回顾中国近现代史，“宁可错杀一千，也不放过一个”这样的情况经常出现，当然，过去杀的是人命。

但是在互联网产品设计中，其实我们也经常出现类似的错误，拿身边的例子举例：

• 登陆时候的验证码。验证码的出现应该说是防止暴力攻击帐户的一个非常有效的办法，于是一夜之间，几乎所有的网站都在登陆的时候使用了验证码。但是问题来了，每次、每一个用户登陆都需要验证码吗？难道每一次登陆你都怀疑它是具有暴力攻击的危险的吗？
  • 事实上答案是否定的，慢慢的，产品经理知道这不是最好的解决方案，于是修改为默认不使用验证码，当用户输入密码错误超过一定的次数以后再出现，比如google/比如支付宝。
  • 但是为什么一开始我们没有想到这个问题呢？我记得去年我在这里也说过这个问题，就是指支付宝的登陆，每次都需要输入该死的验证码。幸运的是后来修改了，不幸的是，错误一次密码就要输入验证码。^_^

幸运的是，可以看到越来越多的类似的“谨慎”被修正，比如淘宝交易创建，我记得之前也是有一个验证码需要输入的。每次购物还要输入一次验证码，想起来就头疼。为什么当时不能把这个问题解决好呢？

现在不需要输入了，但是背后的逻辑是什么呢？是简单的去掉验证码？还是说有更好的逻辑等待在后面呢？

负责人：

用例描述：

用户界面设计：

用例场景：

• 用户：
• 前置条件：
• 主流程：
• 后置条件：
• 扩展流程：
• 输入项详列：
• 输出项详列：

关联ＵＣ

补充规约：
遗留问题和可能的解决方案：

————————–

作为产品设计师，开始做一个新产品设计，一开始的时候，通常是在脑子里面的一堆想法，idea或者是跟需求方讨论出来的一些业务规则等等，最终要变成可以实施的项目，需要产品设计师去梳理，规范化需求，并最终形成需求文档，UC是其中最典型的文档产出物了。

我的建议是：

• 原则上流程图，特别是业务流程图是最先开始要拿出来的，在流程图中要确保各个业务流程是完整的，而且是效率最高的。这个需要比较多时间的讨论和细化。
• 将业务流程拆分成为一些典型的用户交互模块。比如：用户管理模款、帐户管理模块等
• 将每一个模块划分成为典型的用例组合，比如：用户注册、用户信息修改等等。

所以在具体开始写UC的时候，我的建议是：

1. 不要一个UC写完整了再写一个，建议是先通盘写出所有UC的名称（其实名称一定程度上已经定义好了UC的主要工作目标了，比如：用户注册、注册用户信息修改、帐户信息检索等）。等于是写文章的一个提纲，主要的章节都有了。然后再看一遍，对照自己脑子里面的业务流程，看看是否有遗漏的。
2. 写完成UC的描述，我的常用格式是：通过本UC….， 比如“通过本UC，用户可以完成支付宝用户的注册。” UC 描述基本上已经明确定义了该UC的范围，大小。在往下写之前，对该UC应该完成的主要功能，以及会遇到的所有分支、输入输出应该有明确的定义。UC的撰写过程只是将上述的内容进行细化和规范化，变成其他人可以阅读使用的东西。特别提醒一点：UC是给别人看的，而不是你自己看的。
3. 下面说说正式写UC正文的时候，我个人觉得特别要注意的地方：
   1. 正确的定义UC的用户和前置条件，将会有效的改善UC的流程复杂性。比如：淘宝要做一个专门为淘宝卖家准备的产品。淘宝卖家第一次进入该产品，需要确认一个服务条款。怎么定义用户和前置条件？常见的会有：
      1. 用户已经登录
      2. 用户为淘宝卖家
      3. 用户尚未确认最新版本的服务条款
   2. 根据上面的业务是为淘宝卖家做准备而言，上面的用户定义貌似没有问题，但是在实际产品设计中中会遇到一个问题：怎么判断用户是淘宝卖家？用什么条件？看，麻烦来了，所以，我的建议是，把上面的第二条去掉。会有问题吗？当然具体还是要看业务，我只是举例子，说：用户的定义将很大程度上影响流程的复杂性。
