需求描述：
在一个订单流转的过程中，存在两个步骤，分别形成两个权限01和02，分别赋予两个角色。
权限01决定某个订单“确认签署”合同，然后权限02根据合同进行“确认付款”。
低保真原型，大致如下图：
相关疑问：两个按钮相互独立，但是假设某用户A同时拥有权限01和权限02，那么在A的眼里这两个按钮就是替代关系，如何解决？
Hozin的回答：不用解决，本来就是替代关系。
继续追问：公司的设计规范要求“禁用不具备权限的按钮”，那么假设用户B仅拥有权限01，那么B的眼里看到的订单，“确认付款”按钮应该是不可用。
隐约感觉，如果B没有权限02，就不应该看到“确认付款”按钮。
那么，到底“不可用”还是“不可见”？
Hozin的回答：如果没有权限02，为何要让用户感知到“确认付款”按钮的存在？为了保证基本的可用性，禁用某个按钮，必须要解释禁用原因，并且还要告诉用户如何解除禁用……然而，根本不存在解除禁用的方法！除非单独设计一个让用户获得临时授权的流程，否则没有必要禁用按钮。
继续追问：禁用“确认付款”按钮另有的理由~~虽然无法操作，但总要让用户知道“付款”这件事吧？
Hozin的回答：如果想让用户感知“付款”事件，单独设计订单进度条，而不是给用户一个无法点击的按钮。
回头再看需求，如果“订单流转”是一个作用域，那么某个用户在这个作用域应该拥有唯一的角色。权限01和02分别赋予两个角色，杜绝角色之间的权限交叉，但又允许多个角色在作用域内叠加，这恐怕将是另外的隐患。
读者疑惑：“用户组”和“角色”的概念还是有点模糊，假如系统中有两个用户组甲和乙，如果有一个概念把[甲组]和[乙组]封装起来，那这个概念就可以称之为“角色”了？
Hozin的回答：
《ToB 产品经理的常见误解：把 [ 角色 ] 当成 [ 用户组 ]》已经解释过二者区别，继续补充一些观点。
“用户组”和“角色”的存在意义，天壤之别。
用户组是为了区分特征，角色是为了继承特征。
比如下图，有两种动物：鳄鱼和牙签鸟。
我们把它们分为“G爬行动物”和“G鸟类”两个分组（G为Group的缩写），主要是为了区分它们，因为它们在外观形态、内部构造、进化程度各个方面都有很大区别。
换个角度，也可以把它们分为“R爬行动物”和“R鸟类”两个角色（R为Role的缩写），听起来和上面差不多啊，也是区分了动物嘛……但是本质有很大不同，当第三种动物出现，比如鸬鹚，那么……
“R鸬鹚”作为一个新角色，可以从“R鸟类”派生出来，自动拥有鸟类的全部基本特征。
也就是说：如果“R鸟类”增加“卵生”的属性，那么“R鸬鹚”将自动继承。
换个思路，如果第三方动物出现，“G鸬鹚”仅仅是一个新的用户组，相当于和 “G爬行动物” 和 “G鸟类” 是并列关系。
如果“G鸟类”增加“卵生”的属性，并不会影响“G鸬鹚”的属性。
听起来无伤大雅，用起来完全不同。
现实情况往往是：把“用户组”当作“角色”来设计。这样的危害是~~~~既然“G鸬鹚”和“G鸟类”是两个没关系的分组，那么当初为什么要有“G鸟类”呢？直接叫“G牙签鸟”多好啊~~~然后搞出一大堆不同的分组描绘复杂的需求……
如果系统中没有“鸟类”的准确定义~~岂不是回到了史前时代？
封装是为了更好继承，如果无法继承，谈不上封装。
（正文完）
- END -
注：交互设计学堂公众号接受投稿啦，如果你有好的原创设计类文章，可联系客服。别让灵感溜走，快来投稿吧~~
