在功能介绍里保留适用限制，空结果也需要解释条件，把撤销范围交代给使用者

在功能介绍里保留适用限制

帮助内容应围绕任务，而不是只列页面上的控件。

页面简洁与信息可发现，需要放在一起考虑。

空结果也需要解释条件

事务范围过大时，外部等待可能拖住本来能够快速完成的写入。可以先梳理哪些状态必须同时改变，哪些后续步骤允许异步完成，再决定边界。讨论应同时包括失败后的补偿方式，避免为了缩短事务而把一致性问题转移到没有人负责的角落。

清楚的入口名称可以减少理解内部术语的负担。

错误提示应解释当前影响，并提供合适的下一步。

把撤销范围交代给使用者

文档中连续按下撤销时，使用者期待每一步对应可以理解的编辑意图。若一次输入被拆成许多细小步骤，恢复过程会显得冗长；若多个独立动作被合成一步，又可能误撤其他修改。组织历史时，可以依据编辑行为的边界，而非只按底层事件数量分组。

交互页面的简洁应与信息是否容易发现一起评估。

历史记录应帮助理解变化，而不仅显示有人操作。