空结果也需要解释条件
历史记录应帮助理解变化，而不仅显示有人操作。
结果暂时不明时，应提供可查询的状态线索。
从通知时机理解消息价值
故障排查文档可以先从使用者看得见的现象开始。无法打开文件可能对应多种原因，直接要求检查某个内部服务未必适合所有人。按现象给出简单判断分支，并说明何时需要求助，可以让读者逐步收集有效信息，也避免未经理解就执行具有额外影响的操作。
页面简洁与信息可发现，需要放在一起考虑。
通知需要说明为什么在此刻出现。
在取消之后说明当前结果
随机测试需要保留可重现的线索。一次偶然输入揭示问题后，若没有记录生成条件，后续很难确认修复是否覆盖。可以保存种子与最小失败样例，再将关键规则转化为稳定检查，让探索得到的发现能够进入日常维护，而不是只存在于一次运行日志中。
交互评审需要包含首次使用与偶尔使用的情境。
一个功能的效果应放在具体使用流程中检查。