产品设计的双管道模型

产品设计的双管道模型各步骤内容，以及各步骤产品经理的工作如下：

1.  业务分析和软件需求

 如果把产品设计的过程，比喻成一个妈妈怀孕，孕育宝宝的过程。那么最初的业务分析和软件需求分析，相当于拥有非常强大的基因力量的，初具雏形的胚胎，有头，有手，有脚，有身体。但是手还没分化出手指，只有一个手柄。这个阶段非常的重要，它是一个定形的过程。它在胎儿后期稳定地生长起到很大的作用。

产品经理如果是那个施魔法，培育产品宝宝长大的魔法师妈妈，他就需要就业务分析和软件需求分析这个阶段，孕育产品。

业务分析和软件需求的落地点，是生成软件需求规格。无论后续的系统设计和用户体验设计阶段，都必须基于这个规格的要求，提供相应的“设计”解决方案。

2. 用户体验设计

从大部分企业的分工，用户体验设计可以拆分成交互设计和UI设计两大领域。

首先是交互设计。也就是一些比较大型的公司，或者是注重用户体验的中小公司才会配备交互设计师。

而很多中小型的公司，把产品经理当成半个交互设计师，而UI设计师也当半个交互设计师，虽然，往往0.5+0.5<1。但是，这些公司在没有享受到“用户体验”带来的“好处”的时候，在花成本配备交互设计师这个事情上需要掂量掂量也是正常的。

关于交互设计，产品经理可以如下思路考虑：

如果公司有交互设计师，那么作为产品经理，需要考虑需求和交互设计的衔接，以及如何品鉴评审交互设计，看交互设计是否符合需求。

如果公司没有交互设计师，那么作为产品经理，自己画原型，就需要考虑如何进行交互设计了，需要自己动手和思考，包含功能内容范围，交互设计，信息框架，原型设计等工作。

另外，产品经理也需要关注UI设计。

这里也分两种情况：一般讲，大部分的软件公司还是会请UI设计师的，但是也有少部分的公司，不是把UI设计外包，就是要求进来的产品经理十项全能，也能用高保真原型，代替UI设计的工作。

想要产品经理十项全能这种模式，其实怎么讲，我始终觉得人的精力是有限的，你这里花的时间多了，其他的业务分析，软件需求分析的时间肯定就少了的。所以这个事情对于产品经理往往是负担，而不是提供成长机会。话说回来，这种情况下，如果是后台系统，一般就是找一些好的UI设计模版套上去，也不会太浪费时间，但如果是一些非后台的页面，还是要自己捣鼓一番，着实有种非专业人士做着专业的UI设计的即视感。

除了这种比较奇怪的模式和外包模式之外，产品经理一般是要在UI设计师在UI设计后参与设计评审的，所以产品经理虽然不用做UI，但是关于UI设计是否符合需求这件事，则需要把关，因为它会影响到产品最后提供给到客户和用户的价值。另外，UI设计会有一些很主观的成分，如何在品鉴UI设计的时候保持专业性，让产出的界面，符合目标用户的审美，符合目标用户的使用习惯，也是需要产品经理需要建立一定的审美能力。

3. 系统设计

系统设计，一般会进行系统架构设计和数据库设计。在软件需求完全确定下来了之后，就可以进入本阶段了。产品经理会和系统架构设计人员和开发人员，一起对软件需求进行内部讨论，主要在可用性，和技术可实现性做相应的评估。当然，技术可实现性，在软件需求提取之前，产品经理就经常要去找系统架构师去聊聊“假如会要做...需求，那技术可以满足吗？”之类的问题。避免在软件需求做完了之后，才发现“糟糕了，居然是没有办法实现”。

在技术可实现性评估之后，系统架构师就开始进行系统架构设计和数据库设计，系统设计完成了之后，也会有相应的系统设计评审，产品经理需要参加，看是否内部架构的设计，能提供产品需求所需要的种种特性，例如所需要存储和调用的数据，是否都已经在结构里面了，数据和数据的关系是怎样的，能不能支撑业务。技术上的功能模块是否能涵盖产品需求。在确认这些内容都没有问题的时候。就可以进入下一步工作了。

系统设计结果，产品经理需要确认是否符合需求。

4. 开发

回顾传统IT软件开发过程，会在需求分析和系统设计之后，就进行开发了。但是，在互联网新型软件，由于更注重非功能性的，更高层级的用户情感需求，以及用户价值实现的需求。所以开发阶段之前，会多增加一个步骤，就是进行用户体验设计，从用户的角度出发，综合考虑用户的行为和心理，以用户需要的系统外部表达方式，把系统提供给用户。

在双管道模型，开发阶段之前。即要进行系统设计，又要进行用户体验设计。无论用户体验是否摆在第一重要的位置，只要系统是考虑做给人用的，那么产品经理就有“提供给人使用的便利性”的目标。即使为了平衡成本，减少了这个部分的考虑，但是这个部分依然存在。

开发阶段，就是开发人员写代码的过程，有了系统设计评审，以及评审输出的标准。完整的交互原型，以及UI设计稿，开发人员只要按着这些“标准性”的要求开展就可以了。开发阶段产品经理多走查，多了解，是否开发出来的和需求，和设计有偏差，过程的监控其实也是开发的产品在测试之前的“预测试”的过程，为了让产品生产出来能符合设计的需要，这也是产品经理要重视的事情。

5. 测试

产品的测试是从什么时候开始的呢，开发之后吗？

产品的测试，系统的目标愿景出来，就已经开始了。系统的愿景，在《软件方法》的定义，是目标组织老大希望系统给组织带来的改变。一旦愿景确定下来，就要找到系统可量化的验收要求，这个验收要求，将成为系统“验收测试”阶段的“测试脚本”。

系统需求输出出来之后，需求文档将为测试人员提供验证和核对系统分析结果提供依据。

在系统原型出来之后，测试人员编写“系统用例”，这将作为系统“用例测试”阶段的“测试脚本”

在视觉稿出来之后，测试人员将会以视觉稿为基准，去核对开发出来的页面，是否符合最初的“设想”。

测试阶段产品经理需要对所有的测试文档进行查阅，看是否测试人员对于需求，设计的理解有所偏差，如有偏差就要和测试人员协商调整。另外产品经理是系统提供方的最后把关者，所以自己也要站在涉众人员的角度，时常测试，时常使用，时常反馈，时常改进。

测试阶段产品经理的工作，依然可以归纳到产品管理的工作，而不是产品设计的工作。

参考书籍《软件方法（上）》，作者“潘加宇”