理想情况下无需文档也能使用
别名: 自解释界面 · 无需文档 · 可学习性 · 首次成功率
概念解释
帮助与文档（help and documentation）是支持层，不能成为主流程的替代品。理想界面通过任务语言、可见选项、状态反馈、合理默认和恢复路径让首次用户完成核心目标；文档服务于复杂规则、异常、管理和后续查询。这条原则的判定方式很具体：把一个未受训用户放到界面前，不给任何说明，看他能不能独立完成核心任务——完不成的每一步失败，都应该先被当作界面设计的缺陷去修，而不是理所当然地归为"需要写文档解释一下"。
机制
用户遇到困难时的真实顺序是先试探界面、卡住之后才去找帮助，而不是反过来。要求用户先读手册再动手，等于把学习成本提前搬到任务开始之前，这对愿意投入时间的核心用户影响不大，却会直接筛掉大量只是想临时试一次的用户——他们在第一步就放弃了，根本不会给界面第二次机会。文档天生还有一个覆盖不到的死角：它只能描述常见路径，无法穷举每一种权限组合、每一种数据状态和每一次版本差异的排列组合，界面本身必须自带足够的线索（当前状态是什么、下一步能做什么、为什么这个按钮不可点），否则文档写得再全，用户遇到的具体情境也不一定在文档里。可自解释性带来的收益不止是省一次搜索：它同时降低了培训成本、支持工单量和首次使用的出错率，这三者是同一个机制的三个可测量结果。
怎么研究
标准做法是招募符合目标画像但完全未受训的用户，不提供任何说明材料，观察他们能否独立完成注册、创建、提交、恢复等核心任务。记录的不只是成功与否，还包括每一次求助行为发生的具体位置、放弃前的最后一步操作、以及任务完成后请他们复述"你以为这一步是做什么用的"——这句事后复述常常能暴露界面传达的意图和用户实际理解之间的落差。更有诊断价值的设计是三组对照：完全无文档、仅有内联提示、附完整手册，比较三组的首次成功率与完成时间差异，用来判断某个具体困难到底应该靠界面本身修复，还是本就属于文档该承担的部分——如果内联提示组和手册组的成功率没有显著差别，说明问题出在界面结构而不是说明不够。
边界
复杂专业系统不可能做到所有功能都直观易懂：法规条文、命令行语法、组织内部审批流程本身就需要专门学习，这不是界面设计能替代的，而是系统真实复杂度的体现。自解释也不等于把所有信息一股脑塞进界面——那样做的结果往往是信息过载，把可学习性问题换成了视觉拥挤问题，两者都不理想。这条原则还有它明确不覆盖的场景：无障碍用户可能依赖辅助技术阅读界面本身就存在额外成本，危机场景（比如医疗急救界面）容不得用户靠试错学习，低网络或离线环境下界面本身可能加载不全，这几类场景仍然需要文档或人工支持作为兜底，不能指望"理想界面"单独解决。
怎么落地
- 挑选三到五个真正核心的任务做无引导测试，把测试中出现的第一个失败点当作界面缺陷记录下来，而不是写进帮助文档了事。
- 用真实对象名称、具体示例、合理默认值和有信息量的空状态说明系统能力，减少用户对手册的依赖。
- 保留文档作为兜底，但把每个核心路径的首次成功率当作界面质量的持续追踪指标，而不是只在上线前测一次。