编辑导语：当设计师有了一定的工作经验后，往往会发现工作的范围不再只限于输出设计方案。这就要求我们除了专业的深度累积，也还需要拓宽横向职业技能。本文作者今年完整的参与了一个从策划到运营全程跟进的项目，在探索过程中，累积了一些产品搭建的基础知识，并且分享给大家。

在我的认知体系中，将产品的类型进行了如下划分：

以主体维度划分，产品类型可分为“消费级产品”和“企业级产品”，也就是我们常说的“C端产品”和“B端产品”。消费级产品和企业级产品的区分特征在于，产品的客户和用户是否为同一主体。

所谓客户，就是付费的那类人；所谓用户，就是使用的那类人。消费级产品，付费的和使用的都是同一类人；而企业级产品，付费的和使用的不是同一类人。

基于以上的阐释，我们可以给出书面的定义：

• 消费级产品，是指客户和用户为同一主体的产品。
• 企业级产品，是指客户和用户非同一主体的产品。

以需求维度划分：产品类型可分为“工具类“、“社交类”、“生活类“、“信息类”、“娱乐类”、“游戏类“六种。具体的类型定义我就不做冗余阐述了，这些类型还是比较好理解的。

有了前序的产品类型分类后，明确要设计的产品是属于哪种类型，接下来进入从0到1的必经之路。

一、评估产品的投入和产出

在建设任何一个产品或功能前，首先都需要考量建设的必要性。对于必要性的考量，无非就是要回答以下几个问题：

1. 能带来什么价值？

这个问题是产品的基石，实际是在思考用户的本质需求。在这个阶段我们很容易犯的错误就是把解决方案当成是价值本身。

用个大家烂熟于心的例子，用户说想要一匹马，但用户的本质需求其实是想要提高通勤效率。

那么我们在回答这个问题时，就不能浅显的认为答案是“我可以给用户提供一匹汗血宝马”，“提供马”只是带来价值的一种解决方案，并不是价值本身。

2. 价值怎么量化？

以工具类产品为例子，其价值就是降本或增效。到底能降多少本、能增多少效，是需要给出量化评估的。成本一般可用人力成本、硬件成本来评估，效率一般可用耗时来评估。

这里给出的量化评估，细化后就是后续产品的关键指标和目标。

3. 影响范围有多大？

影响范围其实可以归入到价值量化的问题中，这里单拎出来的原因是因为这一点很多时候会被我们忽略。在系统产品中，影响范围一般可通过角色数、用户数来进行评估。

同样的，影响范围也是后续产品的关键指标和目标。

4. 需要投入多少资源？

设计师也应该需要具备一定的成本意识，对于产品开发的投入，一般会通过工时（人日）、硬件、外部采购这三个纬度来评估显性成本。

同时，从经济学的角度看，人力资源、部门预算属于私用品，有时我们还需要考量其他产品因未能使用到资源而产生的价值损失等这类隐性成本。

TIPS：前三个问题是从“产出”的角度出发，第四个问题是从“投入”的角度出发。正如微观经济学的厂商理论中，会分为生产理论和成本理论两个方向来研究。

二、业务流程与产品架构

当验证完产品建设的必要性，决定要开发这款产品后，就该进入到业务流程的梳理和产品架构的设计阶段。这是产品从0到1建设时独有的一个必经阶段，我们必须严肃、认真、敬畏。

业务流程，包括了业务流、状态流、数据流，涉及钱的系统还会有资金流。产品架构，是指产品中的功能模块或子系统组合。

对于复杂的系统，一般需要先梳理业务流程，再设计产品架构。产品架构会随着业务流程的梳理而逐步呈现，这是一个很自然而然的过程。

在这个阶段，我们会需要借助一些图工具，包括业务流程图、状态图、权限表、时序图等工具。工具的种类是很多的，以下仅举例我在项目中使用过的几个工具。

业务流程图主要描述的是业务需要经历的主步骤，是状态图、权限表的基石。

完整的业务流程图帮助产品、设计、研发、测试等各个角色的参与人快速了解业务全貌。

可以直接从业务流程图中洞察业务逻辑是否合理，在更进一步的细化工作开始前，就能先砍掉很多不必要的分支流程（功能），或是修正显而易见的逻辑错误。

状态图

主要描述的是业务步骤中存在的各种状态，是梳理异常业务流的强有力的工具。

可以清楚的看到会有多少同页面的不同状态。设计师在初次接触状态图时，容易忽略系统产生的路径与页面状态，或是把系统路径与角色路径混淆在一起。

权限表

主要描述的是各角色对产品各功能模块的页面权限、操作权限、数据权限，是基于状态图，添加角色后的细分理解。

每种业务状态都由相应的角色/系统操作产生，而链接其中的每条线就是赋予不同角色的权限能力。描述方式上，基于开发的语言，和技术模型的结果进行表达更清晰易懂。

将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。

时序图

主要描述的是功能模块间的业务、数据、信息、资金的流转，是基于数据流程图对产品架构的最终呈现。和我们熟悉的服务蓝图比较起来，时序图更适合面向研发人员，清晰的介绍数据流转关系。

除了展现产品整体的数据流转信息外，也可以用以说明某些涉及多平台多方合作的数据流转关系，以下的案例便是一个比较简单且适合向开发哥哥阐述数据关系的时序图。

TIPS：注意“这是产品从0到1建设时独有的一个必经阶段”的理解。这个阶段虽然在后续产品迭代（从1到100）的建设中不是必须经历，但是并不意味着就完全不会经历。

一切都在变化之中，产品架构也会跟随业务变化发生调整。

