Windows 应用 UX 设计 - 按使用环境划分的优先级

思考 Windows 应用的 UX 时，如果一上来就从“看起来是否现代”“留白是否美观”入手，很容易把顺序搞反。

在 Windows 桌面端，UX 并不只由外观决定。

• 能否仅用键盘就完成操作
• 是以鼠标为前提，还是以触摸为前提
• 是长时间使用，还是偶尔用几分钟
• 是监控场景、录入场景，还是现场终端
• 误操作时会造成什么样的影响和损失
• 使用文字放大、对比度主题、屏幕阅读器等辅助技术时，能否照常操作

这些加在一起，才构成 UX。

flowchart TB
    accTitle: 不只由外观决定的UX
    accDescr: 能否仅用键盘完成操作、是鼠标还是触摸、使用时长与用途、误操作时的影响和损失、使用屏幕阅读器等辅助技术时能否照常操作，这些加在一起才构成UX的示意图。
    a1["输入方式与操作的完结程度"] --> a4["这些加在一起才是UX"]
    a2["使用时长与用途"] --> a4
    a3["出错代价与辅助技术"] --> a4
    a4 -.-> a5["从“看起来是否现代”入手就会把顺序搞反"]

图1：Windows 桌面端的 UX，先由使用场景的组合决定，而不是外观。

更麻烦的是，ToC 和 ToB 的侧重点并不相同。 但如果因此就认为“ToB 就该把信息塞满”“ToC 就该做得轻飘飘的”，往往会在某个地方栽跟头。

例如，同样是 ToB，

• 财务录入、订单管理这类 事务类应用
• 工厂、仓库、前台、检测设备这类 现场终端
• 24 小时监控、维护支持的 运维界面

它们对“好的 UX”的定义相当不同。

反过来，即便是 ToC，

• 面向个人的小型实用工具
• 图像编辑、音乐制作、投资分析这类偏高级用户的工具

在 UI 密度和快捷键需求上也完全不同。

flowchart TB
    accTitle: 同一个标签下条件并不相同
    accDescr: 同样是ToB，事务类应用、现场终端和运维界面对好的UX的定义相当不同；同样是ToC，小型实用工具和偏高级用户的工具在密度和快捷键需求上也完全不同的示意图。
    b0["同样叫ToB的标签"] --> b1["事务类、现场终端、运维界面"]
    b1 --> b2["对好的UX的定义相当不同"]
    c0["同样叫ToC的标签"] --> c1["实用工具、高级用户工具"]
    c1 --> c2["密度和快捷键需求也不同"]

图2：即使同在 ToC / ToB 这一个标签之下，好的 UX 的条件也会分岔。

Microsoft 面向 Windows 的设计指南同样强调，Windows 应用的设计应当 直观易用、无障碍，并能跨输入方式和外形规格保持一致的行为。¹²

本文将 Windows 应用的 UX 整理成一张 按用途划分的判断表，目的是让设计评审或界面设计的初期阶段更容易梳理出“这个应用应该优先考虑什么”。

本文的目标读者与前提

本文使用的术语

1. 先说结论

先粗略地把结论摆出来。

• ToC 应优先考虑 易于首次理解、安心感、设置项少、路径直观
• ToB 应优先考虑 持续效率、防误操作、键盘支持、布局稳定
• 但 ToB 的现场终端，优先级不是密度，而是 清晰明确、大操作对象、短路径
• 但 ToC 的高级用户工具，优先级不是简单易用，而是 信息密度、快捷键、可定制性
• 在 Windows 应用中，把 键盘 / 鼠标 / 触摸 / 文字放大 / 对比度主题 / 辅助技术 都纳入 UX 考量范围，后续的设计会更不容易崩坏¹³⁴⁵⁶⁷

最先真正要决定的，不仅仅是 ToC 还是 ToB。 应该先把以下这 5 点明确出来。

1. 谁在使用（初学者、熟练用户，还是混合）
2. 在哪里使用（办公桌、会议室、现场、工厂、前台、户外）
3. 用什么操作（键盘、鼠标、触摸、笔、条码枪、辅助技术）
4. 使用频率有多高（以首次使用为主、偶尔、每天、全天）
5. 出错的代价是什么（轻微、严重、危险、需要审计）

看清这 5 点之后，UI 密度、导航方式、快捷键、确认对话框、可定制性的优先级就会大幅更容易确定。

flowchart TB
    accTitle: 需要先明确的5个问题
    accDescr: 谁在使用、在哪里使用、用什么操作、使用频率有多高、出错的代价是什么，看清这5点之后，UI密度、导航、确认对话框等的优先级就更容易确定的示意图。
    q1["1. 谁在使用"] --> q2["2. 在哪里使用"]
    q2 --> q3["3. 用什么操作"]
    q3 --> q4["4. 使用频率有多高"]
    q4 --> q5["5. 出错的代价是什么"]
    q5 --> q6["密度、导航、对话框的优先级随之确定"]

图3：比起先分 ToC 还是 ToB，先把 5 个问题说清楚更能定下优先级。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 23 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. ToC / ToB 只是入口，并非答案

ToC / ToB 的划分作为最初的入口是很方便的。 但是，真正决定 UX 正确答案的，更多是使用方式的种类，而不是买方的种类。

例如，粗略地用两个轴来看，大概是这样：

也就是说，

• ToC = 永远轻量的 UI
• ToB = 永远高密度的 UI

并不成立。

