在企业综合办公平台会议管理模块中，我先识别申请、审批、参会和场地准备中的不同角色，再用核心与支线场景提炼页面需求，并在交互稿之前处理“是否允许直接修改”的方向性争议。
企业综合办公平台的会议管理模块同时服务会议申请人、审批人、主持人、参与人和会议室管理员。
项目由综合管理部牵头、信息中心主导，目标是把传统线下电话预约会议室的流程迁移到移动端。申请人要确认时间、地点和会务要求，审批人、主持人、参与人和会议室管理员还要继续接收各自的任务。
原有方式依赖电话与综合办反复确认。开始时间、结束时间、会议主题、主持人、参会人员、议程、详情和会务要求都要逐项沟通；遇到无可用会议室、取消或修改会议时，还会产生新的协调和通知。
会议申请并不是单一表单，而是一条跨角色协作链。
工程部 · 员工
因 A 项目图纸评审会，需要申请合适的会议室。
工程部 · 行政主管
核实申请内容，完成会议室申请审批。
工程部 · 项目经理
参与并主持 A 项目图纸评审会。
工程部 · 技术主管
参与 A 项目图纸评审会，及时获知会议安排。
综合办 · 员工
会前开门，并按要求准备茶水、投影等会务。
角色边界明确后，后续场景才能同时覆盖申请操作、审核内容、通知对象和场地准备。
| SCENARIO场景任务 | 张 会议申请人张文涛 |
杨 会议审批人杨威 |
周 会议主持人周尧 |
李 会议参与人李大鹏 |
刘 会议室管理员刘燕南 |
|---|---|---|---|---|---|
| 核心申请会议 | 完成会议申请 | 核实申请内容，审批会议申请 | 接收会议通知，获知自己是会议主持人 | 接收会议通知 | 接收会议室预订通知，准备会务要求 |
| 支线 01无可用会议室 | 查看会议室占用人，考虑是否可以协商 | —不参与该场景 | —不参与该场景 | —不参与该场景 | —不参与该场景 |
| 支线 02取消会议 | 取消已申请的会议 | —不参与该场景 | 及时获知会议取消通知 | 及时获知会议取消通知 | 及时获知会议室预订取消通知 |
| 初版支线 03修改会议 | 查看会议室占用人，调整会议信息 | 核实修改内容，审批会议申请 | 及时获知变动后的会议信息 | 及时获知变动后的会议信息 | 及时获知变动后的会议室预订信息 |
他先按开始时间和借用时长筛选可用会议室，再查看地点、规模、座位数、投影和预约情况，最后填写主题、主持人、参会人、议程、详情与会务要求。
申请提交后，杨威审核完整信息；周尧和李大鹏接收会议通知；刘燕南根据地点和会务要求安排场地。一次提交会触发多条后续任务。
这些支线把申请记录、空状态、预约明细、取消确认和消息通知带入需求范围，也暴露出“直接修改”会增加任务与通知复杂度。
我将需求精简为两类：用户需要在界面上看到什么，以及用户需要对这些对象做什么。这样，故事可以直接转化为页面级清单。
会议室照片、地址、规模、座位、设备、预约情况，以及会议主题、状态、人员、时间、会务、审核信息。
时间选择、可用筛选、会议室确认、信息填写、申请记录、取消申请，以及初版中的修改入口。
申请入口 + 申请记录入口
时间筛选 + 会议室列表 + 空状态
空间信息 + 预约情况 + 确认入口
人员、议程、详情与会务要求
申请将由部门行政主管审核
提交反馈 + 审核人信息
地点、时间、状态与申请时间
完整信息 + 未开始会议的取消入口
取消通知已发送给相关会议角色
取消反馈 + 多角色通知
初版独立修改路径 · 最终移除
初版用于反馈修改结果与审核人信息
初版结果反馈页 · 最终移除
初版需求包含独立修改入口。产品同事提出异议后，我重新比较个人操作效率、任务学习成本、通知复杂度和协作稳定性，没有把“少一步操作”作为唯一目标。
普通员工账号不提供前台直接修改。申请有变化时，先取消原申请，再重新提交；确认提交前明确告知“提交后无法直接修改”。行政管理员保留后台修改权限，用于紧急、特殊的会议调整。
找到需要变更的会议申请。
原参会对象收到会议取消通知。
按新时间与人数选择会议室。
补齐新的人员、议程和会务信息。
审批通过后发送新的会议通知。
这条普通员工路径更长，但任务类型更少，提醒含义也更清楚；行政管理员则通过后台权限处理紧急和特殊变更。设计没有把“少一步操作”作为唯一目标，而是用权限分层同时处理协作效率与责任边界。
上线前，项目招募 10 名不同岗位、不同年龄段员工完成任务测试；2020 年 6 月随移动端办公平台 2.0 全量上线后，继续跟踪三个月业务数据与全员满意度反馈。
上线前测试：10 名员工；上线后数据：全量上线三个月统计。
评价集中在“预约便捷”和“会议室占用状态透明”；取消会议任务完成率为 100%。
主要来自高频组织会议的行政岗，诉求是开放快捷修改入口，该需求进入下一迭代计划。
申请人发起会议，审批人确认申请，主持人和参与人接收安排，会议室管理员准备场地；同一条流程在不同角色手里有不同任务。
确定时间、人数、时长和场地要求，为筛选会议室设定范围。
查看容量、座位、投影和预约情况，选出可执行的场地。
补充主题、主持人、参会人、议程、详情与会务要求，交给审批人确认。
时间或地点变化时取消原申请并重新提交，保持场地和通知信息一致。
申请提交后获得明确的待办入口，知道哪一项会议需要处理。
核对时间、人员、议程、详情和会务要求，避免只看会议主题做判断。
确认申请是否通过，让后续会议通知和场地准备有明确依据。
原会议取消后，重新申请会再次进入审批链，保证变更有记录可追踪。
明确需要讨论的事项和参与对象，为申请人填写会议内容提供依据。
审批通过后查看会议主题、时间和地点，确认自己承担主持任务。
根据议程和会务要求组织会议，确保场地与参会安排匹配。
收到取消或新的会议通知后调整安排，避免按旧时间组织会议。
申请前没有主动操作，等待组织者完成申请和审批。
审批通过后收到会议主题、时间和地点，获得参加会议所需信息。
根据最新通知准备并到场，不需要介入申请和审批过程。
会议取消或重新申请后及时获知变化，避免前往旧地点或旧时间。
记录会议室的预约情况，让申请人能判断哪些场地可用。
审批通过后获得会议时间、地点和会务要求，开始准备场地。
按会议时间提前开门，并准备投影、茶水等会务条件。
收到取消或新的会议通知后更新占用记录，避免会议室被错误锁定。
| 角色 | 申请前 | 申请与审批中 | 会议前 / 变更时 |
|---|---|---|---|
| 申请人 | 确认时间、人数和场地条件 | 填写申请并知道审核人 | 取消或重新申请 |
| 审批人 | 等待待办 | 查看完整申请并审批 | 收到取消或新的申请 |
| 主持人 | 提出会议安排 | 等待会议通知 | 确认时间、地点和变更 |
| 会议参与人 | 无主动任务 | 接收会议通知 | 记录安排或接收取消通知 |
| 会议室管理员 | 维护会议室占用 | 接收场地与会务信息 | 准备场地或释放资源 |
页面 09、10 属于初版员工端“直接修改”方案。最终从普通员工端移除，变更复用取消与重新申请流程；行政管理员的后台修改不在这组移动端页面范围内。
它们分别对应会议通过、取消和变更，连接申请人、审批人、主持人、参与人和会议室管理员。
审批通过后，会议主持人、会议参与人和会议室管理员收到新的会议安排。
申请取消后，相关角色收到明确的取消通知，场地资源随之释放。
普通员工端用取消提醒和新的会议提醒替代；行政管理员通过后台紧急修改时，仍需向相关角色说明变化。
争议的关键不在表单能否复用，而在任务学习成本、消息复杂度、申请责任和办公效率之间如何取舍。
路径更短，但要同时处理修改字段与多类变更提醒。
普通员工端只保留申请与取消，降低学习成本，让通知含义更清楚。
普通员工采用；行政管理员保留后台直接修改权限。
| 判断维度 | 员工端直接修改 | 普通员工取消后重提 |
|---|---|---|
| 个人操作效率 | 保留已填内容，路径更短 | 需要重走申请流程 |
| 任务学习成本 | 需要理解申请、修改、取消 | 只需理解申请与取消 |
| 通知复杂度 | 需区分地点、人员、议题与会务变更 | 取消通知与新会议通知含义明确 |
| 协作稳定性 | 变更门槛低，可能增加多方确认 | 提高变更成本，促使首次提交更谨慎 |
| 最终结论 | 普通员工端不采用；行政后台保留 | 普通员工采用，并在提交前说明无法直接修改 |
围绕高频组织会议的行政岗，细化后台快捷修改流程并验证紧急场景下的操作效率。
补充分层权限、审计记录和变更通知规则，确保管理员例外权限可追溯。
继续观察普通员工取消后重新申请时的重复填写、遗漏和中途退出情况。