简介这份文档以会议申请功能为切入点系统讲解To B产品设计中角色与场景分析的方法面向产品经理、交互设计师及企业办公系统开发者帮助解决B端产品用户理解笼统、需求重点混乱的问题。资源为单个doc文档压缩包约44KB内容围绕申请人、审批人、主持人、参与人、场地管理人员五类角色展开构建典型人物模型并通过申请会议室、审批、通知接收、异常处理等情境场景还原真实使用路径。文中还以与产品经理的争议为例探讨用户体验与产品目标之间的权衡思路展示如何在设计初期统一团队认知。目前已有36人学习适合需要掌握B端角色建模与场景叙事方法、提升需求分析能力的从业者参考。1. 会议申请功能为什么是 To B 角色与场景分析的最佳切片做过 To B 产品的人大概都有过这种体验需求评审会上业务方说“加个会议申请”研发觉得三天能上线结果做完发现行政嫌流程太长、销售嫌审批太慢、财务说预算字段对不上、IT 管理员抱怨权限没法配。一个看起来只是“填个表单走个审批”的功能最后变成五个角色互相拉扯的战场。这不是团队能力问题而是 To B 产品天然的多角色、多场景属性决定的——它从来不是服务一个人而是服务一条决策链。会议申请这个功能之所以适合拿来练角色与场景分析是因为它足够小、足够完整、又足够典型。它同时踩中了 To B 产品的几个核心特征有明确的发起者、审批者、执行者、被影响者有资源占用会议室、设备、时间有跨部门协作有权限边界还有可量化的成功标准审批时长、会议室利用率、冲突率。你把这一个功能拆透了换到报销、采购、请假、工单方法论是通用的。这篇文章面向的是正在做或准备做 To B 产品的交互设计师、产品经理以及需要理解业务侧诉求的前端工程师。我会按“先立住角色与场景的分析框架再落到会议申请的具体设计最后讲清楚踩过的坑和验证方法”这条线走中间给到可以直接抄的字段表、状态机和权限矩阵。读完你应该能独立完成一个 To B 功能的角色场景分析并且知道哪些地方最容易翻车。2. 角色与场景分析框架从干系人地图到场景剧本2.1 先分清“用户”和“干系人”别把角色分析做成用户画像To B 产品最容易犯的第一个错误是把角色分析做成了 C 端那套用户画像——年龄、职位、使用习惯。这套东西在 To B 里几乎没用因为 To B 的“角色”本质是权限与责任的集合不是性格标签。一个人可能同时是审批者和被审批者取决于他在哪条流程上。我一般用干系人地图来起手分四层层级定义会议申请中的例子关注点发起者主动触发流程的人需要开会的员工填得快、少填字段、知道进度审批者决定流程能否继续的人直属主管、行政、财务判断依据充分、批量处理、可追溯执行者流程通过后负责落地的人行政专员、IT 运维资源可调度、冲突可预警被影响者不操作但受结果影响的人同会议室的其他预约人、参会者不被冲突、准时收到通知这张表的价值在于它逼你在写需求前就想清楚“谁操作、谁决策、谁承担后果”。很多会议申请功能上线后被吐槽就是因为只考虑了发起者和审批者把执行者和被影响者漏了。提示干系人地图不是画完就完每个角色后面要跟一句“他如果不满意会怎么绕过这个功能”。绕过方式往往就是下一个版本要补的洞。2.2 场景剧本要写到“触发条件 约束 成功标准”三件套角色定完了接下来是场景。To B 的场景分析不能写成“用户想要开会”这种废话得写成可验证的剧本。我习惯用三件套模板触发条件什么情况下这个场景被激活约束时间、权限、资源、合规上的硬限制成功标准怎么判断这个场景被满足了以会议申请为例拆出四个典型场景场景 A常规内部周会触发条件是员工每周固定要开部门会。约束是只能预约本部门可用会议室、时长不超过 2 小时、提前 1 天申请。成功标准是审批在 4 小时内完成、会议室无冲突、参会人收到日历邀请。场景 B跨部门评审会触发条件是项目需要多个部门参与决策。约束是参会人跨部门、需要外部会议室、可能需要设备投影、视频。成功标准是所有部门审批人都通过、设备被预留、会议纪要模板自动附带。场景 C紧急临时会议触发条件是突发问题需要立即讨论。约束是提前时间小于 30 分钟、可能走加急审批通道、允许占用已预约但未开始的会议室。成功标准是 10 分钟内完成审批、冲突会议室被自动协调。场景 D外部客户接待会触发条件是接待来访客户。约束是涉及保密、需要前台登记、可能需要茶歇。成功标准是审批链包含行政和安全、访客信息被记录、接待资源到位。这四个场景一摆出来你会发现字段需求、审批链、权限规则全都不一样。如果只做一个“通用会议申请”结果就是每个场景都用得不顺手。常见做法是主流程统一用场景标签驱动差异化字段和审批链。2.3 用状态机把角色和场景串起来角色和场景分析的最后一步是把它们落到状态机上。状态机是 To B 产品的骨架它决定了每个角色在什么状态下能做什么。会议申请的状态机大致如下草稿 → 待审批 → 审批中 → 已通过 → 执行中 → 已完成 ↓ ↓ 已驳回 已取消每个状态对应一组角色权限状态发起者审批者执行者被影响者草稿编辑/删除不可见不可见不可见待审批可撤回可审批不可见不可见审批中只读可审批可预览不可见已通过只读只读可调度收到通知执行中只读只读可调整可查看已驳回可修改重提只读不可见不可见已取消只读只读释放资源收到取消通知这张表是后面所有交互设计的依据。你会发现“被影响者”在早期状态是不可见的这是有意的——避免会议室还没批下来就通知一堆人最后改时间又要挨个解释。这个细节后面避坑章节还会提到。3. 会议申请功能的字段、审批链与权限设计3.1 字段设计必填项越少流程跑得越快字段设计是 To B 产品里最容易被低估的环节。每多一个必填字段发起者的完成率就掉一截。我的原则是能自动带出的不让人填能后补的不设为必填能默认的不让人选。会议申请的字段分三组基础信息组必填会议主题文本20 字以内会议时间日期时间范围选择器起止时间参会人组织架构选择器支持多选会议室根据时间和人数自动筛选可用项场景信息组按场景标签动态显示场景类型单选内部周会/跨部门评审/紧急会议/外部接待会议设备多选投影/视频/白板仅跨部门和外部场景显示访客信息文本仅外部接待场景显示加急理由文本仅紧急会议场景显示审批信息组系统自动填充只读审批链根据发起人部门和场景类型自动生成预算归属从发起人所属项目自动带出冲突提示实时检测同时间段会议室占用字段的显示逻辑用场景标签驱动伪代码如下// 根据场景类型动态计算需要显示的字段 const fieldVisibility { internal: [topic, time, attendees, room], crossDept: [topic, time, attendees, room, equipment], urgent: [topic, time, attendees, room, urgentReason], external: [topic, time, attendees, room, equipment, visitorInfo] }; function getVisibleFields(sceneType) { // 基础字段始终显示场景字段按配置追加 return fieldVisibility[sceneType] || fieldVisibility.internal; }这段逻辑的关键点是基础字段永远存在场景字段按需追加。这样既保证了主流程统一又让每个场景有差异化。参数上sceneType由用户在表单顶部选择切换时已填内容保留只增减场景字段避免用户重填。注意动态字段一定要做“切换场景后已填内容不丢失”。我见过一个版本切换场景直接把表单清空用户骂了三个月。3.2 审批链设计串行、并行、条件分支怎么选审批链是 To B 产品的灵魂也是最容易设计错的地方。会议申请的审批链有三种模式串行审批A 批完 B 批B 批完 C 批。适合有严格层级关系的场景比如外部接待需要主管→行政→安全。缺点是慢任何一环卡住整个流程就停。并行审批A、B、C 同时收到审批全部通过才继续。适合互不依赖的审批比如跨部门评审需要各部门负责人同时确认。优点是快缺点是任何一个人不批就卡住。条件分支根据字段值走不同审批链。比如时长超过 4 小时自动加一级审批涉及外部访客自动加安全审批。实际项目里我一般用组合模式主链串行节点内并行关键字段触发条件分支。配置结构大致如下{ approvalChain: { type: serial, nodes: [ { name: 直属主管, type: single, resolver: directManager }, { name: 部门负责人, type: parallel, resolvers: [deptHead, financeOwner], condition: duration 4h || sceneType external }, { name: 行政, type: single, resolver: adminOwner, condition: sceneType external } ] } }参数说明type决定节点内是单人还是多人resolver是审批人解析规则通常从组织架构和角色映射里取condition是触发条件不满足时该节点跳过。这套结构的好处是审批链可以配置化不用每次改流程都发版。审批链设计里有个血泪经验一定要给审批人“转交”和“加签”能力。主管出差、财务换人、行政临时不在这些情况在真实企业里天天发生。没有转交流程就死在那一环最后大家绕回线下签字系统白做。3.3 权限矩阵谁能看、谁能改、谁能删权限设计要回答三个问题数据可见性、操作可行性、历史可追溯性。会议申请的权限矩阵按角色和状态两个维度展开操作发起者审批者执行者管理员查看详情自己的待自己审批的已通过的全部编辑草稿/驳回不可不可全部撤回待审批不可不可全部审批不可待自己审批的不可不可取消已通过未开始不可已通过未开始全部导出自己的审批过的执行过的全部这张表里有两个容易忽略的点。第一审批者只能看到待自己审批的单子不能看到全公司的会议申请否则就是隐私泄露。第二执行者的取消权限和发起者重叠因为行政在资源冲突时也需要取消已通过的会议这时候要记录取消原因并通知发起者。权限实现上我一般用 RBAC基于角色的访问控制加数据行级过滤。角色决定能做什么操作数据过滤决定能看到哪些行。两者分开配置起来清晰排查问题也快。4. 交互设计把多角色流程做成不打架的界面4.1 发起端一屏填完实时反馈冲突发起端的核心目标是降低填写成本、提前暴露冲突。会议申请表单我坚持一屏填完不搞分步向导——分步在 C 端注册流程里好用在 To B 高频操作里是负担。关键交互点有三个时间选择器联动会议室可用性。用户选完时间会议室下拉框只显示该时段可用的房间并标注容量和设备。这个联动要在前端做防抖避免每次改时间都打一次接口。// 时间变化后查询可用会议室300ms 防抖 let timer null; function onTimeChange(timeRange) { clearTimeout(timer); timer setTimeout(async () { const rooms await fetchAvailableRooms({ start: timeRange.start, end: timeRange.end, capacity: attendeeCount }); renderRoomOptions(rooms); }, 300); }参数说明start和end是时间戳capacity是参会人数。接口返回的rooms里每项带conflict: true/false前端把冲突项置灰并提示“该时段已被占用”。参会人选择器支持组织架构树和最近联系人。To B 用户开会对象相对固定最近联系人能省掉大量翻组织架构的时间。提交前做一次全量校验。时间、会议室、参会人、审批链四项都确认无误再提交避免提交后被打回重填。4.2 审批端批量处理和一键通过是刚需审批端的使用频率远低于发起端但单次处理量大。主管可能一周攒了二十个会议申请你让他一个个点开看再批他一定骂人。审批端的设计要点列表页直接展示关键信息主题、时间、会议室、发起人、冲突提示。审批人不用点进去就能判断。支持批量通过和批量驳回。勾选多条一次操作。驳回时必须填原因通过可以不填。审批详情页突出决策依据这个会议和我的日程有没有冲突、会议室是否紧张、预算是否超支。把这些信息放在审批按钮旁边减少审批人来回查的成本。移动端审批要能用。很多主管只在手机上批流程如果移动端体验差流程就卡在他那里。移动端至少要做到列表可批、详情可看、通过驳回可操作。4.3 执行端与被影响者通知的时机和粒度执行端行政、IT关注的是资源调度被影响者关注的是“我的会议会不会被挤掉”。这两类角色的交互核心是通知的时机和粒度。通知时机上我遵循“状态变更即通知但分角色分内容”提交成功只通知发起者审批通过通知发起者、参会人、执行者审批驳回只通知发起者会议取消通知所有相关方会议变更时间/地点通知所有相关方且要求确认通知粒度上参会人只需要知道时间地点执行者需要知道设备和资源需求被影响者只需要知道“你关注的会议室被占用了”。用同一套通知模板发给所有人是典型的偷懒做法结果是所有人都觉得通知没用直接屏蔽。提示通知一定要给“免打扰”选项。To B 用户被通知轰炸后第一反应是关掉整个系统的通知权限那你就再也叫不醒他了。5. 避坑与排查会议申请功能上线后最容易翻车的五件事5.1 现象审批人看不到待审批的单子原因审批人解析规则依赖组织架构但发起人所在部门刚调整组织架构同步有延迟导致审批人解析为空单子卡在“待审批”但没人收到。解决审批链生成时做兜底——解析不到审批人时自动上溯到上一级或转给管理员并记录异常日志。同时组织架构同步要做增量更新别等全量同步。5.2 现象同一会议室被重复预约原因并发提交时两个请求同时查到会议室可用都通过了校验。这是典型的竞态条件。解决会议室占用要做数据库层面的唯一约束或分布式锁不能只靠前端校验。提交时用“查询占用”原子操作冲突则返回失败让用户重选。5.3 现象用户切换场景后表单被清空原因动态字段实现时用了重新渲染整个表单的方式没有保留已填值。解决字段显隐用 CSS 控制或条件渲染但表单状态要统一管理切换场景只增减字段不清空已有值。这个坑我在两个项目里都见过属于低级但高频。5.4 现象移动端审批按钮点不动原因审批按钮的点击区域太小或者被固定底栏遮挡或者移动端没做适配直接用了 PC 端组件。解决移动端按钮最小点击区域 44x44px固定底栏要留出安全区审批操作单独做移动端组件。上线前一定要在真机上点一遍模拟器不算数。5.5 现象会议取消后参会人没收到通知原因取消操作只更新了会议状态没有触发通知任务。或者通知任务依赖的消息队列积压延迟发送。解决状态变更和通知发送要做成事务性操作至少保证“状态变更成功则通知必发”。消息队列要有监控和重试积压超过阈值要告警。6. 用角色场景矩阵验证你的会议申请设计设计做完不等于做对。我一般用一个角色场景矩阵来做验证横轴是角色纵轴是场景交叉点是该角色在该场景下的核心诉求和验证方法。场景发起者审批者执行者被影响者内部周会3 步内提交列表直接批无需介入无感知跨部门评审自动带出参会人并行审批不卡设备预留确认无感知紧急会议加急通道可见10 分钟内响应冲突协调收到协调通知外部接待访客信息一次填多级审批可追溯接待资源到位无感知验证方法上我习惯用两个指标卡流程完成率和平均审批时长。完成率低于 80%说明字段或流程有问题审批时长超过 24 小时说明审批链或通知有问题。这两个指标不用等上线用可点击原型做一轮用户测试就能估出来。最后一个技巧把会议申请的状态机打印出来贴在工位上。每次讨论需求先指状态机问“这个需求改的是哪个状态、哪个角色的权限”。大部分争论会在这个问题面前自动收敛。我自己做 To B 产品这些年最大的教训就是——角色和场景分析不是文档里的一章而是每次需求评审都要重新过一遍的检查清单。跳过它后面全是后悔药。希望帮到你。本文还有配套的精品资源点击获取