这样的需求,交互设计千万别接!

背景

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

你可能感兴趣的:(这样的需求,交互设计千万别接!)