最近在做一个新产品，其主流程是：用户来创建一个广告计划，过程中，需要设定广告计划的基本参数：价格、预算、投放时段、计🦹划投放的广告牌等，然后完成付款。

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

广告牌怎么处理。

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

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

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

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

原因有几个：

如果可以创建，那么广告牌的审核就跟广告计划直接关联，那么两者的时间冲突就可能发生，比如广告牌创建后没有足够的时间审核，广告计划就开始投放了。麻烦
这个系统的分支流程就完全变复杂了，需要引入广告牌创建过程，一个简单的主流程，变成了一个大的复杂流程。
没有给用户清晰的引导，其实对用户而言，做一个事情，一个入口足以，而不需要让用户在多种口子去完成一个事情，比如：创建广告牌。我的建议是在市场中提醒用户，先创建广告牌。
其实这个case还是比较简单的，我相信我可以很轻易的说服有不同争议的人，但是在昨天想到写这个文章的时候，忽然想起来当年在支付宝，设计支付宝的外部接口产品的时🌌候，也是一个类似的情况，却将整个系统高的无比复杂，当然，这是我的错。

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

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

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

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

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

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

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

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

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

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

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

原文：//www.kimihome.net/blog/?p=720