Windows 应用的设计指南同样强调 跨设备、跨输入方式、跨外形规格保持一致的可用性，在无障碍方面也强调不能只考虑残障与否，还要把 明亮的户外、共享空间、安静场所、嘈杂场所 这类环境限制一并纳入考虑。¹²

flowchart TB
    accTitle: 使用方式的种类比买方的种类更关键
    accDescr: ToC永远是轻量UI、ToB永远是高密度UI这两个等式并不成立，真正决定UX正确答案的更多是使用方式的种类而不是买方的种类的示意图。
    e1["ToC = 永远轻量的UI"] --> e3["这个等式并不成立"]
    e2["ToB = 永远高密度的UI"] --> e3
    e3 --> e4["决定答案的是使用方式的种类"]
    e4 -.-> e5["把环境限制也一并纳入考虑"]

图4：决定 UX 正确答案的，是使用方式的种类，而不是买方的种类。

所以，在看过 ToC / ToB 之后，建议再用下面这些轴进一步划分。

先把这一层划分清楚，会议中那种“感觉挺现代”“感觉挺像业务系统”的空泛讨论就会大幅减少。

3. 一张表看懂：按用途划分的判断表

先给出实务中最好用的一张表。

光看这张表，大致方向就已经能看出来了。 特别重要的是，即使是 ToB，现场终端的正确答案也不是高密度 UI，以及 即使是 ToC，高级用户工具也是效率优先于轻量。

flowchart TB
    accTitle: 标签与正确答案反转的两个例子
    accDescr: 即使是ToB，现场终端的正确答案也不是高密度UI；即使是ToC，高级用户工具也是效率优先于轻量，展示两个从标签推想的答案会反转的例子的示意图。
    f1["ToB的现场终端"] --> f2["高密度UI不是正确答案"]
    f3["ToC的高级用户工具"] --> f4["效率优先于轻量"]
    f2 --> f5["按用途决定，而不是按标签"]
    f4 --> f5

图5：判断表中特别重要的、标签与正确答案反转的两行。

如果时间紧张，读到本章为止就够了。 接下来的第 4 章，是把这张表的每一行展开成“为什么会这样”“具体该放什么”。它不会重复表里已有的结论，因此可以只读表中写不下的那些判断依据。

4. 按用途划分的设计方针

4.1 ToC 实用工具 / 个人应用

对于面向 ToC 的小型 Windows 应用，“启动之后马上就能用” 是最强的。

尤其要重视以下几点：

• 第一屏就能看出这是做什么的应用
• 主要操作被压缩到一两个
• 空状态不会显得不友好
• 危险操作可以撤销
• 不会一开始就把所有设置项都摆出来

这里容易犯的错误，是把技术上能做到的功能全部堆上去。 但对于 ToC 的轻量工具而言，能马上用起来 比 功能多 更有价值的场合往往更多。

Windows 的导航设计也指出，不存在对所有应用通用的正确答案，首先重视的是 一致性、简洁性、清晰度。使用标准控件和标准位置，会让界面更容易被预测。⁸

因此，对于 ToC 而言，大致按下面这样梳理就够用了：

• 体量小则用单一界面
• 各版块并列时用顶部导航
• 设置分阶段展示
• 主要操作醒目，其余操作低调

flowchart TB
    accTitle: ToC产品的梳理方向
    accDescr: 面向ToC时以启动之后马上就能用为轴，体量小则用单一界面、版块并列则用顶部导航、设置分阶段展示、主要操作醒目其余低调，这样梳理往往就够用的示意图。
    g1["启动之后马上就能用"] --> g2["体量小则用单一界面"]
    g1 --> g3["并列时用顶部导航"]
    g1 --> g4["设置分阶段展示"]
    g4 -.-> g5["主要操作醒目，其余操作低调"]

图6：ToC 的轻量工具，要往“能马上用起来”而不是“功能多”的方向梳理。

不过，即便是 ToC，一旦涉及 照片编辑、视频编辑、作曲、投资分析、开发辅助 这类面向高级用户的应用，情况就不同了。 这时与其看 ToC 这个标签，不如看 熟练度 和 使用时长，这样更接近正确答案。

4.2 ToB 事务录入 / 后台办公

对于事务类 ToB 应用来说，比外观轻盈更重要的是 作业不被打断。

每天使用的用户，几天之内就会熟悉 UI。 之后真正起作用的是这些方面：

• 仅用键盘能走到哪一步
• 能否顺畅地在列表和明细之间往返
• 重要的列和状态是否一目了然
• 是否能保持筛选和排序状态
• 错误能否当场修正

Microsoft 的键盘无障碍指南也强调，应用应做到 可通过键盘到达全部功能，并建议规划好 Tab 顺序、焦点、Enter / Space 操作以及快捷键的实现。³

另外，访问键不仅有助于无障碍，对偏好键盘操作的高级用户也能提升效率。在合适的场合，包括自定义控件在内也建议支持访问键。⁹

在事务录入类场景中，列表/详情 是较为稳妥的导航方式。 Windows 的导航指南也指出，列表/详情适合 频繁切换项目、同时进行详情查看与更新 的用途，例如 邮件收件箱、联系人列表、数据录入 这类场景。⁸

也就是说，下面这种结构比较自然：

• 左侧是功能分类
• 中间是列表
• 右侧或下方是明细/编辑区
• 上方是搜索、筛选、主要命令
• 常用操作支持快捷键

