有意义的，所以这就不是一个合适的用例。

第二个是对角色的划分，很多人认为C端产品没有太多角色的划分，其实以电商为例可以划分为首次登录的用户、老用户、从外链进入的用户等等，不同的用户不同的场景都是能产生不同的用例的，在梳理的阶段分得越细就越不容易出现遗漏或考虑不周的情况。

图1 根据用户和场景的不同建立不同的用例线
分清楚线之后我们开始丰富线里面的交互动作。

用例场景是有步骤的（执行了一系列动作）:也就是说，它是一个由一系列业务步骤组成的业务活动。

业务活动是属于线下的真实活动，我们需要把这个业务流转化成线上的交互动作流。

对于一个动作，实际上是没有具体的划分的，例如一张表单里面如果需要填写两部分的内容，产品人员认为表单的其中一部分有复用性需要区分，那么这个流程就可以拆分成两个填写的交互动作。

只要是属于交互动作，并且有足够的理由支持能成为一个节点，那么这一个流程便是合理且符合实际业务情况的。

图2 丰富用例线中每个场景的交互动作
在一个用例里动作也存在与其他用例的动作产生交互的现象，例如某机构有销售人员与财务人员，财务人员进行记账时就要获取销售的报价然后等待销售与客户完成交易，这就是销售人员的用例与财务人员的用例产生交互的情况，所以在存在与别的用例产生交集的地方可以先把这里一系列的动作归纳为一个父级动作，在里面再进行一系列子级动作的过程。

同样如果存在一个动作涉及到几个交互动作也可以把它分为子级与父级的关系。

比如”完成表单”是一个父级动作，新建、填写、提交这就是属于”完成表单”的三个子级动作。

这里也类似我们在画素描的时候，如果局部的地方需要画一个箱子，我们就会把这个箱子的范围先确定下来，整个局部都画好了再去细化这个箱子里面的细节，属于一个局部分总分的思想。

最终把所有用例线的交互动作都表示出来就完成了这一环节的工作。

图3 完整得构建出所有用例的交互流程
点线构成面，这里所说的面其实是”页面”。

交互动作在系统中最直接的体现就是页面的反馈，所以页面的反馈是需要我们去设计的。

上一步在确定节点的时候以动作去做一个划分也是希望在这个阶段可以把每个动作变成一次对页面的交互，通常情况下一个动作(子级动作)一般对应一个页面的变化，所以在这个阶段，我们把每一个节点转化成页面。

在个时候还不是页面最终呈现的效果，只是把每次动作的变化转换成界面的变化，不需要考虑某些动作是在同一个页面上操作的情况，只需完整地把结果页面列出来即可。

图4 把交互动作转化成页面的变化
最后我们需要把同类用例线的所有页面进行一个归纳和分层，确定页面与页面之间的层级关系。

归纳是把不用用例的同类操作合并，分层是把不同流程的动作区分界面的层级以确定产品的架构层级。

这一步的目的是为了在表现层中提取内在业务的联系，也是基于所有构成的用例中（业务流转方式）取出最合适的页面表现关系。

图5 把所有用例的页面变化相连接
图6 归纳和整理同层级的页面，提取核心
图7 页面分层，最终效果
总结一下整个过程就是”线-点-线-面”这样的一个顺序，先把用例线进行全面梳理确定范围，然后再细化每条用例线中的交互动作确定节点，再思考每条用例线之间的交互与联系，从而把整体进行页面化，把流程最终转化成页面的关系，最终是一个通过页面确定整个系统架构的过程。

这样的方法是先把业务流程产生的用例转化成交互流程，然后以交互流程为依据建立页面与层级之间的关系，实际上整个过程都是在以业务流程为核心推动着系统架构的设计，是一种自下而上的设计方法。

先把底层的所有用户、场景、需求产生的用例都梳理出来，再经过向上一级的归纳提取把其中核心的业务流程模型建立起来。

这样的方法非常适合做快速的功能设计，能够在较短的时间内确定交互动作的流程，在这个过程中只注重交互的流程而不是交互的形式。

在功能设计的时候我们总是说要善于归纳总结，但是如果前期没有想清楚所有的用例那么后期肯定是要不断地去填坑，”点线面法则”能很好地帮助产品人员最大程度上规避出现这样的情况。

人物、场景、需求、功能这四者必须贯穿在整个设计思考的过程中，不断去思考四者之间的关系，所谓万变不离其宗亦算是这个道理。

#专栏作家#
justilam，知乎id：justinlam，人人都是产品经理专栏作家。

一个产品，半个设计。

专注企业信息系统的研究与总结，擅长CRM与ERP系统的架构与规划。

爱好业务需求分析与互联网产品设计，希望在有限的时间研究更多的东西。

本文原创发布于人人都是产品经理，未经许可，不得转载。

人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。