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

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

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

首先,梳理业务逻辑。

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

后台产品思考上篇——架构和权限设计_第1张图片

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

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

接下来,进行权限设计。

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

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

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

后台产品思考上篇——架构和权限设计_第2张图片

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

第三步,设计账号体系。

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

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

你可能感兴趣的:(后台产品思考上篇——架构和权限设计)