flowchart TB
    accTitle: 事务录入的自然结构
    accDescr: 上方放搜索、筛选和主要命令，左侧放功能分类，中间放列表，右侧或下方放明细与编辑区，常用操作支持快捷键的事务录入类自然结构的示意图。
    h1["上：搜索、筛选、主要命令"] --> h2["左：功能分类"]
    h2 --> h3["中：列表"]
    h3 --> h4["右或下：明细、编辑"]
    h4 -.-> h5["常用操作支持快捷键"]

图7：以列表/详情为轴的事务录入类自然界面结构。

反过来，也列出应避免的模式：

• 每一步操作都弹对话框
• 列太少导致一览性差
• 主要操作只能在右键菜单深处找到
• 只靠图标表达含义
• Tab 顺序混乱，Enter 和 Space 都无法生效

关于输入错误，与字段绑定的校验错误，不用对话框而是在界面内展示 会更自然。Windows 的对话框指南也建议，密码框等 与上下文相关的校验错误不要用对话框，而应使用内联显示。¹⁰

4.3 ToB 监控与运维

监控与运维界面的 UX，比“好用”更优先的是 不漏看、不出错、不停摆。

这里的优先级大致如下：

• 一眼就能看出是否存在异常
• 能看出异常的严重程度
• 不仅是当前值，也能追溯变化和时间序列
• 危险操作的入口不能过于轻易触达
• 能立即跳转到日志、历史记录、原因排查

在这类界面中，状态表达 是 UX 的核心。 状态最好用 颜色 + 文字 + 图标 + 时间 等多种要素组合表达，这样更安全。 只用颜色表达状态，容易造成漏看或误判，在无障碍层面也偏弱。¹¹

flowchart TB
    accTitle: 状态用多种要素表达
    accDescr: 监控与运维界面中状态表达是UX的核心，只用颜色表达容易造成漏看和误判，因此用颜色、文字、图标、时间等多种要素组合表达更安全的示意图。
    i1["只用颜色表达状态"] --> i2["容易漏看、误判"]
    i2 -.->|"改为"| i3["用颜色+文字+图标+时间表达"]
    i3 --> i4["漏看和误认都减少，更安全"]

图8：监控界面的状态，要用多种要素的组合而不只是颜色来表达。

导航方面，如果监控对象较多，用左侧导航；对单个对象的深入查看用下钻；详情用日志或时间线呈现，这样的组织方式比较容易处理。 Windows 的导航指南也指出，左侧导航适合 顶层项目较多 或页面切换不频繁的结构。⁸

在操作层面，把命令只放在一个位置也很危险。 Windows 的命令设计指南建议，命令应能从 按钮、右键菜单、快捷键、手势等多个入口 使用，并建议 把所有相关命令都放进右键菜单或 CommandBarFlyout 中。因为如果只依赖 hover 才出现的操作，触摸设备和辅助技术就无法使用。¹²¹³

危险操作的确认对话框在这里同样重要。 但是“什么都先确认一下”反而会起反作用。 真正需要确认的，是 停止、删除、切换、屏蔽、覆写 这类偏不可逆的操作。 如果要弹对话框，

• 第一行就明确写清楚会发生什么
• 按钮文案不要用 OK / Yes，而要具体化为 删除 / 停止 / 屏蔽
• 必须放置一个安全方向的按钮

这 3 点至少应该遵守。¹⁰

flowchart TB
    accTitle: 确认对话框的3条原则
    accDescr: 真正需要确认的是停止、删除、屏蔽这类偏不可逆的操作，要弹就在第一行写清楚会发生什么、把按钮文案写具体、必须放置一个安全方向的按钮的示意图。
    j1["只对偏不可逆的操作做确认"] --> j2["第一行写清楚会发生什么"]
    j1 --> j3["按钮文案写具体"]
    j1 --> j4["必须放置安全方向的按钮"]
    j2 -.-> j5["“什么都先确认一下”会起反作用"]

图9：确认对话框只留给不可逆操作，并守住 3 条底线再弹出。

4.4 ToB 现场终端 / 设备 UI / 自助终端

现场终端在 Windows 应用 UX 中相当特殊。

• 不是坐着操作
• 可能戴着手套
• 只有一只手空着
• 不会仔细看屏幕
• 存在时间压力
• 在明亮的现场或嘈杂的场所使用

这些条件都很常见。

Microsoft 的无障碍指南也强调，好的 Windows 应用不能只考虑残障与否，还要考虑 强烈日光、共享空间、噪音、安静、正在烹饪等场景 之类的环境限制。²

另外，在触摸设计方面：

• 触摸操作 没有 hover
• 手指或手会 遮挡（occlusion）UI
• 屏幕的某些位置因手部姿势 难以按到
• 视觉反馈非常重要

存在这些差异。⁴

flowchart TB
    accTitle: 触摸设计上的4点差异
    accDescr: 触摸没有hover、手指或手会遮挡UI、屏幕某些位置因手部姿势难以按到、视觉反馈非常重要，这四点设计上的差异的示意图。
    k1["触摸操作"] --> k2["没有hover"]
    k1 --> k3["手指或手会遮挡UI"]
    k1 --> k4["有些位置因姿势难以按到"]
    k4 -.-> k5["视觉反馈变得非常重要"]

图10：触摸在 hover 和遮挡上的前提不同，反馈怎么呈现成了关键。

因此现场终端大致应朝以下方向靠拢：

• 按钮和列表项要足够大
• 尽量做到一屏一目的
• 操作后的反馈要清晰可见
• 把流程拆分成阶段
• 输入尽量倾向于 选择、扫描、预设值，而不是自由输入
• 状态在屏幕上方或中央清晰展示

