这样的需求，交互设计千万别接！

背景

—

我有一个朋友叫小p，他之前是在bat上班，今年换到了一家创业型公司。然后和我吐槽说心累、身体累。情况是这样的，他们公司属于产品2周一迭代，时间少需求多，平均下来一个设计师4天要完成6个左右需求（其中包含了2个左右大需求，4个小需求），平时的需求他都hold住了。不过上周由于对工作量评估不准确导致他个人接了4个大需求、2个小需求，所以导致他在4天里没有完成6个需求，导致项目delay了。他感到很过内疚和过意不去，觉得工作失职了。好在领导也比较开明，知道员工的辛苦和不容易，并没有责怪他。于是呢，上周末小p和我一起针对这次的需求进行了一次复盘，试着一起去寻找真正的问题所在。

思路

—

在和小p讨论这个问题的过程中，我们采用的是：至下而上反推的方法，个性问题-共性问题，去分析原因及影响，找到解决问题的办法。核心思考：找到问题—分析原因—解决办法。

问题&分析

—

其中第一个问题是问题出发点、也是表象，第一个问题的原因也是表层原因，同时第一个问题的原因又是第二条的问题。

简单的核心流程就是：为什么交互会delay？——交互需求评审会变成脑暴会。交互需求评审为什么会变成脑暴会？——产品需求不明确。产品需求不明确是指什么呢？——产品需求无需求文档，全以口头需求为主；产品口头的需求都是比较大的概念。

通过反推法我们梳理出了为什么小p会觉得很累，需求感觉做不完的原因了。原因为：1.产品经理提供的需求不明确，多数以口头需求为主。2.与产品经理沟通成本大。其中核心问题为需求不明确。同时，为了防止问题的片面性，我建议小p把我们的结论与组内其他交互同学进行讨论，看是否是其他人也遇到了同样的问题，最后发现对于这两个问题其实是一个共识问题。那找到核心问题后，在基于核心问题进行发散，如果需求不明确的核心问题不解决会带来什么问题呢？

需求不明确给设计带来什么问题呢？

—

1，工作量无法评估：口头需求，交互无法预估工作量。

2，需求可以随时变大：产品可以随时增加功能，需求变大导致交互工作增大。

3，沟通成本表达，时间被压缩：需求沟通需要花费1天半左右时间。还会存在沟通后的需求会忘记，重复沟通的情况，因为全是口头的东西。

4，交互的工作本末倒置，设计质量受影响、设计精力受到影响：60%时间精力去分析梳理业务、40%时间精力去思考交互—结果就是最后业务功能推荐的很合理，产品老大/用户抱怨交互体验不好，设计质量不好。这是有很大问题的。

解决办法

—

1，产品需要提供明确的需求，交互才接。

明确需求：1.有wiki连接的、明确的、文档性需求（非口头需求）；2.内容：与产品老大确认过做的需求、有项目背景、现有问题（问题真实性）、现状数据、产品提出的功能性假设方案等。

ps：产品写文档性需求的时间不够，我觉得不成立，虽然脑暴时间是周一，周二给我们需求，但是版本迭代是半个月一次，也就说产品有15天时间去想需求、去理需求、写需求、讨论需求，所以应该是产品他们进行脑暴时就应该有基本的文档性需求，脑暴时不只是口头说。

案例：滴滴、百度、今日头条都是产品必须有明确的、文档性需求，交互才接。同时公司其他业务线：助力车、平台、单车其实也是有基本明确的文档性需求，不存在产品上来就张嘴说的情况。

2，与产品老大反馈下，增强相互间的积极性

产品与交互毕竟是一个相杀相爱的过程，都属于合作关系，在产品不主动的情况下交互需推动产品进行需求确认、需求讨论、设计验收等。

后记

—

后来，小p把这个问题和老大反馈后，老大也意识到了问题的核心原因所在，正在积极推动这件事情。有时候，很多觉得理所当然的事情，不去深入分析，其实真的挺难去发现真正的问题所在，并解决它。所以，其实任何岗位都不容易，遇到问题不要去逃避，可以去思考问题是什么？原因是什么？怎么解决它？如何和领导去反馈并让领导帮助去推动和解决。