不要过分地信任产品经理，所有需求都要自己了解过后，才开始设计。

　　笔者在春节期间在被七大姑八大姨问的比较多的一个问题有：

　　你现在是做什么工作的啊?

　　看着眼前的火锅实在不知道怎么解释，就问了他们一个问题“你觉得我们在春节期间怎么能吃上火锅?”

　　他们的回答大概可以归类为：

　　买材料 —— 火锅底料烧开 ——-放吃的 —— 完成

　　而我的回答是：

　　“如果今天的客人不敢吃辣，而你准备的是辣锅呢?”

　　“如果你买的火锅料大家不是大家想要吃的呢?”

　　“如果客人太多，而锅太小呢?”

　　我目前的工作就是这个，让客人在各种状况下都能享受到这顿火锅。当然我不知道他们是不是理解，会不会以为我是海底捞的服务员。扯远了，回归正题。

　　正是这样的对话，让我回想起以前刚做交互设计师(产品经理)的时候，经常遗漏各种分支业务流程和异常状态。

　　为什么容易遗漏

　　1、没有自发的去了解需求

　　刚入行的交互设计师一接到需求，就按照需求画了原型图，因为原型是按照产品提的需求来的;然而，你对于需求为什么要这样并不了解，一旦错误地理解了需求，产品上线有可能对产品来说是灾难性的。

　　所以，不要过分地信任产品经理，所有需求都要自己了解过后，才开始设计。

　　解决方法：

　　(1)可以参考我之前写过的《产品需求：你真的了解你所看到的需求吗?》

　　(2)之前和其他交互设计师讨论过一个方法：5W法则

　　这里的5W并不像大家常说的what、who、when等，而是连续向你的需求问5个Why。

　　举个例子：

　　我现实中接到过这样的需求：

　　需求：我需要在首页新加一个搜索栏!

　　看起来需求是很明确的，但是真的是这样吗?我们来试一下：

　　第一个Why：为什么要加搜索?

　　答：方便用户对想要的进行搜索。

　　第二个Why：为什么用户需要进行搜索?

　　答：用户可以更高效。

　　第三个Why：为什么用户觉得这样更高效?

　　答：因为在导航很难找到。

　　第四个Why：为什么导航难找到?

　　答：导航归类做的不好。

　　那么到目前只用到了第4个Why，其实需求的真面目就已经有一定程度的揭晓了，用户的困扰并不在搜索，而是在商品的分类上并没有做好，即使做了导航，也只是治标不治本。所以需求应该是对产品的导航进行重新更人性化的归类。

　　所以，不要太相信需求方，要自己去了解需求。

　　2、没有自发地了解业务

　　了解业务很重要!

　　了解业务很重要!

　　了解业务很重要!

　　重要的事情说三遍，在交互方案(原型)设计完成之后，总能听见产品或者开发抱怨，又漏了考虑某个场景或者业务根本走不通的情况，然后默默地开始各种填坑。

　　那么为什么，不在一开始就把业务了解清楚，花费一部分精力去整理业务规则下所包含的所有场景和穷举一些极端情况下的业务场景?

　　所以，一定要和相关人员了解清楚整个业务流程才开始设计。

　　解决方法：

　　避免这种情况最好的方法就是：绘制业务流程图。

　　举个例子：

　　业务流程图的作用是表达清楚业务需求在产品线的各个阶段中在各个功能模块之间的轮转。

　　业务流程图的绘制思路一般是：

　　首先将业务按阶段划分，比如电商类可以分为下单和支付，单车类可以分为提车、骑行和停车;

　　然后列出每个阶段参与的功能模块，比如下单阶段，就有商品查看、登录/注册、信息记录、个人中心等功能。

　　最后按照时间顺序，画出业务需求在各个功能模块之间的流转情况。

　　为了输出一份完整的业务流程图，一般有两个原则：

　　先思考主干流程，再思考分支流程，主干流程逻辑准确，分支流程全面无遗漏;

　　表达清楚后台产生的各种判断及相应的前端展示,这将作为接口设计的重要根据。

　　比如我们以某个餐厅的点菜系统为例：

　　(1)先将业务进行划分：

　　(2)写出功能各个部分的功能模块：

　　(3)按照时间顺序，将业务模块之间进行链接：

　　以上是一个简单的业务逻辑图，但是实际情况可能远远比这个例子要复杂等多，因此更需要业务逻辑图来帮助理解业务。

　　3、没有自发的去和相关人员沟通