反过来，应避免的是：

• 小字号
• 小点击区域
• 依赖 hover 才出现的提示
• 深层级菜单
• 一屏塞入大量信息
• 长篇自由输入

“因为是 ToB 就该做高密度”这种粗糙想法，在这个领域最容易踩坑。 这里恰恰是 业务应用中尤其应该以清晰为先 的领域。

flowchart TB
    accTitle: 现场终端以清晰为先
    accDescr: 现场终端要尽量做到一屏一目的，输入倾向于选择、扫描、预设值而不是自由输入，操作后的反馈要清晰可见，是业务应用中尤其应该以清晰为先的方向的示意图。
    l1["现场终端、设备UI"] --> l2["尽量做到一屏一目的"]
    l1 --> l3["输入倾向于选择、扫描、预设值"]
    l1 --> l4["操作后的反馈清晰可见"]
    l2 --> l5["业务应用中尤其以清晰为先"]
    l3 --> l5
    l4 --> l5

图11：现场终端要靠拢的不是密度，而是清晰明确、大操作对象和短路径。

4.5 面向专业用户的编辑 / 分析工具

对面向专业用户的工具来说，“希望做得更易懂”有时会输给“不要打断我的操作”。

例如：

• CAD
• 波形分析
• 视频编辑
• 图像处理
• 音乐制作
• 开发辅助
• 数据分析
• 审计 / 诊断工具

这些都是典型例子。

这类应用中，以下要素会发挥作用：

• 信息密度
• 多面板
• 标签页
• 右键菜单
• 快捷键
• 布局保存
• 列和显示项的可定制化
• 撤销 / 重做
• 作业状态恢复

Windows 的导航指南也指出，标签页 适合想要打开、关闭、重新排列多个页面或文档的场景。⁸ 另外，Windows 的命令设计建议命令应在多个 UI 入口之间共享，即使输入方式不同也能到达同一操作。¹²

这类工具常犯的错误，是为了照顾新手而 把所有功能都藏进很深的菜单。 但熟练用户每天要重复同一操作数百次。 对他们来说，重要的不是最初 5 分钟的友好度，而是 用满 100 小时之后依然不容易疲劳。

因此，面向高级用户的设计，下面这些做法通常更有效：

• 高频操作放在近处
• 辅助功能放得稍远
• 高级功能保留但整理清晰，而不是直接删掉
• 保存显示布局
• 加强键盘操作

flowchart TB
    accTitle: 面向熟练用户的布置思路
    accDescr: 熟练用户每天要重复同一操作数百次，比起最初5分钟的友好度更重要的是用满100小时之后依然不容易疲劳，因此高频操作放近处、辅助功能放稍远、高级功能保留但整理清晰的示意图。
    n1["熟练用户每天重复同一操作数百次"] --> n2["高频操作放在近处"]
    n1 --> n3["辅助功能放得稍远"]
    n1 --> n4["高级功能保留但整理清晰"]
    n2 -.-> n5["比起最初5分钟，更看重100小时后的不疲劳"]

图12：面向专业用户的工具，要按操作频率对应的距离来摆放功能。

4.6 常驻工具 / 系统托盘应用

对常驻类应用来说，不过度刷存在感本身就是 UX。

例如：

• 同步状态
• 连接状态
• 备份
• 音频 / 摄像头 / 设备切换
• VPN / 代理 / 启动器
• 通知中心

这类应用中，主界面往往不是主角。

应优先考虑的是：

• 能从托盘或小型菜单立即操作
• 能看清当前状态
• 只在必要时才通知
• 能从通知直接跳转到所需操作
• 主界面不会过度抢占前台

应避免的是：

• 为小事弹对话框
• 每次启动都打开主界面
• 后台运行状态看不见
• 通知太多导致全部被忽略

对这类应用而言，是否打扰用户 往往比 功能是否多 更能左右 UX。

flowchart TB
    accTitle: 常驻工具不打扰就是UX
    accDescr: 常驻类应用优先做到能从托盘或小型菜单立即操作、能看清当前状态、只在必要时才通知，而通知太多会导致全部被忽略的示意图。
    r1["能从托盘立即操作"] --> r4["不打扰就是UX"]
    r2["能看清当前状态"] --> r4
    r3["只在必要时才通知"] --> r4
    r4 -.-> r5["通知太多会导致全部被忽略"]

图13：常驻工具不过度刷存在感，本身就构成了它的 UX。

5. 导航模式判断表

Windows 的导航指南在指出 不存在对所有应用都通用的单一导航设计 的同时，把 一致性、简洁性、清晰度 作为原则。此外，把标准控件放在用户预期的位置，也能让界面更容易被预测。⁸

flowchart TB
    accTitle: 导航设计的原则
    accDescr: 不存在对所有应用都通用的单一导航设计，以一致性、简洁性、清晰度为原则，把标准控件放在用户预期的位置来让界面更容易被预测的示意图。
    s0["不存在唯一正确的模式"] --> s1["一致性"]
    s0 --> s2["简洁性"]
    s0 --> s3["清晰度"]
    s3 -.-> s4["把标准控件放在预期的位置"]

图14：导航没有唯一正解，靠 3 条原则和标准位置让界面更容易被预测。

在实务中，大致可以用下表来划分，思路会更清楚。

Windows 的导航指南中，特别给出了如下使用建议：⁸

• 顶部导航：想把所有导航项都显示在屏幕上时
• 左侧导航：顶层项目多，且不频繁切换页面时
• 列表/详情：项目切换频繁，且需要查看或更新详情时
• 标签页：想动态打开或关闭多个文档或页面时
• 面包屑：层级较深，想让用户清楚回退路径时

