后台产品设计|角色与权限

We're here to put a dent in the universe. Otherwise why else even be here?

——乔布斯

近期在负责角色与权限需求，分享后台产品经理在系统考虑角色与权限的设计方法。

角色与权限在生活中其实非常容易理解，一个角色对应的权限是什么？最为直接的案例：会员体系。

• 例如健身房中的普通会员：健身房使用权

• 健身房中的VIP会员：1对1私教顾问+健身房使用权+营养套餐

不同于面向普通用户的角色权限，后台产品经理更多考虑的是在公司内部业务运转下所需要的角色，和相应角色需要的权限。

角色与账号

使用后台系统的人员我们称呼为业务人员。他们需要通过系统完成某样任务操作，才能保证业务的正常流转。

账号的概念在后台系统中是以真实用户为单位。一个用户在一个业务流转下，只需要用一个账号就可以达到相应的权限操作。

类似超级管理员账号，其实他至少会有2个角色存在。角色1是普通用户，角色2则是管理员角色。为此，我们在设计角色与权限的时候，首先要考虑的是账号概念。针对后台系统中，账号的管理机制是如何？内部用户如何开通账号，外部用户如何注册账号？

基于账号所在的部门、账号使用人员的职位、账号当前的状态，做出相应的字段进行管理，方便查找和筛选账号。

角色与权限

上图说到，一个账号可能对应多个角色。我们在权限设计中，最低的纬度就应该是角色。不能允许比角色还小的颗粒存在。如果一个账号A权限>账号B权限，那么只能是因为账号A存在多个角色。

账号设计中切记保持最小权限颗粒度：角色

如果没有角色的概念，产品经理需要把系统中每一个click或页面考虑权限设计。当系统从0到1搭建到1到10的扩展期，涉及的页面和业务会持续增加，产品经理很难把握每个账号的权限标准。

如此多的页面事件和click，我们需要一个角色的纬度将权限与角色捆绑起来。

角色在业务的流转中也是很具体的人物。例如电商系统中的客服流程

上诉的业务流转是一个典型的需求收集流程。当客户投诉相应的问题时候，客服可以交给组长，如果是产品缺陷问题可以汇总到产品经理。角色的出现清洗的界定了每个业务需要的权限操作。

角色与权限什么时候考虑

在搭建后台系统中，核心解决的需求还是来自业务的需求。后台系统作为支撑公司产品的基础系统，我建议产品经理不要一开始就考虑角色权限。而是考虑如何快速满足业务的需求。

如果没有预约，就先做预约系统。如果没有客户管理，就先做用户管理。如果来不及，就先用第三方

后台产品经理的kpi，不同于C端产品里的考虑如何拉新、促活，一个后台产品经理的功力深厚：解决业务需求。

业务人员能够没毛病跑起来，并且提高业务效率，才是一个出色的后台产品。

好啦，今天的分享就在这里。我争取每周分享2篇

近期专题

产品落地的细致活，标准文案

后台产品，1个case|专栏正式上架

学会“引导”，让需求快速落地

降价处理的另一种方式，产品人PK需求方

生活处处，离不开产品经理

产品助理（专员）、产品经理、高级产品经理、产品总监是什么样子？

10年前的产品经理是谁？

另外我个人第一本书籍《从零到壹：PM改变世界的点滴》电子档正式上线这本我归纳222篇产品原创，涵盖产品经理面试、算法、交互等不同维度的内容，如果你感兴趣可以打赏后留言你的邮箱。我会在每天中午12点左右发送到你邮件中（希望大家勿外传支持，支持版权）。如果你需要预览书籍大纲，可以跳转链接

一本给自己与产品人的书：从零到壹。