多人编辑冲突发生时,用户最担心的是自己的修改消失。设计应先保存变更来源,再让用户选择合并、保留或恢复。用在线原型设计把两个协作者的编辑路径连起来,能验证冲突提示是否出现在正确的对象附近。

及时说明谁正在改什么
对象被另一位成员选中时,显示头像、姓名或颜色标识;真正发生冲突时,再说明具体属性或版本。不要把“有人在线”写成“文件被锁定”,在线不代表所有区域都不可编辑。

锁定、合并和并行编辑的取舍
| 策略 | 适合场景 | 界面要说明 |
|---|---|---|
| 短暂锁定 | 同一对象无法拆分 | 锁定者和预计释放条件 |
| 属性合并 | 文字、颜色等可分开处理 | 哪些属性来自哪一版 |
| 版本选择 | 改动范围大或难以合并 | 预览差异和可恢复性 |
差异对比要让人看得懂
差异视图同时展示当前版本和待合并版本,标出新增、删除和移动。涉及组件时说明实例是否会跟随更新;不要只列一串时间戳。用户选择后,在提交前保留变更摘要,便于确认没有误选。
恢复不是简单的撤销按钮
恢复前告知会影响哪些对象、能否再次回到当前版本以及其他协作者是否会收到通知。网络超时只说明结果未知,应先查询状态再重试。恢复成功后,画布、版本列表和通知中心要显示同一结果。
原型检查清单
- 两位协作者同时改同一对象,是否都能看到冲突来源?
- 合并失败时是否保留两份可比较的版本?
- 恢复后能否再次查看被替换的内容?
- 窄屏上差异面板是否仍能完成选择?
把冲突路径当作主流程的一部分,团队评审才不会只验证顺利保存的情况。
先保存,再让用户选择
冲突提示出现时,系统应先保留本地草稿或生成临时版本,再展示选择。用户不应因为关闭提示就失去编辑内容。对于文字、颜色和布局等可拆分属性,分别列出冲突;对于组件结构变化,提供版本预览和明确的覆盖范围。
两位协作者同时改标题时,可以显示“你的版本”和“对方版本”,让用户选择一方或手动合并。若一方已删除对象,另一方仍在编辑,应提示对象被删除并提供恢复或复制到新对象的选项,而不是静默恢复旧状态。
评审与恢复路径
在原型中模拟成员甲改按钮颜色、成员乙改按钮文案,再让甲提交。差异面板显示两项可独立合并;如果成员乙随后删除整个按钮,页面转为结构冲突并显示被删除前的预览。恢复成功后,评论线程和版本时间线要能追到同一结果。
交付前检查
- 冲突发生前是否有清晰的协作者和对象提示?
- 合并、覆盖、复制和恢复的影响范围是否可预览?
- 请求超时后是否先查询状态,避免重复提交?
- 移动端差异面板是否能完成选择和确认?
通知与审计不要打扰工作
冲突结果可以在对象旁给出即时提示,在活动记录中保留详细变更。通知内容包含对象、操作者和结果即可,避免把完整差异塞进弹窗。用户回到文件时仍能从版本时间线查看被合并或恢复的内容。
网络中断后重新连接可能带来连续冲突。界面先标记“连接已恢复,正在同步”,同步完成前不显示确定成功。若同步失败,给出查看本地草稿和重新比较的入口,不要自动覆盖本地修改。
把冲突场景加入回归用例:文字属性、组件属性、删除对象、移动对象和评论线程各测一次。不同对象的合并策略可能不同,不能只用一个通用弹窗覆盖所有情况。
组件变更的合并范围
文字、颜色、位置和组件结构可以采用不同的合并策略。设计稿把这些属性拆开标注,避免出现“合并全部”却无法解释的按钮。对于不可自动合并的对象,优先提供复制为新对象和查看旧版本,而不是强制覆盖。
冲突状态要有过期处理:如果对方已经完成编辑,提示可刷新并重新比较;如果本地草稿超过保存周期,提示保存到临时版本。用户关闭页面前仍需说明是否有未同步修改。
验收用两台设备和不同网络速度模拟,检查同步、评论、版本和通知是否最终一致。视觉上看似成功不代表数据已经写入。
不同内容需要不同合并策略
文字段落可以提供逐句选择,颜色与尺寸可以提供属性级差异,组件结构则需要版本级预览。把这些策略写在交互说明里,用户才能理解为什么某些冲突能自动合并,某些必须手动选择。
评论线程也可能发生冲突:一条评论被解决后,另一人仍在引用它。合并后保留引用关系和解决时间,若评论对象已删除,提供迁移到新对象或查看历史的入口。
如果冲突数量太多,可以先按对象分组,允许用户逐组处理并暂存进度。不要用一个“全部保留我的版本”按钮隐藏具体风险,除非产品能提供可逆版本和明确影响范围。
交付时明确可逆性
每个冲突操作都写明是否可撤销、恢复哪一版、通知谁以及失败后的下一步。组件结构冲突和文字冲突不要共用同一套描述,测试数据也应覆盖删除和移动对象。
把本地草稿、服务端版本和临时合并结果分别命名,评审者才能判断用户会看到哪一份内容。
回放离线与重连
先断网编辑,再在另一设备修改同一对象,最后恢复网络。记录本地草稿、服务端版本、冲突提示和合并结果,检查没有任何一份变更被静默覆盖。
按对象类型准备冲突数据
文字、颜色、移动、删除和评论分别准备冲突样本,记录每种样本的自动合并或人工选择规则。这样评审者不会把一次简单文字冲突的结果误认为所有对象都能自动处理。
把冲突处理完成后的版本号、操作者和通知内容也放进原型,检查画布、版本列表和活动记录是否描述同一个结果。
交付时把冲突样本和预期结果保存到版本记录,后续组件升级或同步协议变化后重新回放。只要仍能找回本地稿、服务版本和合并结果,用户才真正拥有恢复能力。
把本地稿和服务器版本的保留期限写入产品说明,用户才能知道离线修改何时会被清理。恢复能力需要明确边界,不能依赖模糊的“历史版本”字样。
如果用户选择保留自己的版本,界面仍应允许查看对方版本和后续恢复。把“当前内容”“待合并内容”“合并结果”区分命名,版本时间线和通知也使用相同名称,减少误操作。