5.1 只画骨架的线框图

只靠文字不容易形成画面，所以把有代表性的 4 种骨架并排列出来。 细节请忽略，只看 什么东西放在什么位置。

[ 顶部导航 ]  想把同级页面全部展示出来时
+-------------------------------------------------------------
| AppName        主页 | 转换 | 历史 | 设置
+-------------------------------------------------------------
|
|    主内容
|    尽量做到一屏一目的
|
+-------------------------------------------------------------


[ 左侧导航 ]  顶层项目较多时
+-------------------------------------------------------------
| AppName                                 搜索 [           ]
+-------------------------------------------------------------
| 仪表盘      |
| 设备列表    |    主内容
| 告警        |
| 作业        |
| 报表        |
| 设置        |
+-------------------------------------------------------------


[ 列表/详情 ]  一边切换项目，一边查看和更新详情
+-------------------------------------------------------------
| 搜索 [          ]  筛选: 未处理 / 全部          [新建] [删除]
+-------------------------------------------------------------
| 列表           |  详情 / 编辑
|  > 单据 1001   |    单据编号   1001
|    单据 1002   |    交易方     ...
|    单据 1003   |    明细行     ...
|    单据 1004   |
|                |    [ 保存 ]   [ 取消 ]
+-------------------------------------------------------------


[ 仪表盘 + 下钻 ]  发现异常并深入排查
+-------------------------------------------------------------
| 总览   正常 22    注意 3    异常 1        更新于 0.5 秒前
+-------------------------------------------------------------
| 异常 1 件
|   ! B 线 检测设备      无响应      48 秒前    [ 详情 ]
| 注意 3 件
|   - A 线 摄像头        数值过旧    12 秒前    [ 详情 ]
|   ...
+-------------------------------------------------------------
              |
              |  按下 [ 详情 ]
              v
+-------------------------------------------------------------
| < 返回列表         B 线 检测设备 / 无响应
+-------------------------------------------------------------
| 当前值 | 时序图 | 事件日志 | 操作
+-------------------------------------------------------------

把这 4 种并排看，选择的判断轴就清楚了。

• 顶部导航和左侧导航的分界，是顶层项目的数量。能横向排完就用顶部，排不完就用左侧
• 列表/详情的主角不是右侧，而是左侧的列表。列表信息量不够，就得反复重新打开详情
• 仪表盘的要点，是把“异常有几件”放在第一行。往下钻之后，一定要留出回退路径

归根结底，导航不是“外观上的喜好”，而是 信息结构与工作结构的体现。

flowchart TB
    accTitle: 顶部导航与左侧导航的分界
    accDescr: 顶部导航和左侧导航的分界是顶层项目的数量，能横向排完就用顶部、排不完就用左侧，导航是信息结构与工作结构的体现的示意图。
    t1{"顶层项目能否横向排完"} -->|"能排完"| t2["顶部导航"]
    t1 -->|"排不完"| t3["左侧导航"]
    t2 -.-> t4["导航是信息结构与工作结构的体现"]
    t3 -.-> t4

图15：骨架的选择不取决于外观喜好，而是由信息结构决定。

6. 输入设备与命令设计判断表

Windows 应用尽量支持更多输入方式，会更灵活好用。Microsoft 的指南也建议尽量考虑 手势、语音、触摸、触摸板、鼠标、键盘 等多种输入方式。¹⁴

此外，Windows 的平台控件本身能在一定程度上吸收多种输入方式的差异，所以 老老实实使用标准控件 首先就是一个很强的选择。⁴⁸

flowchart TB
    accTitle: 标准控件首先就很强
    accDescr: 指南建议尽量考虑手势、语音、触摸、鼠标、键盘等多种输入方式，而平台标准控件能在一定程度上吸收这些输入方式的差异，所以老老实实使用标准控件首先就很强的示意图。
    u1["支持多种输入方式"] --> u2["标准控件能在一定程度上吸收"]
    u2 --> u3["老老实实使用标准控件首先就很强"]

图16：应对多种输入方式，交给标准控件去吸收是条捷径。

整理成实务上便于使用的形式，如下所示：

键盘方面尤其重要的是以下几点：³⁹

• 能否仅用键盘到达全部功能
• Tab 顺序是否与视觉顺序大致一致
• 应能用 Enter / Space 触发的元素是否可以触发
• 重要功能是否有快捷键
• 高频操作是否配有访问键或加速键

触摸方面有以下特性：⁴

• 没有 hover
• 手指或手会遮挡 UI
• 可点击区域给人的感觉比看起来更小
• 需要视觉反馈
• 适合直接操作的 UI，和适合间接输入的 UI 并不相同

6.1 不说“足够大”，而是用数字来定

设计评审中最容易起争执的，是 停在“足够大”“足够清楚”这种说法上。 Microsoft 的指南给出了数值的项目，直接把那个数值当作合格与否的标准，讨论会短很多。

数值定下来之后，评审时的说法也会改变。 从“这个按钮是不是有点小”变成“这个按钮是 32px，没达到 7.5mm 的基准”，改不改的判断当场就能结束。

flowchart TB
    accTitle: 用数值来定评审就快
    accDescr: 停在“足够大”“足够清楚”上会在评审中起争执，把指南给出的数值直接当作合格标准，就能用是否达到基准来说话，改不改的判断当场就能结束的示意图。
    v1["停在“足够大”上"] --> v2["评审中起争执"]
    v2 -.->|"改为"| v3["把数值直接当作合格标准"]
    v3 --> v4["可以用是否达到基准来说话"]
    v4 --> v5["判断当场就能结束"]

