T2.01.2Context-dependent generic button labels设计研究
泛化词无法让用户预判结果
别名: 泛化按钮词 · OK 按钮 · Continue · Submit
概念解释
“继续”“确定”“提交”“OK”等泛化按钮词（generic button labels）主要表达流程角色，很少独自说明结果。它们并非一律错误：当单一、稳定、紧邻的上下文已明确对象和下一状态时，“继续”可以准确推进；当按钮会保存、发布、付款、授权或离开当前任务时，泛词通常不足以支持预判。判断标准是完整使用情境中的结果可预测性，而不是黑名单命中。
机制
泛词把语义负担转移给标题、步骤结构和用户记忆。“提交”可能是提交审核、最终发布或只保存表单；“OK”可能确认破坏性动作，也可能关闭通知。若候选结果不止一个，用户必须回读或猜测，压力、弹窗叠加和小屏浏览会放大误判。反之，在无分支向导里，标题持续可见、下一步无副作用且可返回时，“继续”所表达的流程推进就是完整结果，不必为具体而造冗长标签。
怎么研究
把按钮放在真实标题、选择、状态和后续结果中测试，请用户在激活前说出下一屏或数据变化，并给出确信程度。改变上下文可见性、回退能力和候选后果，观察泛词何时开始产生分歧；同时覆盖深链接、读屏导航、翻译后长度和错误恢复。将误判按“上下文缺失、词义多义、实现超出承诺”分类，不用脱离界面的单词猜测测试否定所有泛词。
边界
纯信息提示的“知道了/OK”、可逆单路径向导的“继续”和约定明确的系统控件可能足够。取消也不保证永远“无变化”：若关闭会丢失输入，就必须说明。平台控制的按钮不能改写时，应在触发前或对话框正文提供具体对象和结果。高风险确认按钮仍需重述动作，这里只解释泛词何时缺乏预测信息。
怎么落地
- 逐个标注泛词按钮实际造成的导航、数据、费用、权限和可逆性；若存在合理的第二种解释，改为动作/目的地加对象。
- 允许泛词须同时满足：上下文紧邻且持续可见、只有一个合理结果、低后果或可恢复、用户可返回；任一条件不成立就补足标签。
- 不用“提交”概括不同阶段，分别写“保存草稿”“发送审核”“发布文章”；不让“继续”隐藏付费、授权或创建账户。
- 通过预测测试与遥测复核允许项；流程新增副作用或上下文布局变化时，重新审核原先合格的泛词。