怎样设计一个包办所有对企政策的城市平台？

它是容纳了一个城市所有政府对企政策的平台，它的非正式代号是“城市主站”。它的定位是：只要这个平台部署在某个城市，那么这个城市的所有企业，就能从各种五花八门的政府机构平台中得到解放。

企业不再需要寻找各种政府平台的网址，寻找某种政策，然后寻找那个政策的相关文件和附件，然后再想办法搞清楚需要提交的材料，以及每个材料的填写与装订要求，然后再弄清楚办理的流程……对于城市主站所降临的城市，一切都不需要企业自己去操心了。一切都被规范化，可以被一站式解决，这就是我所在的公司以及我个人设计这个平台的初衷。

这里为你展示的是MPV版本初阶里程碑。虽然我所在公司已经运营了很多政府的很多业务，但是我们显然无法一次性说服一个城市的所有政府部门都按照新的要求来对接全部业务。而对于一个SAAS平台来讲，用户看不到的业务对接工作占据了开发量的90%——我们得先做出成绩，让各个部门都看到我们的平台确实较受企业的欢迎。

这里为你展示的是这个里程碑版本中的主流程。我所在公司的完整的政务系统中，需要对接这个主流程的平台还有：线上表单系统、总库系统、政策匹配系统、线下办理OA系统……由于那些系统相对独立，我将在以后另外介绍。

单位小站

一个城市会有直辖部门，也有各个行政区之下的部门。这些部门自己会颁发一些对企政策，同时它们可能还有旗下部门、旗下部门的旗下部门……它们都有可能会直接对企业开放一些政策。

因此，我们必须用独立的“单位小站”，加上弱关联来设计这个平台。所谓单位小站，是指只要一个单位可以提供政策给企业，我就平等地视你为大平台中的一个子站点，因为服务没有大小之分。

而所谓弱关联，是指不同的单位小站也许级别不同，或者其中一些单位从属于另一些单位——这之中的关联可以随时修改，并不影响小站本身。

单位小站是政策的发布者和执行者，只有让它们独立运营、自负盈亏，才能充分利用人性，给企业带来最好的体验。

政策，安静地呆在单位小站的某个最终分类里，平台的所有政策都来自这种地方。每个单位都有一套自己的政策分类手段，平台应该尽可能地符合政府人员的文书工作流程。因此，政策的分类可以自由向下延展，也不要求层级数量的对称。

锚定于wiki式的子站设计原则，子分类无需配置任何额外的信息，例如描述或配图。这是个只专注于服务企业的平台，不应画蛇添足，额外支配各单位政府职员的运营精力。

处于中间层级时（上半图），路径下面呈现子层级，提示用户继续往下走。路径和子层级之间我尝试过用分割线来区分，也尝试过用箭头来暗示它们的从属关系，但都没有“继续深入…”这个标题来得简洁，而后2×2种目录底框样式可以继续抵消掉大多不必要的设计元素。

不论是最高层级、中间层级还是最终层级，每个层级的政策分类都可以储存“指南”。指南可以是这层分类的指导精神、办理须知、问答……具体的设计会在下文“万物皆论坛”中详解。

政策

曲径通幽处，就是最终的政策，某个单位小站某个最终分类下的某个政策。由于政策是整个平台最实在的一个东西，所以我也用最大的篇幅来介绍它的细节。

我们对全国各政府平台、各种形式的政策已经研究几年了。遇到过链接带你各处跳转的政策，遇到过看到一半突然没有下文的政策。

有些平台的政策只有一篇正文，企业根本不知道下一步该做什么；而做的好一些的平台中，花多一些力气，在各种不同朝代装修风格的页面之间进行网上冲浪，兴许能找到申报指南、申请表格下载、材料装订指南，以及最终的办理渠道——得益于这么久以来的归纳，政策的数据模型设计并未耗费太大的力气。

在政策主页的排版风格上，我采用了大量的留白和靠左对齐。在无线框风格中，“把右边空出来”是web页面相对于移动端最需要体现的差异。

一个政策具有二重身份，除了属于某个单位小站的分类之外，还会属于某个城市分类（会在下文“融合与升华”中介绍），所以需要政策主页需要二重导航。如果将导航放在红色区域，会产生体验上的困惑，因为主站和小站有从属关系，而导航跟在后面则暗示了它从属于小站。因此导航只能放置在蓝绿色区域，而这又会增加一行元素。

为了节省元素，我将一个政策所属的城市分类（1）和小站分类（2）放置在政策头部信息的右边，这暗示了它们都是一个政策最高级别的信息，因此我不必再强调它们代表这个政策的路径。而导航中的首页入口（1）和子站入口（2）恰好对应了路径的上一层——于是我用最少的元素实现了导航的逻辑完备。