第一章 权限交互的典型业务场景梳理：B端多角色系统、C端会员等级、数据可见性边界

权限交互是产品设计中“看不见的骨架”——用户每一次点击是否可用、每一条数据是否可见、每一个按钮是否出现，背后都由权限规则驱动。本章从三类最典型的业务场景出发，帮助产品经理建立权限交互的全局视角，为后续用 Axure 原型做权限验证打下场景基础。

1.1 三类场景的业务素描

1.2 场景一：B 端多角色系统

用户场景： 一家 SaaS 公司的 CRM 系统中有“销售主管”、“销售顾问”、“市场运营”三类角色。销售主管可以查看团队所有客户的跟进记录，但无权修改其他成员的商机金额；销售顾问只能看到自己的客户；市场运营可以查看客户画像标签，但不能操作商机阶段。

业务问题：

• 角色定义不清晰导致权限蔓延，超管频繁救火
• 角色与岗位一对一 vs 一对多，缺乏灵活映射
• 权限变更缺乏影响面评估，一个角色改动影响上百人

用户访谈关键问题：

• “您一天中需要跨几个系统/菜单完成核心工作？”
• “给您分配一个查看全公司数据的权限，您觉得是方便还是困扰？”
• “当您需要临时查看下属客户数据时，目前的流程要多久？”

1.3 场景二：C 端会员等级

用户场景： 一款知识付费 App 提供免费、月度、年度三种会员。免费用户可试听前 3 分钟；月度会员可解锁全部音频，但每月有 50 次下载额度；年度会员无限制下载，额外赠送专属社群身份标识。

业务问题：

• 权益梯度设计缺乏可视化的“升级预期”，用户不知道下一级有什么
• 付费会员与免费会员在同一个页面混排，操作路径模糊
• 会员过期后数据保留策略不透明，引发用户投诉

用户访谈关键问题：

• “您是否清楚当前会员等级能做什么、不能做什么？”
• “哪一个权益是您愿意付费的核心原因？”
• “如果会员过期，您最担心失去什么？”

1.4 场景三：数据可见性边界

用户场景： 一家医疗集团的 HIS 系统中，院长可以看到全院的门诊量、收入、药占比；科室主任只能看到本科室的运营数据，且不可查看患者姓名；一线医生只能看到自己经手的患者列表，且不可查看费用明细中的药价加成。

业务问题：

• 行级权限：同一张报表，不同角色看到不同的数据行
• 列级权限：同一行数据，不同角色看到不同的字段
• 数据边界与组织结构不匹配，科室合并/拆分后权限逻辑崩溃

用户访谈关键问题：

• “您最不希望哪些人看到您的工作数据？”
• “当您需要跨部门协作时，数据壁垒是否影响了效率？”
• “如果您看到的数据中出现了不该看到的信息，您会怎么处理？”

1.5 三大场景的结构化对比

1.6 需求拆解与方案表达

权限交互的需求拆解遵循“场景 → 角色 → 资源 → 操作 → 约束”五层法。以一个 B 端 CRM 的“客户详情页”为例：

1.7 验收标准与交付物模板

验收标准（三大场景通用）：

• 每个角色按矩阵表访问对应菜单，无遗漏、无越权
• 同一条数据在不同角色下显示不同字段（列级权限）
• 同一张列表在不同角色下显示不同数据行（行级权限）
• 会员等级切换后，页面状态在 1 次交互内刷新正确
• 数据边界变更（如组织调整）后，权限配置可追溯、可回滚

交付物模板（本章结课输出）：