企业应用的后台设计，远比你想象的重要

编者按：企业应用的“后台管理功能”在SaaS时代将会越来越重要。但后台设计又往往得不到开发人员应有的重视。本文作者以亲身经验历数了企业软件后台管理功能设计方面的五个误区，希望能对开发者有所启示。本文为投稿，作者系明道创始人任向晖。

企业软件通常都离不开“后台管理功能”（Administration），这是一个非常容易被忽略的环节，但它设计的优劣几乎决定了软件本身的生死。一个逻辑清晰，繁简得当的后台，能够加强实施人员的信心，企业软件的部署就有了内部的支持者，成功率就能够得到提升。相反，如果展示给用户的是一个简陋混乱的体系，他们可能连使用第二次的兴趣都没有，更加不要谈部署决心了。

在SaaS时代，后台设计的要求更高了。因为用户可能在没有任何售前人员的帮助下自行探索产品。这个后台设计的水平会基本决定潜在客户的使用意愿度。尽管企业SaaS产品大多建立了Customer Success团队，但在看到令人失望的后台后，大多数试用者并不会给你打电话。

我历数了企业软件后台管理功能设计方面的五个误区，这是每个企业软件产品都非常容易犯的错误，甚至很多时候，明知故犯。

一、过于薄弱的后台功能特性

大多数产品设计的流程和步骤都是从前台开始，首先考虑满足终端用户的需求，例如协作平台考虑的是每一位协作者，CRM考虑的是销售员工，销售经理。当开发周期压力变大的时候，后台功能的设计和交付周期往往被严重挤压，导致最终提供给客户的是一个特别简陋的特性组合。该有的参数控制没有，该有的初始化过程省略，该有的数据统计缺失。

尤其是这两年的企业移动应用热潮，产生了一大批所谓的“移动优先”、“全移动”的产品，这些产品也许拥有一个比较简洁的前台移动App，但是，用户也别指望能够拥有一个功能强大的管理后台，就连微信企业号，公众号的后台都有这样的倾向。当后台管理特性缺失时，产品的弹性和通用性就会下降，用户会抱怨：“咦，为什么只能这样呢？”、“啊，这个居然都不能自定义！”。当功能的缺失到达一定的程度，超越了用户的接受底线，他回毅然决然地离你而去。

二、选项、配置和参数的垃圾桶

相对于简陋的后台，更加可怕的是繁复的后台。我看到过最吓人的企业应用后台拥有多达数千个配置选项，在一个页面上居然能够塞下上百个。学会这样的软件部署，花的精力基本上可以背下《新概念英语》1-4了。选项配置越多，用户学习成本越高，同时产品的开发难度和差错率也必然高。测试流程中要枚举出所有的用例，可能要花更长的时间，经过反复的使用和调试才能做到bug free。这就是企业软件的常见噩梦。

问题是，明明知道有这么高的风险，为什么开发者会自己往火坑里跳呢？实际上，几乎没有软件在第一天就会把后台搞得这么复杂，通常在1.0版本中，都拥有一个条理比较清晰的引导和分类，但是随着时间的推移，用户的增加，需求的堆叠，再加上缺乏清晰定位的产品战略，糟糕的产品与项目管理能力，这个后台就会被现有用户的需求塞得满满的。所以，看似满足了越多越多老用户的需求，实际上吓走了更多的新用户。当年我们在使用webex的时候，惊讶的发现这么一个会议SaaS，为了配置一个Conference，居然有超过100个配置项，而且主次不分地全部拥挤在一个页面中。就是这个原因，我们开始逐步放弃使用，尽管它的确拥有出众的会议连接可靠性。

为了克服这个问题，首先是产品管理的原则性要强，产品经理和高管都要有极大的克制，有取有舍，绝不轻易加入任何的新特性。在复杂的企业软件中，几乎没有任何所谓简单的小功能添加，任何一个细节的丰富都需要逻辑上的反复验证，细心规划、执行和检查。

拥有一个清晰的产品路线图也是必须的。团队应该能够非常清晰地描绘出未来6-12个月内将要添加和调整的特性，因此会对后台业务产生哪些影响。而且在产品演进过程中，还要不断地根据用户反馈来微调这个路线图。

