腾讯不断推广敏捷开发，也在强调敏捷开发，但你会发现，即便如此，还是会堕入以下情景

• 又丑又长的讨论会
• 好像人手永远不够
• 不切实际的想法
• 悬而不决的功用点
• 无穷尽的偏好设置
• 越来越多牵扯不清的细节
• 项目仍然延期

我们如何构建一个更轻巧的开发流程，让我们更快更好的交付结果？作为一个设计师，如何成为敏捷的一分子？以下是一些心得方法，希望和大家分享

1 界面先行

作为设计师，最简单能让大家明白你的想法就是先把它画出来，不要用晦涩的言语和结构图，毕竟不是所有人都能把你的言语转化为图像。而且界面（视觉，交互）设计是绝对轻量级的，修正起来也简单，成本也低。但修正程序就远不是那么回事了。保持界面先行可以让你非常灵活，至少在开始开发之前可以随意修正。

界面先行另一个最重要的缘由就是，对于用户来讲，界面就是你的产品，界面可以协助你从用户角度看待本人的产品，如何展现，如何操作，给人感觉怎样样，是不是易用。只要当你面对真正界面的时候才能回答这些问题，文档概要并不能帮你处理实际用户体验问题。

2 初期不需求太关注细节

虽然大家总说，成功来源于细节，当然，这非常对。但前期过分关注细节的同时也会令你止步不前。先把大框架确定下来，而不是不断纠结于

• 这条提示怎样写更合适？
• 文字字号用16还是14？
• 要不再往左挪1像素？
• 这里加个高光把
• 把2像素的描边变成1像素

你需求关注细节，但不是如今。所有事情都要从大到小的去做。先把他做出来，把该放的东西放上去，然后实际去用一下。

细节是你在使用的过程中才会慢慢显显露来，只要在使用中你才会发现哪些更值得关注。如果你有足够的时间，当然可以面面俱到，如果没有，请先把精力放在最重要的事情上。

3 不要纠结那些还没有成为问题的问题

“当我们的用户用了这个功用当前还想跟另一个功用配合使用怎样办？”

如果想快速推出版本，就先处理当下。不要花太多时间去考虑还没有成为麻烦的问题。别担心，你还有后续版本。

而且你就真那么确定用户想跟另一个功用配合使用么？如果不是，就先放一边，等问题真正浮出水面的时候再去快速处理。

4 协助产品经理精简功用

好像大家都在弩着一股劲，比谁做的多。竞争对手的产品如果做了**，我们就要做***，他们有4个功用，我们就要做5个。如果不做，拿什么跟他们竞争？

这种方式是行不通的，由于你会发现，永远是赶超，永远没有本人领跑的那一天。怎样办？

做少

通过做少来打败他们

做的功用越多，功用间的交互就会越复杂，用户的学习成本就会越高。而我们的用户真的用的上那些高深的功用么？他们会不会曾经被那些多如牛毛，但我们自以为高明的设置搞得疲惫不堪？试着少做一点，让本人的产品愈加轻巧而更具备亲和力——没有人会喜欢使用显得本人很笨的软件。

5 功用间更少的牵扯

把一个功用点做的尽量独立，能保证需求改变时更为快速，更为灵活。

如果功用间的牵扯太多，就好像你身上沾满了蜘蛛丝，每做一点改变，其他的都要进行改变，从设计，到开发，到测试。当你发现改变的代价太大时，你就会放弃，然后照旧背负着带有缺陷的功用一路走下去。

为什么不开始就尽量少牵扯呢，这样愈加来去自若

6 要有本人的主张

虽然交互设计通常都会处在不黑不白的阶段，由于没有绝对的对与错。但我们还是需求坚定本人的主张。也许果断的观点看起来目中无人，但总比那些“嗯……其实这样也成……”模棱两可要好的多。敏捷开发中需求的就是快速做决定，而不是唯唯诺诺和稀泥。

————————————————————————————————

也许并不是所有的项目都适合，毕竟初期不考虑细节必然要考虑后期更改的成本。但对于一个新产品，快速触达用户，让用户来使用，验证，反馈，得到的数据愈加真实无效。依据这些反馈作出的调整总是比本人拍脑袋来的简单，愈加符合用户需求。

敏捷，并不只是站立晨会，迭代总结，理论，文档，更需求的做的是，把它做出来。