快两年的产品经验里，我做过公司的运营后台和校区的管理后台，积累了一些经验。

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

　　一、梳理业务逻辑

　　业务逻辑的核心是谁(用户角色)?在什么场景下(时间地点)?完成什么任务?这个任务的实现需要经过哪些步骤?

　　下面以互联网教育公司为例进行解释，因为各个功能的使用场景类似，就没有逐一分析。

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

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

　　二、进行权限设计

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

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

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

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

　　三、设计账号体系

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

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

　　四、进行功能设计

　　在做完整体的架构设计，我们就要开始设计每一个具体的功能，这时候可以采取四步走战略。

　　第一步，梳理业务逻辑。仍然是理清楚谁在什么场景下要完成什么任务，形成完整流程图。

　　比如说，APP推送更新，需要经过的环节有以下几步：更新材料配置(安装包、图片、文案)，更新条件配置(推送用户数量/渠道、推送时间、前台/后台更新)，更新数据跟踪，异常问题处理等。

　　第二步，依据流程图，确定产品的功能点。

　　第三步，搭建产品架构图。这一步需要确定页面数量、层级关系;每一个页面的功能。

　　第四步，原型设计。确定每个页面包含哪些模块，每个模块包含哪些元素，按照用户认知顺序对页面进行布局，形成原型图。

　　实操案例：活动运营的功能设计

　　第一步：理清业务逻辑

　　活动运营包括策划、开发、上线、数据查看、下线、复盘等环节，其中运营后台的使用场景是活动运营同学在运营后台上线活动，并且查看以往活动的历史数据;

　　业务逻辑梳理如下：

　　上线：选择资源位(首页、商城banner、开屏页、答题广场)、上线时间、渠道、城市;配置上线素材(图片、文案);设定上下线时间。

　　数据查看：总数据、分时段数据、漏斗、对比;

　　下线：在数据没有达到效果或者发生意外的情况下，需要将活动手动下线;

　　复盘：数据导出。

　　第二步：确定页面和功能点

　　根据上一步的流程，我们可以确定下来的功能有：

　　1、上线功能

　　2、查找历史活动

　　3、查看活动数据

　　4、下线功能