图17：把数值当作合格标准，尺寸的争论当场就能结束。

另外，WinUI 的标准控件在默认情况下就是按这个目标尺寸做的。¹⁵ 反过来说，危险的只有自制控件和自定义绘制的部分。

命令设计方面，Windows 的命令指南是很好的参考。 特别重要的是，让命令能从多个 UI 入口使用。¹²

• 能从按钮点击
• 也能在右键菜单中找到
• 也能用快捷键调用
• 必要时也支持滑动或手势

并且建议 把所有相关命令都放进右键菜单或 CommandBarFlyout。如果只依赖 hover 时才可见的操作，在纯触摸设备上就会卡住。¹²

flowchart TB
    accTitle: 命令要从多个入口提供
    accDescr: 同一个命令要能从按钮点击、能在右键菜单中找到、也能用快捷键调用，从多个UI入口使用，而只依赖hover时才可见的操作在纯触摸设备上会卡住的示意图。
    w1["同一个命令"] --> w2["按钮"]
    w1 --> w3["右键菜单"]
    w1 --> w4["快捷键"]
    w2 --> w5["任何输入方式都能到达"]
    w3 --> w5
    w4 --> w5
    w1 -.-> w6["依赖hover在触摸上会卡住"]

图18：重要命令要放到多个 UI 入口上，避免依赖 hover。

7. Windows 应用中至少不能忽视的 UX 要点

从这里开始，整理不论用途都至少应该把握的要点。

7.1 是否能仅用键盘完成操作

在 Windows 桌面端，键盘不是“有则更好”的附加项，而是主要的输入手段。

Microsoft 的键盘无障碍指南也指出，支持键盘不仅是为了视觉或运动能力受限的用户，对于 出于效率而选择键盘 的用户同样重要。³

至少要看这 5 点：

• Tab 顺序是否自然
• 是否有焦点可视化
• 是否可以用 Enter / Space 触发
• 是否有快捷键
• 相当于右键的操作能否也用键盘调用

看起来不起眼，但一旦这里出问题，ToB 的 UX 会受到相当大的损害。

7.2 文字放大、对比度主题与无障碍

Windows 应用只要能好好跟随文字大小和对比度设置，UX 就会稳定不少。

Microsoft 的指南建议 可见文本的对比度至少达到 4.5:1，并要求在文字被放大时 控件和容器也相应地调整大小和重新排列。⁵⁶

此外，在对比度主题方面：

• 不要硬编码颜色
• 使用 SystemColor / Brush 资源
• 在 4 种对比度主题下逐一测试

以上这些都是推荐做法。⁷

这里容易崩坏的地方是：

• 假定标签宽度固定
• 按钮高度用像素写死
• 只用颜色表达含义的设计
• 自定义绘制且不跟随主题的 UI

与其把这些当作“无障碍适配”，不如把它们看作 打造长期不易崩坏的 Windows UI 的基础工程，这样更说得通。

flowchart TB
    accTitle: 经得起放大和主题切换的基础工程
    accDescr: 固定宽度的标签、写死像素的高度、只用颜色表达含义、不跟随主题的自定义绘制都容易崩坏，而不硬编码颜色、改用资源并在对比度主题下逐一测试，是长期不易崩坏的Windows UI的基础工程的示意图。
    y1["固定宽度标签、写死像素的高度"] --> y3["放大或切换主题时崩坏"]
    y2["只用颜色表达含义、自绘UI"] --> y3
    y3 --> y4["不硬编码颜色，改用资源"]
    y4 --> y5["在4种对比度主题下逐一测试"]
    y5 -.-> y6["长期不易崩坏的UI的基础工程"]

图19：跟随文字放大和对比度主题，属于 UI 的基础工程。

7.3 不要滥用对话框

对话框很方便，但用得太多反而会成为作业的敌人。

Windows 的对话框指南把对话框定义为，在需要 通知、确认、补充信息输入 时使用的 模态 UI，并建议至少放置一个 安全且非破坏性的操作（如 Close、Cancel）。此外，按钮文案最好写成 具体的响应。¹⁰

重要的是，不要什么都做成对话框。

尤其是：

• 字段级的输入错误
• 可以当场修正的格式错误
• 临时性的提醒

这些最好尽量用内联显示来处理。¹⁰

7.4 重要命令要提供多条入口

在 Windows 的命令设计中，重要命令应能 从多种输入方式和多个 UI 入口调用，这一点很受重视。¹²¹³

这在实务中也相当有效。

例如“删除”这个操作，如果有

• 工具栏
• 右键菜单
• Delete 键
• 必要时的滑动手势

这样多条路径并存，使用体验会更稳定。

反过来，

• 只在 hover 时出现在最右侧
• 只能通过右键调用
• 用键盘永远无法到达

这类设计一旦输入方式发生变化，就会立刻变得脆弱。

7.5 用测试工具进行确认

无障碍这件事，靠脑子里想“应该没问题吧”，不如用工具看一眼来得快。

Microsoft 的无障碍测试指南介绍了使用 Accessibility Insights for Windows 进行 Live Inspect、FastPass、故障排查的方法，还可以用 SDK 中的 Inspect 查看 UI Automation 的属性和导航结构。¹⁷

至少做到

