更小更快更灵活——设计师谈敏捷
这是一篇来自腾讯WSD用户体验设计团队的文章，供大家参考。
腾讯一直推广敏捷开发，也在强调敏捷开发，但你会发现，即便如此，还是会陷入以下情景
- 又丑又长的讨论会
- 好像人手永远不够
- 不切实际的想法
- 悬而不决的功能点
- 无穷尽的偏好设置
- 越来越多纠缠不清的细节
- 项目依然延期
我们如何构建一个更轻巧的开发流程，让我们更快更好的交付结果？作为一个设计师，如何成为敏捷的一分子？以下是一些心得方法，希望和大家分享
1 界面先行
作为设计师，最简单能让大家明白你的想法就是先把它画出来，不要用晦涩的语言和结构图，毕竟不是所有人都能把你的语言转化为图像。而且界面（视觉， 交互）设计是相对轻量级的，修改起来也简单，成本也低。但修改程序就远不是那么回事了。保持界面先行可以让你非常灵活，至少在开始开发之前可以随意修改。
界面先行另一个最重要的原因就是，对于用户来讲，界面就是你的产品，界面可以帮助你从用户角度看待自己的产品，如何展现，如何操作，给人感觉怎么样，是不是易用。只有当你面对真正界面的时候才能回答这些问题，文档概要并不能帮你解决实际用户体验问题。
2 初期不需要太关注细节
虽然大家总说，成功来源于细节，当然，这非常对。但前期过分关注细节的同时也会令你止步不前。先把大框架确定下来，而不是一直纠结于
- 这条提示怎么写更合适？
- 文字字号用16还是14？
- 要不再往左挪1像素？
- 这里加个高光把
- 把2像素的描边变成1像素
你需要关注细节，但不是现在。所有事情都要从大到小的去做。先把他做出来，把该放的东西放上去，然后实际去用一下。
细节是你在使用的过程中才会慢慢显露出来，只有在使用中你才会发现哪些更值得关注。如果你有足够的时间，当然可以面面俱到，如果没有，请先把精力放在最重要的事情上。
3 不要纠结那些还没有成为问题的问题
“当我们的用户用了这个功能以后还想跟另一个功能配合使用怎么办？”
如果想快速推出版本，就先解决当下。不要花太多时间去考虑还没有成为麻烦的问题。别担心，你还有后续版本。
而且你就真那么确定用户想跟另一个功能配合使用么？如果不是，就先放一边，等问题真正浮出水面的时候再去快速解决。
4 帮助产品经理精简功能
好像大家都在弩着一股劲，比谁做的多。竞争对手的产品如果做了**，我们就要做***，他们有4个功能，我们就要做5个。如果不做，拿什么跟他们竞争？
这种方式是行不通的，因为你会发现，永远是赶超，永远没有自己领跑的那一天。怎么办？
做少
通过做少来打败他们
做的功能越多，功能间的交互就会越复杂，用户的学习成本就会越高。而我们的用户真的用的上那些高深的功能么？他们会不会已经被那些多如牛毛，但我们自以为高明的设置搞得疲惫不堪？试着少做一点，让自己的产品更加轻巧而更具备亲和力——没有人会喜欢使用显得自己很笨的软件。
5 功能间更少的牵扯
把一个功能点做的尽量独立，能保证需求改变时更为快速，更为灵活。
如果功能间的牵扯太多，就如同你身上沾满了蜘蛛丝，每做一点改变，其他的都要进行改变，从设计，到开发，到测试。当你发现改变的代价太大时，你就会放弃，然后依旧背负着带有缺陷的功能一路走下去。
为什么不开始就尽量少牵扯呢，这样更加来去自如
6 要有自己的主张
虽然交互设计通常都会处在不黑不白的阶段，因为没有绝对的对与错。但我们还是需要坚定自己的主张。也许果断的观点看起来目中无人，但总比那些“嗯……其实这样也成……”模棱两可要好的多。敏捷开发中需要的就是快速做决定，而不是唯唯诺诺和稀泥。
————————————————————————————————
也许并不是所有的项目都适合，毕竟初期不考虑细节必然要考虑后期更改的成本。但对于一个新产品，快速触达用户，让用户来使用，验证，反馈，得到的数据更加真实有效。根据这些反馈作出的调整总是比自己拍脑袋来的简单，更加符合用户需求。
敏捷，并不只是站立晨会，迭代总结，理论，文档，更需要的做的是，把它做出来。
http://www.oschina.net/news/11564/designer-talk-about-agile