当我们在进行互联网或系统产品设计时，大多数产品经理都明白产品创意和交互设计的重要性。但是，如何将一个优秀的产品创意变为真正的产品，以何种方式体现交互设计之美，我们必须以严谨有序的方式进行产品设计。

在To B产品，特别是后台产品的设计工作中，即使这些产品通常逻辑比较复杂，但仍能遇到产品经理接到一个需求任务，上来就开始画原型，做交互，乐此不疲。事实上，这种工作方法常常是不可取的。理清该需求的本质，并在产品设计中以合理和完善的方式去体现，才是第一要务。从此开始，我们应该抛弃一切不着边际的幻想，从最冷静和理性的角度来着手产品的设计工作。

第一步：剖析需求，提出问题

在做需求分析的时候，产品经理的一个大忌就是，拿来就做，不问问题。不问问题有两种可能性：第一种可能性是需求已经提的很完善了，没有什么问题可以提；第二种可能性是需求分析不到位。

举一个例子，曾经有一个业务部门需求是，将原本T+1的金融产品赎回到账体验改为T+0实时到账。但是该需求并没有提出具体的实现方式，只提出他们可以先垫一部分钱给投资者。我们在分析这个需求的时候，首先要明白，这个需求的第一要务是，无论如何，投资者应该在赎回的当前就拿到赎回款。

• 衍生出的第一波待解决问题较为宏观：
• 一旦T+1变为T+0，原来的T+1产品是否还存在？
• 是重新创建一个T+0的产品还是把原来T+1的产品改为T+0？
• 这个T+0产品将会是系统中唯一的T+0产品还是未来多个同类型产品中的第一个？

这一波问题找到答案后，我们将会对T+0赎回这个业务的边界有大致的了解。如果是孤例，那就是一个功能模块级别的任务。如果将来会大规模开展，那我们应该从现在就开始考虑功能的扩展性（然而市场总是变化快，开始说只是先做做，后来要大批量上的情况也很多，这主要看产品经理自己的判断是否准确了）。

第一波问题找到答案后，将会进入第二波问题的提出：

• 这个业务将由哪几个部门协同合作？
• 谁领导，谁协同？
• 资金从哪个账户出款，何时出款？
• 是否有回款，什么条件触发回款？
• 这些流程的各个节点，谁推进，谁审核，谁被通知？

这些问题答案就是是能够完成产品设计的最关键素材，这个维度的问题应该问到不能再问的原子级别。问题是否问完的检验标准就是，产品经理是否自己能够流畅的口述整个流程的信息流和资金流的流转过程，有一处不明白，那一处就会成为实现时的坑。

第三波问题也非常重要，这个层次的问题主要在系统层面。例如：

• 由哪几个系统协同完成这个需求？
• 系统和系统之间是如何交互的？
• 数据一致性如何保证？
• 一旦一个系统挂了，另一个系统如何回滚或容错？

在这一波问题中，可能需要技术同事作为顾问，但问答并不需要太细，因为当前只是处在需求分析，并未上手设计。

三波问题，百分之七八十有了答案之后，我们可以写出一个较粗的需求分析报告，给业务部门进行确认。哦，我知道很多产品经理说我哪有时间写这玩意儿啊？没错，你可以不写，但不能不想。

第二步：用例先行，框定边界

如果有做后台的产品经理不知道用例，那是一个很大的遗憾。因为没有用例，就没有整个系统。简而言之，只要能完成预先设定的用例，无论系统实现得多么差，都起码是一个合格的系统。

如何写用例在这里不多讲，个人认为最好的参考资料是《大象-thinking in UML》。写好用例的意义在于，划分清楚，在当下需要实现的版本中，哪些需求是需要实现的，哪些不需要。这点很重要，如果不划分清楚，很有可能出现在需求文档的撰写中，不断加新需求，使版本计划延期，版本功能变得不可控。

第三步：按角色分模块，按功能分模板，按模板做页面

后台产品的原型设计，在很多人眼中，似乎不那么注重交互，就是一堆“某某管理”的操作页面。我们见到的大多数国产后台产品，例如各种OA系统，流程管理后台，ERP后台，数据管理后台等，大多数做的潦草而匪夷所思。

说到这里，不禁想岔开一下：

• 为什么我国美食世界闻名，高端厨具还是用德国的？
• 为什么我国是中医文化的发祥地，现在高端汉方化妆品还是唯韩国马首是瞻？

还有很多的为什么，如果说国防实力或航天科技方面需要国家财力的支持，那么在民用品的创新设计方面，我们也不优秀，这似乎应该是一个社会问题。

那么，我们应该如何来做页面级的功能设计呢？只有一条宗旨，降低学习成本，提高使用效率。

假设该产品已经沿用多年，除非有显著的简化和易用性新设计，一般不应改变原有交互逻辑，不管你觉得该逻辑有多么白痴。原因很简单，这个产品的使用者很有可能是一些初中都没毕业的客服中心人员，很有可能是一些很少跟电脑打交道的人，他们并不是我们这样天天研究各种互联网产品的人，当我们做好原型之后，应该自己模拟用户去试试，到底能不能完成既定工作，而不是沉浸在自己应用了各种所谓高端的交互设计概念的飘飘然中不可自拔。

接下来，继续进入正题。

在模块设计时，为什么会有“这个管理”、“那个管理”模块，到底是谁在管理，管理的目的是什么？这个模块的工作之前（前置流程）是什么？做完这个模块的工作之后（后置流程）是什么？这些都需要考虑清楚。

个人的建议是以一个或一类角色的工作作为一个大型的模块，以该类角色中不同的分工作为子模块来处理。这样一来，这类角色可以集中处理工作，而不需要在整个系统的不同模块之间跳来跳去的这里点点，那里点点，一不小心就忘了操作。

这里也举个简单的例子。

见过有些产品设计，将某些业务的申请和审核做在一张页面里，我个人是很反对这种设计的。这种设计的第一个坏处是，这倒逼了技术实现必需将权限设定到按钮级，增加了工作量；第二个坏处是，对于操作员和审核员，无法区别展示不同内容，大家看到的信息必须是完全一样的，毕竟你们共享了一张页面，因此扩展性也是差的。

再说说按功能分模板。

每张页面都有它自己的功能，没有一张页面是什么功能也没有的。一般页面的功能可以粗略的分为：综合展示页面（dashboard类页面）、表单工单类页面-即填入一些数据并保存的页面、列表类入口页面-即展示数据表格并带有一些索引链接的页面（例如产品列表，投资者列表等）、数据查询类页面-即带有搜索区和结果区的页面、详情主页类页面-即展示某个对象全部数据的页面（例如个人资料、账户详情等）。除此之外，弹窗也有一些模板，在这里不一一列举。

如果我们能够预设一些模板，并在页面设计中尽量复用这些模板，不但可以节省我们的工作时间，也可以让用户的学习成本进一步降低，因为对大多数人来说，触类旁通比完全从头开始学习容易得多。

当然，这是一个循序渐进的过程，我们自己应该在一次次的产品迭代中，也对我们的页面模板库进行迭代，不断重新整合、分拆，以适应新的业务和进一步优化原有业务。

当我们完成了以上三步，可以说大部分的产品设计工作已经完成，但是这仅仅是设计阶段，这些工作还不能达到可以提交开发的阶段。

下一篇开始写产品自测。

本文由 @echo回声 原创发布于人人都是产品经理。未经许可，禁止转载。