• 用 Accessibility Insights 粗略扫描一遍
• 用 Inspect 确认主要元素的名称、角色、模式
• 仅用键盘走通主要流程
• 试一遍文字放大和对比度主题

这种程度，后期返工就会少很多。

flowchart TB
    accTitle: 无障碍的确认步骤
    accDescr: 先用Accessibility Insights粗略扫描，再用Inspect确认主要元素的名称、角色、模式，然后仅用键盘走通主要流程，最后试一遍文字放大和对比度主题的确认流程示意图。
    z1["用Accessibility Insights扫描"] --> z2["用Inspect确认名称、角色、模式"]
    z2 --> z3["仅用键盘走通主要流程"]
    z3 --> z4["试一遍放大和对比度主题"]
    z4 -.-> z5["比脑子里的“应该没问题”快得多"]

图20：无障碍先用工具扫描，再动手确认主要流程。

7.6 加入可恢复性

这与其说是 Microsoft 的某条清单，不如说是在 Windows 桌面实务中相当见效的经验。

UX 不只由“按下去很舒服的按钮”决定，也由 出了错也能退回来 决定。

例如：

• 撤销 / 重做
• 自动保存
• 保留编辑中的状态
• 恢复筛选 / 排序 / 列宽
• 中断与恢复
• 长时间处理的进度显示和取消

这些对 UX 的作用，远比外观大得多。

尤其在 ToB 或面向专业用户的场景中，重做一遍操作的压力 会直接变成 UX 的糟糕之处。

flowchart TB
    accTitle: 可恢复性决定UX
    accDescr: UX不只由按下去很舒服的按钮决定，也由出了错也能退回来决定，撤销与重做、自动保存、状态恢复、长时间处理的进度显示和取消都能减少重做操作的压力的示意图。
    ba1["撤销 / 重做、自动保存"] --> ba4["出了错也能退回来"]
    ba2["编辑中状态、显示状态的恢复"] --> ba4
    ba3["进度显示与取消"] --> ba4
    ba4 -.-> ba5["重做一遍操作的压力直接变成UX的糟糕之处"]

图21：UX 不只看好不好按，也看出错之后能不能退回来的可恢复性。

8. 常见的设计失误

8.1 认定“因为是 ToB，做成高密度就好”

这个说法只对了一半。

面向每天使用的熟练用户时，高密度确实有时能起作用。 但在现场终端、前台终端、设备 UI 中，密度反而是敌人。

与其看 ToB 这个标签，不如看 熟练度、输入方式、使用环境，这样更不容易判断失误。

8.2 因为是 ToC 就把功能藏得太深

即便面向个人，如果是面向熟练用户的工具，效率仍是最优先的。

一旦什么都朝着“做得看起来简单”的方向去，就会开始出现

• 高频操作离得很远
• 每次都要在菜单里挖
• 界面不停切换

这种安静的地狱。

flowchart TB
    accTitle: 标签式思维的两个陷阱
    accDescr: 因为是ToB就做成高密度的想法在现场终端会失灵，因为是ToC就把功能藏得太深会让熟练用户的高频操作变远，展示这两个陷阱的示意图。
    ca1["因为是ToB就高密度"] --> ca2["现场终端里密度是敌人"]
    ca3["因为是ToC就隐藏"] --> ca4["熟练用户的高频操作变远"]
    ca2 --> ca5["按熟练度、输入方式、使用环境来看"]
    ca4 --> ca5

图22：“ToB 就高密度”“ToC 就简单化”的成见，会朝相反的方向失灵。

8.3 做出依赖 hover 的操作

触摸没有 hover。 而且只能靠指针才会出现的 UI，往往和辅助技术的兼容性也不好。⁴¹²

重要操作最好始终可见，或者至少准备多条入口，这样更安全。

Before: 只有 hover 的那一行，最右侧才出现操作
  单据 1001   2026-03-18   未处理                        <- 什么都看不到
  单据 1002   2026-03-18   未处理        [ 编辑 ][ 删除 ] <- 只有鼠标移上去的那行

After: 始终可见 + 增加入口
  单据 1001   2026-03-18   未处理        [ 编辑 ][ 删除 ]
  单据 1002   2026-03-18   未处理        [ 编辑 ][ 删除 ]
     右键        -> 编辑 / 删除
     键盘        -> Enter 编辑，Delete 删除

8.4 只用颜色表达状态

这在监控界面中特别多，只用红 / 黄 / 绿表达含义是很危险的。

把文字、图标、时间、数量、说明配合起来，漏看和误认都会减少。¹¹

8.5 把校验错误全部做成对话框

这在事务录入类场景中很常见。 每录入一次就弹一次对话框，作业节奏会被彻底打乱。

局限在上下文之内的错误，在界面里就地展示会更自然。¹⁰

Before: 每个字段都弹模态
  邮政编码  [ 1234        ]        +------------------------------+
  地址      [             ]        | 邮政编码的格式不正确
                                   |                       [ OK ]
                                   +------------------------------

After: 就地内联展示
  邮政编码  [ 1234        ]
            ! 请输入 7 位数字。例 1234567
  地址      [             ]

8.6 用固定尺寸的布局来做

在 100% 缩放的开发环境中看起来很整齐，但一旦遇到

• 文字放大
• 高 DPI
• 对比度主题
• 本地化

就会轻易崩坏。⁶⁷

Before: 固定宽度标签 + 固定高度按钮。文字一放大
  [ 预计发货... ][ 2026-03-1  ]      <- 标签被截断，数值也溢出
  [ 登 ][ 取 ]                        <- 按钮文字上下被切掉

