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

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

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

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

单位小站

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

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

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

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

单位小站是全网内容的主要提供者，但它不是我们期待用户去主动访问的地方，它更像一个wiki式的资料站，它是信息的来源但不是推荐用户玩耍之地。所以我在这里用了窄头部、灰底、紧凑布局的设计。

整个平台所有的页面分为两种大的设计基调，一种是大头部、白色底、大留白的设计，代表鼓励用户探索；另一种则是单位子站这样的wiki式设计。这些原型设计不规定UI最终的外观，只为了向设计师传递调性。

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

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

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

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

政策

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

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