文档介绍：产品设计中的点线面法则文章主要讲的是如何从零搭建起一个信息系统的方法,但实际上甚少有产品人员会参与到系统搭建的工作,因为系统架构往往是在产品的初期,大部分的情况下都是已经搭建好的系统再去根据不同的需求增加不同的流程或功能。那么这个时候再使用UML或SERU的方法就会造成每次都可能对系统架构的重设计,需要重新去梳理一个子系统中整个业务的过程,不利于快速迭代的开发。在这里我提供另外一种适合快速建模的方法,我称之为”点线面法则”。在“点线面法则”中,有四个重要的组成部分,分别是:人物、场景、需求、功能。在业务流程抽象成任务流程中最关键的点就是把握好如何将人物,场景,需求转化成功能。但有很多项目都试图通过定义功能性需求和非功能性需求来确定需求,这些需求没有说明一个用户如何使用系统,也没有说明一个功能在何种场景下必须运行,这样的抽象方法无疑到最后是不符合用户预期的。所以在产品设计中,人物/场景/需求这三者应该是不可分割的组成,这个组合在uml里面称之为“usercase用户案例”,任何只考虑需求或场景的设计都很容易陷入“我认为式”或“老板式”的设计。“点线面法则”是把交互事件作为节点,用例作为一条线,再根据点与线的关系构成页面,显现出从线到点,从线到面的设计原理。实际操作中第一步让我们先把线分清楚,每一条线是根据不同类型的用户在不同的场景下的一种事件流程组成的,也就是说线是由用例组成的。用例是参与者在系统中执行了一系列动作,这些动作将生成特定执行者可见的价值结果。这里值得注意的是两点,用例是有人物有场景有目标的,也就是说它能够在特定场景下为参与者带来有意义的结果,例如”填写表单信息”显然对参与者而言是没有意义的,所以这就不是一个合适的用例。第二个是对角色的划分,很多人认为C端产品没有太多角色的划分,其实以电商为例可以划分为首次登录的用户、老用户、从外链进入的用户等等,不同的用户不同的场景都是能产生不同的用例的,在梳理的阶段分得越细就越不容易出现遗漏或考虑不周的情况。图1根据用户和场景的不同建立不同的用例线分清楚线之后我们开始丰富线里面的交互动作。用例场景是有步骤的(执行了一系列动作):也就是说,它是一个由一系列业务步骤组成的业务活动。业务活动是属于线下的真实活动,我们需要把这个业务流转化成线上的交互动作流。对于一个动作,实际上是没有具体的划分的,例如一张表单里面如果需要填写两部分的内容,产品人员认为表单的其中一部分有复用性需要区分,那么这个流程就可以拆分成两个填写的交互动作。只要是属于交互动作,并且有足够的理由支持能成为一个节点,那么这一个流程便是合理且符合实际业务情况的。图2丰富用例线中每个场景的交互动作在一个用例里动作也存在与其他用例的动作产生交互的现象,例如某机构有销售人员与财务人员,财务人员进行记账时就要获取销售的报价然后等待销售与客户完成交易,这就是销售人员的用例与财务人员的用例产生交互的情况,所以在存在与别的用例产生交集的地方可以先把这里一系列的动作归纳为一个父级动作,在里面再进行一系列子级动作的过程。同样如果存在一个动作涉及到几个交互动作也可以把它分为子级与父级的关系。比如”完成表单”是一个父级动作,新建、填写、提交这就是属于”完成表单”的三个子级动作。这里也类似我们在画素描的时候,如果局部的地方需要画一个箱子,我们就会把这个箱子的范围先确定下来