后台产品思考上篇——架构和权限设计

后台产品和用户端产品本质上是一样的，都是分析用户需求，将需求落地为具体的产品功能。相比之下，后台产品更加注重业务逻辑和数据流转，而且后台产品的用户更有耐心，对视觉设计和交互设计要求较低。

先说运营后台的宏观架构。

首先，梳理业务逻辑。

业务逻辑的核心是谁（用户角色），在什么场景下（时间地点），完成什么任务，这个任务的实现需要经过哪些步骤。下面以互联网教育公司为例进行解释，因为各个功能的使用场景类似，就没有逐一分析。

通过和不同业务线上的运营同学交流，了解他们的日常工作，我们收集到了这张表。中间需要注意的是，不同的运营同学的工作内容可能有交叉，比如教师运营和商城运营的同学也会进行一些活动运营，这个在权限划分上需要注意。

产品架构按照任务类型来组织，每个角色可以快速找到自己需要的功能。

接下来，进行权限设计。

权限管理的核心是明确谁有权干什么。一般来讲，权限划分有两种方式，一种是按照业务类型进行角色设计，一种是按照用户的职位等级进行划分。两种划分方式可以结合起来，按照职位等级划分之后，再针对每个等级进行角色细分。

以运营后台为例，由于初创公司的管理结构较为扁平化，权限设计没有上下级划分，只有一个超级管理员账号，其他的按照角色来分组，不存在层级关系，操作不需要上级审核。

但是我做的另外一个校区管理后台系统，相比较之下就较为复杂。由于是2B的系统，层级分为总部、区域、城市、校区，每个层级内部又有角色细分，比如校长、课程咨询、学管师等等。将需求和层级纳入同一张表里，我们就得到了这样一张权限设计表。

PS：这张权限设计表其实还有很多问题，比如没有把层级清晰地展示出来，一眼看过去比较混乱。但是由于层级和角色比较多，我也没有想到更好的设计办法，还请大神指教。

第三步，设计账号体系。

账号体系主要包括账号生成、登陆、注销、密码找回、多系统关联。小公司的内部后台管理系统账号大多由开发同学——超级管理员，负责生成和注销。在层级较多，组织庞大的情况下，就要考虑账号注册、审核、绑定等问题，核心是保证账户安全和操作简单快捷。

以校区管理后台为例，校区刚开始试运营的时候，人员较少，没有层级，所有账号都由总部超级管理员生成。后来开始拓展2B业务，系统重构，这时候就开始重新设计账号体系，改为超级管理员只开通校长账号，下级账号由上级开通和注销，保证了校区运营的灵活性，同时节约了超级管理员的时间。很多crm系统也是一样的规范，这个可以参考借鉴。