To B产品会议申请模块设计：角色分析与场景推演实战

简介这份文档以某公司办公管理系统APP的会议申请功能为实例系统讲解To B产品设计中角色与场景分析的方法面向产品经理、交互设计师及对B端产品设计感兴趣的从业者帮助解决角色划分笼统、需求重点混乱、用户体验与产品目标难以权衡等实际问题。资源包共1个doc文件大小约44KB内容围绕申请人、审批人、主持人、参与人、场地管理人员五类角色展开建立典型人物模型并通过核心场景、支线场景与异常场景的叙事还原真实使用路径。文中还以与产品经理的争议为例探讨交互设计初期如何借助情境场景统一团队思路并分析数据追踪与用户体验之间的平衡点。目前已有36人学习适合需要掌握B端角色建模与场景推演方法、提升需求分析能力的读者参考借鉴。1. 会议申请功能拆解To B 产品角色与场景分析到底怎么落地做过 To B 办公系统的交互设计师大概都有过这种经历需求评审会上产品经理一句“加个修改会议功能”你觉得理所当然开发排期也加上了上线后却发现推送通知满天飞、审批人收到一堆重复提醒、中老年用户根本分不清“修改”和“取消再申请”的区别。问题出在哪不是交互稿画得不好而是角色和场景分析这一步被跳过了。这份文档以某公司办公管理系统 APP 的会议申请模块为案例完整走了一遍从角色分析、人物模型、情境场景到需求提炼的流程最后还记录了一场与产品经理关于“是否支持修改会议”的真实争议。它适合正在做 To B 产品交互设计、需求分析或产品规划的人尤其是那些面对多角色、多场景、多异常分支时容易“拍脑袋”的从业者。文档本身不是代码包而是一套可复用的分析方法论加完整案例推演下面我按落地路径把它拆开讲。2. 角色分析与人物模型五个典型岗位怎么划出来2.1 为什么 To B 的角色分析不能照搬 To C 那套To C 产品做用户画像时我们习惯从年龄、性别、兴趣、消费能力、生活方式这些维度切入因为 C 端用户的角色往往跟家庭角色、个人态度、兴趣偏好强相关。但 To B 产品完全不是这个逻辑。文档里说得很直接在 To B 产品中角色常与工作角色或职责相对应用户的目标和行为受性格、能力、经验的影响较小而受企业内岗位职能的影响较大。这句话翻译成实操语言就是你不需要知道张文涛是 28 岁还是 45 岁、喜欢 iOS 还是 Android、平时用不用小红书你只需要知道他是一个“项目助理”他的核心任务是接到主管指令后快速订到合适的会议室。他的行为路径由岗位职责决定不由个人偏好决定。这带来一个直接后果To B 产品的目标用户通常比 To C 更宽泛需要为不同岗位职能、不同部门、不同需求的特定个体类型分别设计。认知负担和导航成本天然高于 To C。所以角色分析的第一步不是画同理心地图而是先把“一场会议从发起到结束到底牵扯哪些岗位”列清楚。2.2 从会议生命周期反推五类角色文档给出的方法是围绕“一场会议的进行”这个核心事件反推所有相关方。具体到会议申请模块目标用户包括申请人、审批人、参与人员含普通参与人员和主持人、场地管理人员。这五类角色对应到案例中的人物是角色案例人物岗位职能核心诉求申请人张文涛项目助理快速筛选可用会议室、填写会议信息、提交审批审批人杨威部门行政主管快速浏览申请详情、判断是否批准、减少琐碎沟通主持人周尧项目主管接收会议通知、确认时间地点、安排日程普通参与人李大鹏技术主管接收通知、记住时间地点、会前查看详情场地管理员刘燕南会议室管理接收通知、记录会议安排、提前准备设备和茶水这张表的价值在于它把“用户”这个笼统概念拆成了五个行为路径完全不同的个体。张文涛需要的是“筛选和填写”杨威需要的是“快速审批”周尧需要的是“日程确认”李大鹏需要的是“通知接收”刘燕南需要的是“资源准备”。如果只写“用户需要申请会议室”这五条路径的差异就被抹平了后续设计必然出问题。注意人物模型的数量不是越多越好。文档里选了 5 个是因为这 5 个岗位在会议申请这个场景中都有独立且不可合并的行为路径。如果某个角色只是“偶尔看看通知”没有独立操作就不需要单独建模。2.3 人物模型怎么建才不流于形式很多团队做人物模型就是填个模板姓名、年龄、职位、一句话简介然后贴墙上吃灰。文档里的做法更实用人物模型只保留与场景相关的职能信息不写无关的个人特征。比如张文涛的模型里关键信息是“项目助理”“需要快速订会议室”“对会议室位置有偏好离工程部近”“需要填写会议主题、主持人、参会人员、会务要求”。这些信息直接决定了后续界面需要呈现什么、控件怎么摆。具体操作上我一般会按这个顺序走列出所有与目标功能相关的岗位对每个岗位写出他在该功能中的核心任务一句话写出该任务的关键输入和输出需要看什么、需要填什么、需要提交什么写出该任务中可能出现的异常分支找不到资源、需要取消、需要变更合并行为路径高度重合的角色保留独立路径的角色这套流程走完人物模型就不是一张画像而是一份行为规格说明。文档中五个角色在“申请会议室”核心场景下的行为差异直接对应了后续页面 01 到页面 05 的功能设计。3. 情境场景推演从核心流程到三类支线怎么覆盖3.1 核心场景三个页面完成一次申请文档用叙事方式完整描述了张文涛申请会议室的过程。我把其中的关键交互节点和对应页面拆出来页面 01会议管理模块主页面入口首页点选“会议管理”按钮功能提供“会议室申请”入口页面 02会议申请页面会议室列表信息列出所有可选会议室显示照片、地址、规模、座位数、有无投影功能会议时间控件开始时间按整点和半点提供选项、预计时长按小时数、显示全部/显示可用筛选按钮操作填写时间后筛选点选会议室进入详情页面 03会议室详情页信息会议室关键信息、当前预约情况列表功能确认按钮页面 04会议信息填写页信息会议室名称功能开始时间、结束时间、会议主题、主持人、参会人员、会议日程、会议详情、会务要求视频会议系统、快餐、茶水等的填写/选择控件确认按钮页面 05申请成功提示页信息提交成功文案、审核人信息功能返回主界面入口推送新的会议提醒这里有一个设计细节值得注意张文涛在页面 02 填写开始时间和借用时长后列表从全部会议室筛选为 3 个可用项。这个“先填时间再筛会议室”的顺序比“先选会议室再填时间”更符合实际工作流——因为会议时间通常是上级指定的而会议室是可以灵活调整的。文档没有明确说这个顺序是刻意设计的但从场景推演来看它确实减少了用户的反复操作。3.2 支线场景一无可用会议室时怎么引导张文涛填写时间后筛选结果为空页面提示该时段所有会议室已被预约。他的应对是取消筛选勾选在全部会议室列表中找到目标会议室查看当前预约情况发现是陌生部门后放弃联络改试 4 点时段。这个支线对设计的启示是筛选为空时不能只显示“无结果”要给出温和提示建议换时段需要提供“显示全部”的切换能力让用户能查看被占用的会议室及其预约方会议室详情页需要显示当前预约情况列表方便用户判断是否可以协调文档在需求提炼部分明确写了会议申请页面在筛选结果为空时提供温和的提示文案会议室详情页显示当前预订情况并提供醒目的返回列表按钮。3.3 支线场景二取消会议的完整链路张文涛从“申请记录”进入选中记录进入详情页点击“取消”按钮弹窗确认跳转取消成功页。系统向审批人、主持人、所有参会人员和会议室管理员发送取消通知。这个场景的关键设计点申请记录列表需要显示会议地点、时间、处理状态、申请时间详情页需要展示完整信息地点、主题、审核状态、主持人、议程、时间、参会人员、会务要求、申请时间、审核人、审核理由对已申请但未进行的记录提供“取消申请”按钮取消成功后推送通知覆盖所有相关方3.4 支线场景三修改会议的两种路径文档在这里记录了一个重要变化。初版设计支持“修改会议信息”路径是申请记录详情页点击“修改会议信息”按钮进入修改页面重新选择会议室、修改时间、增删人员确认后提交审批系统发送“会议信息变动”通知。但最终项目采纳了产品方意见改为不支持直接修改需要变更时先取消再重新申请。修改后的场景变成张文涛点击“取消”按钮重新回到会议室列表走新申请流程系统先发“会议取消通知”再发“会议通知”。这个变化直接影响了需求清单页面 07 的“修改会议信息”按钮被移除页面 09会议申请修改页面和页面 10会议修改成功提示页不再需要推送提醒类型从“新会议提醒、会议取消提醒、会议变动提醒”三种简化为“新会议提醒、会议取消提醒”两种。提示支线场景的价值不在于穷举所有可能性而在于识别哪些分支会改变核心流程和页面结构。取消和修改这两个支线一个保留了独立路径一个被合并进取消再申请背后的判断逻辑在下一章展开。4. 需求提炼与避坑从场景到页面清单的转化方法4.1 把叙事场景翻译成信息和功能需求文档引用了《About Face 4》的需求分类对象、动作、情境数据需求、功能需求、情境需求、其他需求但根据项目实践精简为两类信息需求界面上要呈现什么数据和信息和功能需求要提供什么功能和可操作控件。这个精简很务实。To B 产品的设计效率要求高如果每个页面都按完整分类法走一遍时间成本扛不住。两类需求的划分足够支撑后续的信息架构设计。具体转化方法是逐页扫描场景叙事把每个页面中人物“看到的信息”归入信息需求把人物“执行的操作”归入功能需求。以页面 02 为例张文涛看到会议室照片、地址、规模、座位数、有无投影 → 信息需求张文涛填写开始时间和借用时长 → 功能需求时间控件张文涛点击筛选按钮 → 功能需求显示全部/显示可用切换张文涛点选会议室 → 功能需求跳转详情页这套方法的好处是需求不是凭空想的而是从场景里“长”出来的。后续做信息架构时页面之间的跳转关系、每个页面承载的信息量、控件的优先级都有场景依据。4.2 避坑角色和场景分析中最容易翻车的五个点现象一角色划分过粗把审批人和申请人合并成“用户”。原因觉得都是公司员工行为差不多。 解决审批人的核心动作是“浏览和判断”申请人的核心动作是“筛选和填写”两者对界面信息密度和操作效率的要求完全不同。必须分开建模。现象二场景只写正常流程异常分支等到开发阶段才补。原因需求评审时间紧先过主干。 解决文档里三个支线场景无可用会议室、取消、修改都是在设计初期就推演出来的。其中“修改”场景直接引发了与产品经理的争议如果等到交互稿产出后再讨论返工成本会高很多。现象三人物模型写了年龄、爱好等无关信息干扰设计判断。原因套用了 To C 的用户画像模板。 解决To B 人物模型只保留岗位职能、核心任务、关键输入输出、异常分支。张文涛喜欢什么颜色、用什么手机对会议室列表的排序方式没有影响。现象四需求提炼时把“信息需求”和“功能需求”混在一起写。原因没有区分“看到什么”和“能做什么”。 解决信息需求决定界面内容功能需求决定交互控件。分开写之后信息架构的层级关系会更清晰。比如页面 03 的信息需求是“会议室关键信息 当前预订情况”功能需求是“确认按钮 返回列表按钮”两者对应不同的设计决策。现象五场景推演做完就结束没有回头验证角色覆盖度。原因线性推进缺少交叉检查。 解决需求汇总后拿五个角色逐一走一遍页面清单确认每个角色的核心任务都有对应页面和控件支撑。比如刘燕南作为场地管理员她的核心任务是“接收通知、记录安排、准备设备”对应的是推送提醒功能和会议室详情页的预约情况展示。如果遗漏了说明场景推演不完整。5. 用户体验与产品目标的权衡一场争议的完整复盘5.1 争议焦点修改会议到底该不该支持文档最后记录了一场真实争议。产品经理提出已提交的会议申请只支持取消不支持修改。需要变更时取消后重新申请。产品方给出五条理由修改页面与申请页面表单元素基本相同单独设置修改路径没必要地点变化、人员增删、议题改动、会务要求变动需要向多方发送不同推送容易混乱收到变动提醒后用户难以看出哪些地方变了徒增困惑企业内有不熟悉移动端的用户应尽量简化任务和推送类型先收取消提醒再收新会议提醒确实不愉快但较高的犯错成本有助于申请人养成一次性填对的习惯设计师初版方案对前三条有不同看法使用场景不同时即使内容相同单独路径也有助于用户明确位置推送问题可以通过分解用例和差异化提醒内容解决变动字段可以用不同字体样式显示。沟通后产品方理解了这些点。但第四、第五条理由确实值得重新考虑。文档的结论是对会议管理这种面向全公司所有部门和层级的模块简化任务路径和推送类型是有道理的。记住“申请和取消”两种操作比记住“申请、变更、取消”三种的学习成本更低。虽然“取消再申请”人为增加了流程长度和推送数量但对企业应用而言更好地完成产品目标比用户体验更重要。5.2 权衡逻辑什么时候用户体验可以让位于产品目标这个案例的价值不在于“谁对谁错”而在于它展示了一种权衡框架。文档给出的判断逻辑是办公管理平台的最大产品目标是提升办公效率如果变更操作过于便捷频繁变更有损于这一目标人为提高变更操作的时间成本在合理范围内损失用户体验促使用户一次性提交正确信息更有利于效率提升确有变更需求时可以灵活处理局部人员变动电话提醒即可会议内容变动没必要在系统重新发布会务要求变动电话联系管理员即可真正需要取消再申请的只有会议室地点和时间变更这部分需求数量并不高最终项目采纳了产品方意见但在确认提交会议申请时增加文案提醒申请后无法修改有变更需取消后重新提交。5.3 修改后的场景与需求调整修改后的“修改会议”场景变成张文涛点击“取消”按钮重新回到会议室列表走新申请流程。系统先发“会议取消通知”再发“会议通知”。周尧、李大鹏、刘燕南收到取消通知后再收到新会议通知心领神会地明白会议改期了。第一次收到通知的汪鸣则直接记下新时间。对应的需求调整原需求调整后页面 07 提供“修改会议信息”按钮移除只保留“取消申请”按钮页面 09 会议申请修改页面不再需要页面 10 会议修改成功提示页不再需要推送类型新会议提醒、会议取消提醒、会议变动提醒简化为新会议提醒、会议取消提醒提交申请时无额外提示增加文案提醒申请后无法修改这个调整的影响范围清晰可控因为需求清单是按页面和推送类型逐条列出的。如果没有前期扎实的角色和场景分析这种方向性调整很可能拖到交互稿甚至开发阶段才被发现返工成本会高得多。从那以后我每次做 To B 功能设计都会在需求评审前强制走一遍“角色-场景-需求”的完整推演尤其是异常分支和产品目标冲突的部分宁可前期多花两天讨论也不想在开发阶段收到“这个流程走不通”的反馈。希望帮到你。本文还有配套的精品资源点击获取