产品|探索中前行：一个设计师做产品的浅显心得( 二 ) 业务流程|心得|状态图|产品|设

文章插图
状态图
主要描述的是业务步骤中存在的各种状态，是梳理异常业务流的强有力的工具。
可以清楚的看到会有多少同页面的不同状态。设计师在初次接触状态图时，容易忽略系统产生的路径与页面状态，或是把系统路径与角色路径混淆在一起。

文章插图
权限表
主要描述的是各角色对产品各功能模块的页面权限、操作权限、数据权限，是基于状态图，添加角色后的细分理解。
每种业务状态都由相应的角色/系统操作产生，而链接其中的每条线就是赋予不同角色的权限能力。描述方式上，基于开发的语言，和技术模型的结果进行表达更清晰易懂。
将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。

文章插图
时序图
主要描述的是功能模块间的业务、数据、信息、资金的流转，是基于数据流程图对产品架构的最终呈现。和我们熟悉的服务蓝图比较起来，时序图更适合面向研发人员，清晰的介绍数据流转关系。
除了展现产品整体的数据流转信息外，也可以用以说明某些涉及多平台多方合作的数据流转关系，以下的案例便是一个比较简单且适合向开发哥哥阐述数据关系的时序图。

文章插图
TIPS：注意“这是产品从0到1建设时独有的一个必经阶段”的理解。这个阶段虽然在后续产品迭代（从1到100）的建设中不是必须经历，但是并不意味着就完全不会经历。
一切都在变化之中，产品架构也会跟随业务变化发生调整。
这并不是鼓励我们可以随随便便的在迭代中重启产品架构设计，架构设计一旦重启，就意味着业务主流程的缺失或冗余，随之而来的就是整个系统问题。
这个时候，就提头去见开发哥哥吧。
三、优先级的考量经济学家说，社会的资源总是不够的，人类的欲望总是多样的。同样的，完成了产品架构的建立，我们对产品所要具备的功能模块或子系统已经了然于胸，但开发资源是有限的。
这个时候就需要一套机制或一种逻辑支撑我们做抉择，决定哪些功能要先开发，哪些功能可以后面慢慢迭代。优先级是产品工作中常常挂在嘴边且永远绕不开的话题。
优先级本质上是对功能或需求的一种分类维度，而分类标准可以有两种：用户价值标准、企业价值标准。
以用户价值为标准对优先级进行考量，最经典的就是Google的“牙刷理论”。牙刷理论把功能分为三个层次：很多人用、很多人经常用、很多人不仅经常用而且必须用。
以业务价值为标准对优先级进行考量，可以把功能分为三种：生死功能、特性功能、扩展功能。
生死功能是指刚性、痛点、决定产品生死的功能，如数据分析类产品的准确性；特性功能是指为了契合用户、提高收入的功能，如数据分析类产品的美观性；扩展功能是指不决定生死、不决定定位、不决定体验、但又不可缺少的功能。
通过以上两种标准综合考量，功能模块或子系统的优先级基本也可以梳理出来了。
四、概念模型与操作接下来，我们就要开始进入具体功能模块的策划。诶，先别急着交互画原型。在这个阶段，我们需要思考，如何让用户理解系统功能的运作方式，这个过程就是在建立概念模型。
举个简单栗子，志愿者去为某公益机构服务做善事，我们会把这个过程理解任务认领的过程。
这就是一个简单的概念模型，基本不用学习，我们就知道要去向机构认领再提交自己做的结果。但在数字环境下数据读取中，任务认领就不是如我们表面看到的那样简单，而是在多个模块甚至系统间交换数据。
点击就可认领任务，就是一种方便用户理解在数据流转方面如何运作的概念模型。
试想，如果系统直白的将它原本的运作方式呈现给我们使用，我们甚至需要编写一段代码才可以成功解读一个任务描述，再将任务归属到我的账户系统下，估计我们很多人一时半会儿学不会。
看完这个栗子相信大家应该对概念模型这个东西有点感觉了。概念模型帮助我们把复杂的物理现象转化成可用的、可理解的心理模型，它是组织和理解复杂事物的非常重要的工具。
一个好的概念模型，可以化繁为简，减少用户的学习成本，这也是概念模型的意义所在。
完成了概念模型的选型和建立，用户在这个功能模块中需要执行哪些操作以及操作的步骤都将很自然的呈现出来。