设计反思 From Waterfall to Agile（4）：Agile UX是如何做设计的

简单来说，Agile和传统工作方式最大的区别就是知道自己的YY是不靠谱的，未来也是不可预测的，充满各种奇葩可能性。这里所说的不靠谱的拍脑袋YY，不局限于老板和产品经理拍需求，也同样包括设计师拍脑袋设计界面、开发拍脑袋写代码。这种自知之明是发自内心的，所以就演变出一套小心翼翼做事情的方法。所以这套方法也只适合于在迷茫中探索。要是打一开始就要抄别人现成的，要搞大项目大手笔大规划，还是瀑布流更好点。

对Agile UX，我觉得可以分成这样三节来介绍，也是一个迭代的前、中、后：

1、如何制定计划？
2、如何与团队协作做好设计？
3、产品发布后干什么？

1、如何制定计划？

项目开动前，是要先有个计划的，确定接下来一段时间团队该做哪些功能。古人形容诸葛亮博学，说的是“前知五百年，后知三千年”。我们没那个能耐，预测不到几个月后的世界会是怎样，所以也就不知道这几个月里做什么是对的。那么，还是只给未来一周&两周定计划吧，这样还略靠谱点。以一两周为一个迭代周期，结束时就立刻把产品送上线，交给用户（APP虽然一般要上架才能发放，但也有诸多灰度测试用户的方法的）。

项目刚启动时，大家有的只是对产品的一个猜想，这个产品是否会被用户追捧、到底能不能赚钱，鬼知道。所以这时候需求规划都是猜，有太多未加验证的假想。这些猜想就属于开荒型功能。等这个迭代结束后，产品上线了，有了用户反馈，局势才会明朗一些。用户骂都懒得骂的功能，尽早放弃的好；用户在骂不好用的功能，就可以列为优化型需求。从此就是无穷无尽的迭代了，每个迭代都夹杂着开荒型的YY和反馈后的优化。

对待这两类功能，设计师出力的方式是不一样的。开荒型功能，纯拍脑袋出来的，风险大。最急迫的事情是把它尽快推到用户那里去试用。靠开会讨论功能是否靠谱，左分析右争论，都没用。所以对这类需求要做的就是Quick & Dirty，先出一个糙的设计方案就赶紧开发出来上线。担心交互/视觉做的太烂被骂？你咋不担心呕心沥血做出来的设计都没用户理会呢！用户反馈在骂不好用，起码说明人家在用。把反馈收集好，放在后面迭代里当优化型需求就好。而且这段时间里功能已然上线了，你自己也在每天用，自然能酝酿出更成熟的方案，打磨掉不舒服的毛刺。

设计需要时间来酝酿Redesign，别指望一次就把界面所有细节做完美。Take it easy。

2、如何与团队协作做好设计？

Agile的精髓是User Story，它用三段式来描述一个功能会怎样为用户带来价值。”作为×××（某类型用户），我希望有一个×××的功能，以便能帮我实现×××这个目标”。这种描述方式，够精炼，同时又有很大的自由度，允许团队去想很多种潜在solution。而且，每一个User Story都只描述一个很小的场景，这样就能让设计每处理好一个Story就拿给开发去实现，从而快速上线，在迭代结束时就能把它活生生地摆到用户面前啦。

由于在User Story中明确表明了做这个功能是帮用户做什么事情，所以就有了一个大家都认可的价值标准。这样就给了设计师与其他人沟通的桥梁。在设计过程中，设计师可以随时对这个Story背后的商业规划、界面的可实现性等等不确定的问题与产品经理、开一起讨论。大家对着一块白板一起写写画画，就能快速探讨多种潜在方案的优劣。随着讨论的逐渐深入，解决方案也慢慢成型。等到差不多可以交由开发去实现时，已经充分吸收了大家的意见，所以也就不必再开什么设计评审会了。

把设计意图传达给开发，不意味着设计师就可以放假啦。开发们随时会来咨询一些设计上的细节，也会因为一些之前的疏漏突然告诉你这个做不了。不要因为这些突发事件而懊恼，毕竟人人都是会犯错的。或许开发的遗漏还是因为设计师没主动讲到位呢。这时只要大家面对面快速讨论一下，找到变通的方案就行，也完全没必要回去更新设计文档。

所以你会发现，在Agile UX中，还真是没有明显的职能先后关系，做完交给下游就可以完全不管了。所有的人都密切交织在一起，分不清。

3、产品发布后干什么

以前发版本就像买股票一样，买完就盼着数据涨。要是涨了大家就开心下去腐败一顿，要是跌了或者没啥动静就自甘倒霉继续干活押下一个宝。但敏捷团队对待发布的态度是不同的，发布更多是为了试探和学习。产品上线后的反馈能够帮助我们了解到一个活的功能究竟会怎样影响用户的生活。

和关注宏观的指标不同，设计师必须去观察那些与User Story紧密相关的小指标，才能精确地知道这个Story做完有何成效。对于开荒型需求，如果用户反馈表明确实有需求，那就值得花更多精力去打磨它，如果是大大的负面消息，那就要赶紧割肉换方向，损失的也只是一个几小时做出来的粗糙设计而已。对于优化型需求，因为有了之前的指标做对比，新的设计究竟起到了多大的效果一看便知。设计师经常抱怨自己的贡献不被重视，那有可能也是因为你没有把精力放在解决团队头痛的问题上。只要设计确实解决了问题，大家就能感受到前后的差异。

由于迭代周期足够短，所以设计师很快就能看到拍脑袋的设计实现出来究竟是怎样样的效果；每一个Story足够小，也能让设计师面对负面消息时忍痛割爱及时掉头。这些都能帮助团队以尽量低的成本在迷茫中学习，最终找到正确的方向。

所以总的来说，Agile的核心思想非常简单。我们可以对产品有设想，但它不靠谱，所以我们需要尽快把产品做出来拿给真实用户去收集反馈，验证猜想。在猜想没有被验证前，所有过多的投入都是有风险的，非常浪费。不要想做一个宏大的规划然后攒一两个月的气，然后放大个招，“哒~哒~”，下载量爆表吧您嘞；而是做一点就验证一下，把每一次反馈视作学习，尊重自然，尊重“与预料不一样”。所有具体做事的术，都是围绕这些想法展开。面对新领域，学习的效率越高越好。

敏捷，不是快，是灵活，面对不确定的灵活。