Windows 应用 UX 设计 - 按使用场景划分的优先级

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

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

• 能否仅用键盘就完成操作
• 是以鼠标为前提，还是以触摸为前提
• 是长时间使用，还是偶尔用几分钟
• 是监控场景、录入场景，还是现场终端
• 出错时会损坏什么
• 能否适应文字放大、高对比度主题和辅助技术

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

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

例如，同样是 ToB，

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

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

反过来，即便是 ToC，

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

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

Microsoft 面向 Windows 的设计指南同样强调，Windows 应用的设计应当 直观易用，并能在不同输入方式和外形规格之间保持一致的体验。¹²

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

1. 先说结论

先粗略地把结论摆出来。

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

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

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

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

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

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

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

也就是说，

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

并不成立。

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

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

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

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

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

光看这张表，大致方向就已经能看出来了。 特别要注意的是，ToB 也不代表现场终端就该做高密度 UI，反过来，ToC 的高级用户工具，效率优先于轻量简洁。

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

4.1 ToC 实用工具 / 个人应用

对于面向 ToC 的小型 Windows 应用，“打开就能用” 是最重要的。

尤其要重视以下几点：

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

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

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

因此，对于 ToC 而言，大致遵循以下原则就足够了：

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

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

4.2 ToB 事务录入 / 后台办公

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

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

• 能否仅用键盘完成大部分操作
• 能否顺畅地在列表和明细之间切换
• 重要的列和状态是否一目了然
• 是否能保持筛选和排序状态
• 错误能否当场修正

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

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

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

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

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

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

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

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

4.3 ToB 监控与运维

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

这里的优先级大致如下：

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

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

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

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

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

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

¹⁰

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

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

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

这些条件都很常见。

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

另外，在触摸设计方面：

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

存在这些差异。⁴

因此现场终端大致应朝以下方向设计：

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

反过来，应避免：

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

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

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

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

例如：

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

这些都是典型例子。

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

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

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

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

因此，面向高级用户的设计，通常这样会更有效：

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

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

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

例如：

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

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

应优先考虑：

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

应避免：

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

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

5. 导航模式判断表

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

在实务中，大致可以用下表来划分。

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

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

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

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

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

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

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

键盘方面尤其要注意以下几点：³⁹

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

触摸方面有以下特性：⁴

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

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

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

并且建议 把所有相关命令都放进右键菜单或 CommandBarFlyout。如果只依赖 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 的基础工程，这样更容易理解。

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 检查主要元素的名称、角色、模式
• 仅用键盘走通主要流程
• 测试文字放大和高对比度主题

这样后期返工会少很多。

7.6 加入可恢复性设计

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

UX 不只由”按下去很爽的按钮”决定，也由 即使出了差错也能恢复 来决定。

例如：

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

这些对 UX 的影响，远比外观来得大。

尤其在 ToB 或专业用户场景中，重复操作带来的压力，本身就是 UX 差的直接体现。

8. 常见设计误区

8.1 认为”因为是 ToB，就该做高密度 UI”

这个说法只对了一半。

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

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

8.2 认为”因为是 ToC，就要把功能藏起来”

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

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

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

这种”安静的地狱”。

8.3 设计依赖 hover 的操作

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

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

8.4 只用颜色表达状态

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

配合文字、图标、时间、数量、说明一起呈现，可以减少漏看和误判。¹¹

8.5 把所有校验错误都做成对话框

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

局限在上下文中的错误，最好在界面内当场展示会更自然。¹⁰

8.6 使用固定尺寸的布局

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

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

就会轻易崩坏。⁶⁷

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

8.7 过度自制自定义控件

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

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

标准控件把这些都照顾到了，如果没有理由地全部自己实现，UX 和无障碍方面的负债只会不断增加。⁸³

9. 开工前要回答的 8 个问题

最后，给出一组适合放在设计评审最开始的 8 个问题。

先回答好这 8 个问题，

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

这些就会自然而然地明确下来。

10. 总结

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

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

• 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 密度、导航方式、快捷键、确认对话框和可定制性的优先级。

应该如何选择导航模式？

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

作者简介

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

Go Komura

小村软件有限公司 代表

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