设计实例：如何以“权限”为单位的进行权限设计（二）

上篇文章介绍了以“用户”为单位的权限设计，今天就如何以“权限”为单位进行权限设计为大家展开介绍。

在上一篇文章中，我们说到了以“用户”为单位的权限设计，适用的业务场景为：适用该系统的人之中，存在很多拥有同一类权限的人。

当使用该系统的人中，当非常多的人的权限不一样时，那么以“用户”为单位的权限设计就不适用了，这时候我们需要用到以“权限”为单位的权限设计。

以“权限”为单位的权限设计

适用的业务场景

当使用该系统的人之中，很多人的权限是不一样的，那么我们需要针对单一权限进行单一的设置，这样才能方便进行统一管理设置。

举例：在一个审核系统中，拥有三级审核权限、二级审核权限、一级审核权限的人是不一样的，那么我们需要针对权限进行选择人，来进行添加设置。

如何进行设计？

1、信息架构图

用户：添加用户过程中，直接针对用户设置一个单一的权限

部门：添加部门时，填写部门基本资料即可

2、业务流程图

具体流程：添加用户时，除基本资料外，需要对用户设置权限，而添加部门时，填完基本资料即可。

3、具体原型图设计

菜单有哪些？

除去部门与管理员菜单，增加权限列表的菜单，便于管理，在之后的详情会说到这一点。

管理员添加

添加用户时，填充基本资料后，直接设置权限。

部门添加

添加部门，填写基本资料即可。

权限列表

左方是权限列表，右方为拥有该权限的用户。

交互方式：鼠标移到用户名上时，出现“X”，左键单击进行删除，点击添加管理员，出现弹窗，进行搜索管理员，可多选，为该权限添加管理员。

涉及到的点：当添加一个新用户时，针对新用户设置的权限进行提交后，该权限列表进行更新，权限对应的管理员需要添加该新用户，保持数据的统一。

为什么不直接在权限列表针对用户添加权限？

当涉及到添加新用户的业务场景时，不能在权限列表，一个一个权限地添加，效率太低。

为什么需要权限列表，难道不可以直接在用户资料中进行修改权限么？

当后台系统上线了一个新功能，需要对该功能设置权限，众多用户需要添加该用户权限，显然我一个一个去找用户修改权限的做法十分低效，那么针对权限，一次性添加众多用户，进行多选，可以解决此问题。

以“用户”与“权限”结合的权限设计

最后一种为以“用户”与“权限”结合的权限设计，任何业务场景都适用，主要的方法是：将通用的权限（指的是所有的用户拥有的权限）以及少部分人拥有的权限进行区分，分为两部分进行管理。

但是此方法的难点在于，如何区分通用权限以及少部分拥有的权限，这个界限纯粹凭人工去判断，一旦判断失误，那么此种方案的设计会有很大的问题。

总结

关于权限设计的三种方式已经剖析清楚。

目前业内最通用的还是第一种方式——针对“用户”为单位的权限设计方式，因为这符合当下大部分公司的组织架构。

而第二种权限设计方式——针对“权限”为单位的权限设计方式，这在政府机关高级机密系统中，更为适用，因为大多数人的权限是不一样的，更适用于此种方式。

最后一种，目前市场上的产品，此种方式是极少的，能走通，但可能并不是很适用。

其实，权限设计的方式，任何一种逻辑都能走通，最为关键的是我们需要根据用户使用该系统的业务场景去考虑问题，从而得出一个最优解，这是作为一个产品经理应有的思考方式。

相关阅读：
设计实例：如何以“用户”为单位的进行权限设计（一）
设计实例：如何以“权限”为单位的进行权限设计（二）

专栏作家

不羁，微信公众号：fuckpm，对于电商以及社交领域产品有深入了解，重业务逻辑，喜深入思考，欢迎交流~

关键字：产品经理, 产品设计, 权限

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！