禁用态需说明为何不可用
别名: disabled state · disabled reason · unavailable action · prerequisite
概念解释
可解释的禁用态（explainable disabled state）是指控件不可用时，界面除了显示其不能被激活，还说明缺少什么条件、限制来自哪里，或用户能如何恢复可用。灰掉的按钮只传递「不能」；原因与下一步才传递「为什么」和「怎么办」。例如提交按钮应指明缺少必填信息，导出按钮应说明权限或选择范围，暂不可用的功能应说明正在处理、网络限制还是计划限制。解释使禁用从死路变成可行动的状态信息。
机制
禁用会打断用户的意图链。用户已经识别出想要的动作，却无法通过点击获得系统响应；若没有原因，只能猜测控件损坏、自己权限不足、尚未满足前提还是系统临时故障。猜错后会反复点击、离开页面重找、联系支持或放弃。把前提条件外显，将不可用动作与可执行补救动作连接起来，减少记忆与诊断负担。原因还建立了产品规则的可预测性：用户下次遇到同类限制时能提前准备，而非再次试错。
怎么研究
让参与者在缺少不同前提、权限受限、任务处理中和系统异常的情况下尝试目标动作，比较仅禁用与带原因/恢复路径的版本。测量正确诊断率、达到可用状态的时间、无效点击、帮助寻求和对限制公平性的判断。不要只问用户是否看懂文案；应观察他们能否据此完成补救。还应测试原因随状态变化是否及时更新，否则过时解释比没有解释更容易损害信任。
边界
并非每个暂不可用控件都需要长篇说明。明显的物理限制或相邻字段即时可见的前提可用简短提示；重复密集的列表中把原因全展开也会制造噪声。反过来，安全、权限和商业限制不能用模糊的「不可用」掩盖：若不能透露具体规则，也应给出合法的下一步或支持入口。原因不是为错误状态找借口，真正的故障应被报告为故障，并提供恢复或重试策略。
怎么落地
- 为每种禁用原因建立可读的状态模型：缺少输入、选择无效、无权限、处理中、离线、额度耗尽或功能不支持各自对应不同说明与下一步。
- 将解释放在用户查看或尝试该控件时可获得的位置，并让它与当前状态同步；不要只把规则埋在帮助中心。
- 能由用户完成的前提应直接提供跳转、自动定位或修正动作；不能由用户完成的限制应给出等待、替代或联系路径。
- 用阻塞任务测试：用户应能在不询问他人的情况下说出为什么不能用、下一步做什么，以及何时应停止重试。