E1.10.3consistent in-product button order设计研究
同一产品内必须统一顺序
别名: 产品内按钮顺序 · 对话框顺序一致 · internal consistency
概念解释
平台给了确认/取消的槽位，产品还要在自己内部只用一种槽位。设置里确定在右、卸载里确定在左、表格批量栏又把删除放在确认常坐的那一侧——这叫产品内顺序不统一。用户无法为「这个应用」编译一条位置记忆，每次对话框都要当新题来做。统一顺序是在产品边界内形成可迁移的技能，跨平台那一层是另一件事。
机制
技能向稳定的统计收敛。一个产品如果自己的统计是噪声，学习曲线就平了：既学不成 Windows 那套，也学不成 Mac 那套，只剩下逐次阅读。不统一往往不是有人故意，而是各业务线复制了不同时期的对话框模板、Web 组件和原生组件各跟各的宿主。用户感知不到模板来源，只感知「这软件的确定有时这边有时那边」。一旦不统一，想靠某一次对调来防呆也失去基准——没有「正常顺序」，对调无法被察觉。内部统一之后，偶发的例外才会被当成警告。
怎么研究
做产品走查：收集全部带确认/取消（或主/次）成对按钮的界面，编码左右或上下顺序，算不一致的页数。再做任务：在顺序一致的版本与故意混用两种顺序的版本之间，测重复对话框的速度和错按。
自变量：产品内顺序是否单一、不一致出现的密度。 因变量：从第二、第三个同类对话框开始的加速是否出现、错按、主观「这软件乱」。
走查比实验更先做。许多产品的不一致在实验室任务用的那两页里根本抽不到。
边界
嵌入系统对话框（文件选择、权限）会强制用 OS 顺序，应用对话框若与之并列出现，短暂的不一致无法消除，只能少让两者同屏。Web 管理后台给多 OS 用户共用，内部统一优先于「试图跟所有人的 OS」；跟 OS 走是跨平台适配的课题。A/B 测试若把按钮顺序当变量，会在实验组里制造不统一，实验结束必须收敛。
怎么落地
- 把确认/取消槽写进唯一的对话框组件，业务线不准另排一排。
- 列出产品里所有成对动作（保存/取消、允许/拒绝、删除/保留），按同一方向编码。
- 发现历史页面顺序不同，一次性迁移，不要留「旧版设置页」。
- 验证：截下每一处成对按钮，叠成一张对照图。出现两种以上的左右或上下模式，产品内顺序就不统一。