4. 主流程一定是你希望的流程，你认为用户最顺利操作你的产品的流程，那么它就是主流程。很多Pd在写UC的时候。主流程无比复杂，里面加入无数的判断，就是因为这一点上没有明确。我自己的感觉是，往往一个UC，主流程可能很短，而分支流程会比主流程多，而且复杂。

Kimi注：未完，待续

从上面的描述来看，这个主流程其实很简单，无非是一个表单，但是在实际的设计过程中，会有一个问题：

广告牌怎么处理。

在国内做过广告产品的人应该知道，作为广告的投放者，需要对投放的广告内容负责，也就是说，如果在淘宝网上投放广告，那么广告内容，需要淘宝负责，一个基本的逻辑就是广告牌需要淘宝进行审核，在没有审核通过前，广告牌是无法进行投放的。

那么好，现在的问题来了，如果一个用户尚未创建任何的广告牌，那么允许用户去创建广告计划吗？

在逻辑的设计过程中，这个争议是显而易见的，我这里就不说争论过程，我说一下我现在的结果是：

如果没有创建审核通过的广告牌，那么广告计划就不允许创建。

原因有几个：

1. 如果可以创建，那么广告牌的审核就跟广告计划直接关联，那么两者的时间冲突就可能发生，比如广告牌创建后没有足够的时间审核，广告计划就开始投放了。麻烦
2. 这个系统的分支流程就完全变复杂了，需要引入广告牌创建过程，一个简单的主流程，变成了一个大的复杂流程。
3. 没有给用户清晰的引导，其实对用户而言，做一个事情，一个入口足以，而不需要让用户在多种口子去完成一个事情，比如：创建广告牌。我的建议是在市场中提醒用户，先创建广告牌。

其实这个case还是比较简单的，我相信我可以很轻易的说服有不同争议的人，但是在昨天想到写这个文章的时候，忽然想起来当年在支付宝，设计支付宝的外部接口产品的时候，也是一个类似的情况，却将整个系统高的无比复杂，当然，这是我的错。

详细说一下，支付宝的外部支付接口，主流程也是很简单的。

用户从商户界面跳转倒支付宝付款页面，然后验证支付宝帐户、密码，然后完成付款。

但是在当时的产品设计中，考虑到，如果到了这个页面，用户没有支付宝帐户怎么办？于是在主流程之外设计了复杂的分支流程：

用户允许选择创建一个新支付宝帐户，只要输入一个Email就可以了。但是事情远没有这么简单，如果这个Email是已经存在的支付宝帐户呢？系统又要跳回来输入密码验证，如果是email是合法的，还需要事后发送邮件让用户补充完整帐户信息，比如密码等。这个一个小分支引起的大麻烦啊。

说道这里，我想表达的意思是，如果可以重新设计，那么我会在支付宝付款接口页面上，将新用户的问题排除掉。这样我相信开发会简单很多。系统的逻辑也简单。用户操作也简单，不需要太多的选择。

当然，有人会问，我就是到了这个页面上，但是没有支付宝帐户怎么办？

是一个问题，我的建议是，这种情况我们不服务，需要有舍弃。在平衡产品的复杂性和用户操作的“伪用户体验好”之间，需要一个优秀的舍弃动作。

如果你不是支付宝会员，说明支付宝的市场部，会员营销部还有很大的空间。

建议负责这个产品接口的产品经理，可以调用一下数据，看看现在有多少的用户通过这个接口使用的时候，选择的是新建支付宝帐户的模式。我猜想，我现在的想法应该是正确的。（当年，我错了）

其实以上文章内容想说的是：

在保持产品主流程简单的同时，如果遇到复杂的分支流程，是不是可以将分支划走，不要进入这个功能模块？而不是因为要考虑用户体验，而硬生生的将不同的逻辑绑定到一起。如果真的是这样，还不如清晰的告诉用户，你要做什么事情，需要事先完成什么事情。前置条件弄的明白，并且给用户清晰的入口去完成前置条件。