查理和政策配对工厂——设计一个问卷运算系统的B端到C端

本文由作者 黄联樵 于社区发布

长文预警，建议先收藏

查理的头都要炸了。查理他开了一家公司，公司年后要扩张，找投资人要钱投资人不给，投资人说，你的公司有它的独特条件，可以找政府拿奖励啊，干嘛让我白掏钱，自己申请去。

查理上政府网站随便打开一个政策一看，确实是这么回事，只要符合条款里的各种条件，就能申请到政府的奖励。然而这些网站太多了，政策也太多了，条款也太复杂了。查理不知道怎么找到自己够格申请的政策，更算不出能拿到多少钱——查理当然不是做不到，只是，查理真的不大愿意做。这太费时间，也太痛苦了。所以查理就开车到附近的市中心散步去了。

走在市中心，查理的两边都是各种巨大又嘈杂的商场，他就在这条路上走啊走，突然看见了一个很违和的建筑。这个建筑周围空荡荡的，只有平整的绿地。建筑本身也简洁得有点奇怪，没有门，没有窗户，没有屋檐和管道，是一个标准的正方体，就像美术课里画画用的石膏方块。

这块大石膏上只有五样东西。墙壁正面凹下去的刻字招牌，写着“政策配对工厂”。墙上挂着一支笔和一张表格纸。从厚厚的墙壁里，延伸出来一条切割得非常平整的矩形开口，而开口的正下方是一个跟墙壁几乎融为一体的，凸起的按钮。

查理拿起表格，看到上面写着：“在表格里勾勾画画几下，然后扔进来，然后按按钮，我们就能很快帮你找到所有符合你条件的政策，并且帮你计算出你能获得的具体政府奖励金额”——查理一看还有此等好事？马上花了3分钟把表勾好，然后就扔进那个非常平整的矩形开口里了……

这篇文章将为你阐述一个通用的问卷运算系统（在本文的预设中，一个政策配对和计算系统，然而它完全可以实现很多其它的场景）从后台到C端的完整设计。

在讲述上，我采用的思路是：一块砖、两块砖，不断砌在一起、不断变得更大。如果你对后台设计有兴趣，你只要一直盯着我怎么砌砖的，不要眨眼，你就一定能看懂并学会。而如果你恰好对后台产品经理有偏见，觉得不过是去堆砌一些复杂的页面，对用户体验的贡献近乎为零，不妨你也看到结尾，想一想如果只有前端产品设计，那么良好的用户体验还是否拥有存在的可能。

现在我们开始吧。

黄联樵 / 微信：arubagod

1

门槛 / 款项门槛

如果我们不了解查理是否能办理一个政策，就直接让他填写各种数据，这显然会让用户付出额外劳动。对于一个政策来讲，我们应该先让查理回答一些简单的选择题，先保证查理能办这个政策，然后再让他填写一些具体的数据来计算能拿到多少钱也不迟——这就是一个政策的门槛。

一个政策经常会划分成一些具体的款项，它们的办理条件是有差异的。例如，有一个政策是针对一些二道房东（科技创新载体）来发放租房的补贴，细分成针对孵化器的，和针对众创空间的，这么两个款项。

对于众创空间来讲，我们要求你是科技载体；而对孵化器来讲，你除了是科技载体之外，你的工位数量还不能小于200个——那么“工位数量大于等于200”就是“孵化器”款项的门槛了。

所以我们要配置一些选项，把其中一些选项标注成这个款项的门槛。你也许会说，为什么图中有两个选项都符合这个款项？不能在文案上进行合并吗？例如第一项是“工位数量300以上”，第二项是“工位数量200到300”，我们把它合并成“工位数量200或以上”不就刚好是这个款项的门槛了吗？

这是因为一个问题设计好之后，是可以抽出来变成通用问题的。可能这个问题在这个政策里只考察你的工位是不是200以上，而在另外的政策里，200个工位和300个工位是区分对待的。后面在提到通用问题的时候会来介绍。