当越来越丰富的特性交付的同时，对后台管理界面的逻辑分类，新用户上手指南就更加重要，不能图方便随意在一些角落添加选项元素，他们应当依照意义的逻辑(Categorization)，主次的关系(Primary, Secondary)，邻近的规则(Neighboring) 来有序布局。在后台产品上，不要忽略交互设计师的参与，他们应该获得和前台产品同样的重视度。

三、随意的定义和命名

设计企业软件的过程，往往也是定义业务流程和功能的过程。这个过程中，难免遇到很多术语和约定俗称的称谓。比如CRM软件中会定义销售阶段，顾客类型，流程应用中会涉及权限等级，我们总是倾向于用一个简单概括的名词来定义一个复杂的参数组合。因为如果没有定义，就不能设计出简单通用的软件产品。

但有时候，产品经理可能会过高估计用户的共识度，用并不通行的名词来定义流程。比如我们经常看到权限设计中的“管理员”、“超级管理员”、“系统管理员”。仅仅凭借这个名词，用户依然是一头雾水，不得不要花时间搞清楚不同的名称到底意味着什么样的具体权限组合。

解决这个问题就要从用户的角度出发，直观明确地指明权限内容，而不是从产品经理的角度出发，只是完成定义任务。用户如果能够得到简洁而明确的引导，自然降低了部署的心理门槛，消除了功能项目上的疑虑。

四、前后台脱节的割裂设计

当我们使用前台功能时，往往想到：这个地方能不能自定义呢？这里的数据源来自哪里呢？我如果是管理员，是不是可以有更高的权限呢？我看到的是不是和其他人看到的一样呢？

如果你清楚软件是具备对应的管理功能的，那为什么不让我直接从这里改变设置呢？为什么我一定需要从后台管理进入，再找到相关的配置项呢？

我描述的就是企业软件中常见的前后台脱节设计，两者不能直接穿透。它大大影响了高级功能的被发现能力，也影响了易用性。造成这个问题的成因很好理解——割裂的产品管理。前台业务功能可能是产品经理A来负责，而对应的后台模块则是产品经理B负责的。

解决这个问题的一个基本思路，就是建立企业软件的前台和后台的叠加层，就像两张纸一样，叠在一起，在对应的位置上直接打个洞，并用线穿起来。

还有一个更加激进的做法，就是把原先应该从属于后台的管理功能直接嵌入到前台中，根据用户角色来动态决定权限，并提供完善的错误消息。

五、多用户协作架构不合理

大多数企业软件都不是个人独立使用的，它通常服务企业中的团队，但处理多用户和权限分配是一个非常复杂的过程，很多产品在这个环节缺失或者削弱。反过来，也有产品实现了复杂的权限层级，并支持多用户，但定义角色和权限的过程过于复杂，导致用户不得不放弃。更糟糕的是，设计者完全不了解目标客户的协同场景，从自己的理解出发，定义了一些不实用的权限组合，客户发现每一个选项都不属于自己。

比如一个表单管理应用，通常有特定用户创建，但需要更多成员一起编辑和查看表单数据。这就带来了共享协作设计逻辑的问题。金数据（jinshuju.net）在这个环节上的设计遵循了简洁得逻辑，但的确符合大多数用户的需求。它选择在表单这个数据对象上，各自定义协作者列表，并且把权限简单地划分为表单管理，数据维护和数据查看三个一目了然的类别。

当然，很多应用在多用户协作设计中比较犹豫的原因是担心协作者没有动力创建个人账号，这也是明道开放平台为什么支持企业应用全员登录的原因。企业安装应用一旦部署，所有员工均可用现有的明道账号登录。

这同时也对企业应用部署模式带来要求。有些应用选择用admin, sales这样的缺省职能账号模式，这样做既不安全，也不符合这个时代尊重个体的理念，所以，即使企业应用也应该建立个人实名账户的基本原则，否则协作起来会更加困难。

以上是我们十多年企业软件设计和运营的一些经验总结，也许能够帮你少踩一些坑。