这并不是鼓励我们可以随随便便的在迭代中重启产品架构设计，架构设计一旦重启，就意味着业务主流程的缺失或冗余，随之而来的就是整个系统问题。

这个时候，就提头去见开发哥哥吧。

三、优先级的考量

经济学家说，社会的资源总是不够的，人类的欲望总是多样的。同样的，完成了产品架构的建立，我们对产品所要具备的功能模块或子系统已经了然于胸，但开发资源是有限的。

这个时候就需要一套机制或一种逻辑支撑我们做抉择，决定哪些功能要先开发，哪些功能可以后面慢慢迭代。优先级是产品工作中常常挂在嘴边且永远绕不开的话题。

优先级本质上是对功能或需求的一种分类维度，而分类标准可以有两种：用户价值标准、企业价值标准。

以用户价值为标准对优先级进行考量，最经典的就是Google的“牙刷理论”。牙刷理论把功能分为三个层次：很多人用、很多人经常用、很多人不仅经常用而且必须用。

以业务价值为标准对优先级进行考量，可以把功能分为三种：生死功能、特性功能、扩展功能。

生死功能是指刚性、痛点、决定产品生死的功能，如数据分析类产品的准确性；特性功能是指为了契合用户、提高收入的功能，如数据分析类产品的美观性；扩展功能是指不决定生死、不决定定位、不决定体验、但又不可缺少的功能。

通过以上两种标准综合考量，功能模块或子系统的优先级基本也可以梳理出来了。

四、概念模型与操作

接下来，我们就要开始进入具体功能模块的策划。诶，先别急着交互画原型。在这个阶段，我们需要思考，如何让用户理解系统功能的运作方式，这个过程就是在建立概念模型。

举个简单栗子，志愿者去为某公益机构服务做善事，我们会把这个过程理解任务认领的过程。

这就是一个简单的概念模型，基本不用学习，我们就知道要去向机构认领再提交自己做的结果。但在数字环境下数据读取中，任务认领就不是如我们表面看到的那样简单，而是在多个模块甚至系统间交换数据。

点击就可认领任务，就是一种方便用户理解在数据流转方面如何运作的概念模型。

试想，如果系统直白的将它原本的运作方式呈现给我们使用，我们甚至需要编写一段代码才可以成功解读一个任务描述，再将任务归属到我的账户系统下，估计我们很多人一时半会儿学不会。

看完这个栗子相信大家应该对概念模型这个东西有点感觉了。概念模型帮助我们把复杂的物理现象转化成可用的、可理解的心理模型，它是组织和理解复杂事物的非常重要的工具。

一个好的概念模型，可以化繁为简，减少用户的学习成本，这也是概念模型的意义所在。

完成了概念模型的选型和建立，用户在这个功能模块中需要执行哪些操作以及操作的步骤都将很自然的呈现出来。

TIPS：无论在产品开发环节还是在用户与产品的交互环节，固有的复杂度都无法依照我们的意愿去除，只能设法调整、平衡。所以在建立概念模型时，产品经理不能仅仅关注用户使用的复杂度，还需要考虑当前概念模型的技术可行性，要多和开发哥哥交流。

五、信息架构与页面交互

这个阶段处理的是用户体验要素中“框架层”和“表现层”的事物，是设计师擅长和熟悉的阶段。也是我们本来就掌握和熟练的领域，所以在此处不展开细说。

六、关键指标制定

产品的效果必须要有可量化的指标来衡量，而且在产品的不同阶段，需要关注的指标也会有所差异，关键指标的制定需要遵循以下3个步骤：

1. 明确产品阶段；
2. 明确每个阶段需要关注或突破的问题；
3. 针对问题制定有效反馈指标。

根据以上步骤，对系统产品，我们可以梳理出以下关键指标：

其中，“系统触达业务”是指使用系统功能完成了某个业务任务，“系统触达业务数”是指使用系统功能完成了某个业务任务的数量。

这个指标主要反映的是，用户是在使用系统功能来处理业务，还是仍然按照传统方法在处理业务。

七、发布计划制定

发布之前，必须要做的是找一个专业的测试工程师来全盘测试几轮。

与他们深度沟通，让他们了解清楚整个系统的设计意图，他们是帮助产品发现系统问题的重要角色，能大量的减少上线后出bug的问题。

这个阶段还要解决的问题，是如何让用户更快更好更容易的接受产品新功能。

我们可以用一句话来描述：在什么时间点，针对哪些角色，针对哪些用户，灰度或全量发布什么产品内容，发布后通过哪些方式教育用户。

总结一下就形成以下的表格：

其中发布策略包括：灰度、全量。教育方式包括：额外的培训、页面指引、页面宣传等。

八、反馈的收集与分析

在这个阶段的指导思路，我们可以采用望、闻、问、切：

• 望，观察用户的操作，可以通过可用性测试、眼动测试等实现。
• 闻，听用户的吐槽、抱怨、建议，可以使用兔小槽等工具辅助收集。
• 问，向用户提问，注意要区分目的性提问和探索性提问。
• 切，分析指标数据，注意要对数据进行清洗和修正。

TIPS：问题的答案不是重点，重点是问题背后的意义。不了解问题背后的意义，即使知道答案，也只是照猫画虎、东施效颦。

最后想说的：

产品搭建的套路是相通的，以上的8个步骤是我从交互设计师转型产品体验设计师的过程中，摸索的产品搭建基础套路，是大部分产品都会经历的起步流程。

产品搭建的套路又是不通用的，方法的适合度总是因人而异。所以，试着在你目前的产品建设中对以上套路实践一番，你或许能理解的更到位，同时还能改造优化成更适合你自己的一套方法论