然后我们加上问题描述和一些操作按钮，就形成对一个门槛问题的配置了。对了，这里的设计有一个坑，就是缺少了一个排他的“无”的选项。查理选择了“无”之后，就不能再继续多选了。请大家假装看到了我已设计排他选项的功能。

那么对于这个问题来讲，它会有一些报错的情况。我的所有报错都是层层递进的。比如一个低级模块有3个报错，那么这3个报错会反映到上一级模块的报错区域，形成1个关于这个低级模块的报错，具体报错内容就是“下面有个模块存在3个报错”，至于是哪3个报错，运营的人往下追查就行了——这个报错思路在后面更复杂的地方你可能会被绕晕，所以我先声明一下。

一个款项的门槛问题可能不止一个，所以我们在左侧加上问题列表。列表没什么好讲的，唯一需要注意的是，不管运营的人配置了多少个问题，查理在回答这些问题的时候，必须全部选中了准入的选项。有任何一题回答错误，查理都会失去申报这个款项的机会。

你可以看到，刚才问题的报错传递给了问题列表，问题列表由传到了这里。这里就来到了页面的头部，右侧是对整个款项的属性的设置。前面介绍的情况，是这个款项需要独立配置自己的门槛，也就是“依赖通用+额外门槛”的情况。

另外一种情况则是“仅依赖通用”，如果切换就到这个选项，那么款项本身就不能在配置问题了——只要满足通用条件，查理就可以办理这个款项。例如，当这个款项是针对众创空间的，那么由于众创空间没有额外的要求，所以查理只要在通用门槛里确认了“我是符合条件的科技载体”，就可以直接办理“众创空间”这个款项了。

所以再把这个头部安上去，这个款项门槛的配置页面就搞定了。

讲完了简单的款项门槛，在这个基础上，你想理解通用门槛就比较快了，所以我们点击这个分段控制，进入这个政策的通用门槛吧。

2

门槛 / 通用门槛和“通用的”门槛

一个政策的通用门槛配置页面看上去跟刚才也差不多，只是多了一些东西，下面我就来介绍多出来的东西。

把镜头拉近，看一下问题的配置，这里就跟具体款项门槛的配置不太一样，这里的逻辑会比较绕，请认真看下面这几点——

1、回到上一章我们讲的款项。如果把一个款项设置为“仅依赖通用”，也就是说，只要查理符合整个政策的门槛，就可以直接办理那个款项，那么，对于一个通用问题来讲，它的选项配置成“仅为通用门槛”时，就说明只要用户选择了这个选项，用户就符合了整个政策的大要求，同时也直接符合了那些不做特殊要求的具体款项；

2、但是，像我们上一章提到的情况，一个款项除了要求符合整个政策的大条件，还要符合具体的一些特殊要求时，我们会把那个款项设置为“依赖通用+额外门槛”。例如我们前面提到的，对于孵化器这个款项来说，你除了满足整体对你科技载体资质的要求，你的工位还得超过200个；

3、那么这个时候，我们很显然会去孵化器款项里面，配置关于工位数量的调查问题。但是天有不测风云啊，如果整个政策也对工位数量有要求，只是没有孵化器款项要求的这么高呢？例如，整个政策不管你是什么东西，我都要求你有超过20个工位，而如果你申请的是孵化器款项，我会提高要求，你的工位数量不是要超过20个，而是要超过200个；

4、那么这个时候我们怎么办？我们难道要分别配置两个问题？在通用问题里，先问用户是不是超过20个工位，然后在孵化器款项里，又去问用户是不是超过200个工位？烦不烦啊？用户不就多回答了一个问题吗？所以我们这个时候直接在通用问题里一个问题问完不就行了吗？

5、所以，我们在通用问题里配置了上图的问题，问用户“你的工位情况是怎样的”，然后配置3个选项，分别是：“20个以下”、“大于等于20个小于200个”&