在评审阶段，我们常常会因为一些疏忽的纰漏，导致需要变更需求，继而耽误进度。为了避免这种情况，该怎么做呢？作者推荐了一个方法——用例驱动设计法，帮助你掌握科学的设计方法，做到不漏细节。

产品设计中，难免会遇到这样一些问题：

• 业务逻辑不全，没考虑到分支流程、异常流程；
• 交互细节没考虑到，部分场景的处理方式缺失；
• 关键业务规则缺失，未定义边界值。

这些问题如果在评审中经常出现，很容易被研发测试吐槽，如果是在开发中出现，可能会通过变更需求来弥补，可能还会影响开发工期。

要避免这些问题，需要有一套科学的设计方法。刀哥给大家推荐一个方法，可以有效解决这些问题，我把它叫做用例驱动设计法，以用例驱动设计，保证业务、交互、规则都能考虑到，不遗漏关键细节。

01 什么是用例？

用例是对参与者通过系统达成目标过程的描述。

用例是UML里面的标准术语，也可以理解为功能模块，用例是参与者和系统的交互过程，是第三方视角，而功能是系统视角，可以从这个角度来加以区分。

一个完整的用例，包含用例名称、参与者、前置条件、后置条件、主流程、备选流程、业务规则，这几个部分。

用例名称：用例名称是一个动宾结构，如新增用户、修改用户、删除用户。用例也有层级结构，比如管理用户是一级用例，而新增、修改、删除，为二级用例。

参与者：是指执行这个用例的角色。

前置条件：要执行这个用例，需要具备的权限、状态等。

后置条件：执行完用例后，系统如何处理，比如增加一条数据、删除一条数据、变更状态等。

主流程：用户达成目标的正常流程，分为参与者和系统。

备选流程：包含异常路程和分支流程，这部分是在梳理需求时，最容易被遗漏的。

业务规则：系统根据具体的规则来执行处理，这些规则，需要在用例的描述清楚，业务规则也是容易遗漏的点。

02 用例的其他部分

按照传统的UML规则，用例里是不包含界面交互的，用例更多的是表达逻辑，关心用例的更多的是后端研发，这是狭义的用例。

我把用例涉及到的界面也放在用例里，我把它叫做广义的用例，广义的用例包含业务逻辑、字段规则和界面交互。

业务逻辑主要包含流程和规则，字段规则主要包含系统的输入和输出，界面交互是对页面、控件的交互描述。

这样一个广义的用例，就可以把需求描述得很清楚，不遗漏关键细节。每个单独的用例，可以作为设计、研发、验收的单位。

03 如何以用例驱动设计？

以用例驱动设计，可以分为以下几个步骤：

1. 梳理所有的用例

一个大的用例，可以分成更多的二级用例，二级用例又可以拆为三级用例，以每个具体的三级用例，作为产品设计的最小单位。

2. 写用例

前面已经说过，用例包含名称、参与者、前后置条件等要素。写用例之前，可以先不用动手画原型，也可以画了一些简单的原型再写用例，具体根据自己的偏好。

以下是一个完整用例的模板。

这种是标准的用例协作方式，实际工作中，不一定要按照这种模板写，也可以用流程图+文字描述的方式书写。比如在Axure里面写PRD，内容形式要求并没有那么高，甚至不用画流程图，直接文字描述也可以。流程图的作用，是帮助我们可视化业务逻辑，使设计更全面，不遗漏细节。

3. 设计交互界面

在做界面之前，可以先做一些竞品调研，分析竞品的界面及交互，然后再开始动手，在分析竞品的时候，也可以看看别人的业务逻辑及规则，看自己的设计是否有考虑到。

比如，做验证码登录这个模块，可以分析国内几家用户量比较大的产品，看他们是怎么设计的。

以下是京东APP验证码登录的交互界面。

第一步，输入手机号。

第二步，输入验证码。

通过对京东登录模块的分析，也可以试出他们的一些业务规则，比如：

• 验证码有效期为1分钟；
• 同一手机号当日获取次数最多为5次；

以上这些界面交互和业务规则，都可以作为我们设计的参考。

电商平台的用户量比较大，会考虑到很多用户场景，对于这种通用的模块，参考大厂的做法，是比较保险的。

在分析完后，我们再来做自己的设计，就可以做到很全面了。

写在最后

以用例驱动设计，可以全面的考虑业务逻辑、界面交互，不遗漏关键细节，以这种思路写出的PRD，质量会更高。

写出高质量的PRD，是产品经理的基本功，PRD质量高，才可以花更多的时间去思考产品规划、产品迭代、产品运营等，进阶高级产品经理。

自己梳理用例的时候，把正常流程、异常流程、分支流程，都考虑到，具体做交互设计的时候，可以去参考大厂的设计方案，按照这个思路设计，产品应该不会太差。