After: 随内容伸缩的布局
  预计发货日
  [ 2026-03-18              ]
  [ 登记 ]   [ 取消 ]                 <- 高度由内容 + 留白决定

外观做得越精致，固定尺寸的前提就越容易变成毒药。

8.7 自定义控件做得太多

Windows 的标准控件所具备的行为，远比外观看起来的要多。

• 焦点
• 键盘
• 主题跟随
• UI Automation
• 与辅助技术的对接

这些它都替你照顾到了，如果没有理由就全部自己实现，UX 和无障碍方面的负债只会不断增加。⁸³

9. 开工前要定下的 8 个问题

最后，给出一组放在设计评审最开始会很好用的 8 个问题。

先把这 8 个问题回答好，

• 导航是否应该更浅
• 是否适合用列表 + 明细
• 是否应该加强快捷键
• 对话框应该用在哪里
• 定制化应该允许到什么程度

这些就会自然而然地定下来。

flowchart TB
    accTitle: 从8个问题里定下来的东西
    accDescr: 先回答好开工前的8个问题，导航的深浅、列表与明细的结构、快捷键的厚度、对话框的用处和定制化的范围就会自然而然地定下来的示意图。
    da1["回答开工前的8个问题"] --> da2["导航的深浅与列表、明细的结构"]
    da1 --> da3["快捷键的厚度"]
    da1 --> da4["对话框与定制化的范围"]
    da2 --> da5["自然而然地定下来"]
    da3 --> da5
    da4 --> da5

图23：先回答这 8 个问题，设计上的主要选择就会自然定下来。

10. 总结

Windows 应用 UX 设计中重要的， 是先定下 “这个人、在这个场所、用这种输入方式，能否不被打断地使用”，而不是先纠结“是否美观”。

flowchart TB
    accTitle: 比美观更该先定下的事
    accDescr: UX设计中重要的是先定下这个人、在这个场所、用这种输入方式能否不被打断地使用，而不是先纠结是否美观，UX不是装饰而是一份关于操作的契约的示意图。
    ea1["这个人"] --> ea2["在这个场所"]
    ea2 --> ea3["用这种输入方式"]
    ea3 --> ea4["能否不被打断地使用"]
    ea4 -.-> ea5["UX不是装饰，而是操作的契约"]

图24：比“是否美观”更先定下的，是人、场所、输入方式下会不会被打断。

粗略整理一下，大致是这样：

• ToC 优先考虑首次理解和安心感
• ToB 事务类 优先考虑持续效率和键盘支持
• ToB 监控 优先考虑不漏看和操作安全
• ToB 现场终端 优先考虑大操作对象和短路径
• 面向专业用户的工具 优先考虑密度、快捷键、可定制性
• 常驻工具 优先考虑不打扰用户

而不论用途，以下 6 点都是共通有效的：

1. 老老实实使用标准控件
2. 主要操作可以仅用键盘完成
3. 不会因触摸或辅助技术而卡住
4. 不会因文字放大或对比度主题而崩坏
5. 重要命令准备多条入口
6. 出了错也能退回来

UX 不是装饰，而是 一份关于操作的契约。 这份契约与使用者、环境、输入方式咬合得越好，Windows 应用就会用起来越朴实，也越扎实。

11. 参考资料

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

ToB 业务应用是否应该做成信息密集的高密度 UI？

只对了一半。对每天使用的熟练用户的事务录入类应用来说，高密度的一览性和键盘操作确实有助于持续效率。但在工厂、仓库、前台等现场终端或设备 UI 中，密度反而是敌人，应该优先考虑更大的操作对象、更短的操作路径和清晰明确。与其看 ToB 这个标签，不如看熟练度、输入方式和使用环境，这样更不容易判断失误。反过来，即使是 ToC，像图像编辑、投资分析这类面向高级用户的工具，也会优先考虑信息密度、快捷键和可定制性，而不是简单易用。

Windows 应用 UX 设计中最先应该确定的是什么？

只区分 ToC 还是 ToB 是不够的，需要先把 5 个问题明确出来：谁在使用（初学者、熟练用户还是混合）、在哪里使用（办公桌、现场、户外还是前台）、用什么操作（键盘、鼠标、触摸、扫描仪还是辅助技术）、使用频率有多高（以首次使用为主、偶尔、每天还是全天）、出错的代价是什么（轻微、严重、危险还是需要审计）。看清这 5 点之后，就更容易确定 UI 密度、导航方式、快捷键、确认对话框和可定制性的优先级。

应该如何选择导航模式？

并不存在对所有应用都适用的单一导航设计，一致性、简洁性和清晰度才是原则。作为选择的大致标准：想把所有导航项都显示在屏幕上时用顶部导航；顶层项目较多时用左侧导航；需要频繁切换项目、同时查看和更新详情的数据录入类场景适合列表/详情；想动态打开或关闭多个文档时用标签页；层级较深、容易迷失当前位置时用面包屑。导航不是外观上的喜好问题，而是信息结构和工作结构的体现。

确认对话框应该做到什么程度？

关键是不要什么都做成对话框。字段级的输入错误和可以当场修正的格式错误，比起对话框，更适合在界面内以内联方式展示。真正需要确认的，是停止、删除、屏蔽、覆写这类偏不可逆的操作。如果要弹对话框，至少应遵守这 3 点：第一行就明确写清楚会发生什么；按钮文案不要用 OK / Yes，而要具体化为删除、停止；必须放置一个安全且非破坏性的按钮。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。