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，比外觀更早由一整束使用情境決定。

更麻煩的是，BtoC 和 BtoB 的重心不一樣。 不過，如果在這裡想成「BtoB 所以資訊塞滿就好」「BtoC 所以做得輕柔一點就好」，通常某個環節會出事。

舉例來說，同樣是 BtoB，

• 會計登打或訂單管理這類的事務類應用程式
• 工廠、倉庫、接待櫃台、檢查設備這類的現場作業用電腦
• 24 小時監控與維護處理的維運畫面

三者對「好 UX」的條件差很多。

反過來說，即使同樣是 BtoC，

• 個人用的小型工具程式
• 影像編輯、音樂製作、投資分析這類偏向進階使用者的工具

兩者對 UI 密度與快速鍵操作的要求也完全不同。

flowchart TB
    accTitle: 標籤相同條件卻不同
    accDescr: 說明同樣是 BtoB，事務類應用程式、現場作業用電腦與維運畫面對好 UX 的條件差很多，而同樣是 BtoC，小型工具程式與偏向進階使用者的工具對密度與快速鍵操作的要求也完全不同的圖。
    b0["BtoB 這個相同的標籤"] --> b1["事務類、現場作業用電腦、維運畫面"]
    b1 --> b2["好 UX 的條件差很多"]
    c0["BtoC 這個相同的標籤"] --> c1["工具程式、進階使用者工具"]
    c1 --> c2["對密度與快速鍵操作的要求也不同"]

圖 2: 在 BtoC / BtoB 這種相同標籤之中，好 UX 的條件仍會分岔。

Microsoft 針對 Windows 的設計指引，同樣重視 Windows 應用程式的設計要 直覺、容易存取，並且跨輸入方式與板型規格都能一致運作。¹²

本文把 Windows 應用程式的 UX 梳理成一張 依用途分類的判斷表。 目的是在設計審查或畫面設計的初期階段，讓「這個應用程式該優先什麼」比較容易分辨。

本文的目標讀者與前提

本文使用的用語

1. 先講結論

先粗略地說，結論是這樣。

• BtoC 優先 第一次就容易看懂、讓人安心、設定少、動線直接了當
• BtoB 優先 持續使用效率、防止誤操作、鍵盤支援、穩定的配置
• 但是 BtoB 的現場作業用電腦，優先的是 明快、大的操作目標、短的動線，而不是密度
• 但是 BtoC 的進階使用者工具，優先的是 資訊密度、快速鍵、可自訂性，而不是簡單
• 在 Windows 應用程式上，把 鍵盤 / 滑鼠 / 觸控 / 文字放大 / 對比佈景主題 / 輔助技術 一起納入 UX 來思考，之後設計比較不容易壞掉¹³⁴⁵⁶⁷

一開始真正該決定的，不只是 BtoC 還是 BtoB。 要先講清楚的是下面這 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: 比起 BtoC 還是 BtoB，先把 5 個問題講清楚，優先順序才定得下來。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 23 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. BtoC / BtoB 是入口，不是答案

BtoC / BtoB 這種分法，當作最初的入口很方便。 不過，決定 UX 正確答案的力量，來自使用方式的種類，而不是買方的種類。

例如，粗略地用兩個軸來看，大致是這樣。

也就是說，

• BtoC = 永遠是輕量 UI
• BtoB = 永遠是高密度 UI

這兩個等式並不成立。

Windows 應用程式的設計指引同樣重視 跨裝置、跨輸入類型、跨板型規格都能一致使用；從無障礙的角度來看，除了使用者本身是否有障礙之外，把 明亮的戶外、共用空間、安靜的地方、吵雜的地方 這類環境限制也一併納入考量，同樣重要。¹²

flowchart TB
    accTitle: 使用方式的種類比買方的種類重要
    accDescr: 說明 BtoC 永遠是輕量 UI、BtoB 永遠是高密度 UI 這兩個等式並不成立，決定 UX 正確答案的力量來自使用方式的種類而不是買方的種類的圖。
    e1["BtoC = 永遠是輕量 UI"] --> e3["這個等式不成立"]
    e2["BtoB = 永遠是高密度 UI"] --> e3
    e3 --> e4["決定正確答案的是使用方式的種類"]
    e4 -.-> e5["連環境限制也一起納入考量"]

圖 4: 決定 UX 正確答案的，是使用方式的種類，而不是買方的種類。

所以，看過 BtoC / BtoB 之後，建議再用下面這些軸繼續切。

先把這裡切開，會議中「感覺很現代」「感覺很像業務系統」這類討論就會少很多。

3. 一頁看完的依用途判斷表

先放上實務上最好用的那張表。

光看這張表，大致的方向就出來了。 特別重要的是 即使是 BtoB，現場作業用電腦的正解也不是高密度 UI，以及 即使是 BtoC，進階使用者工具也是效率勝過輕量。

flowchart TB
    accTitle: 標籤與正解逆轉的兩個例子
    accDescr: 說明即使是 BtoB，現場作業用電腦的正解也不是高密度 UI，即使是 BtoC，進階使用者工具也是效率勝過輕量，這兩個從標籤想像的正解會逆轉的例子的圖。
    f1["BtoB 的現場作業用電腦"] --> f2["高密度 UI 不是正解"]
    f3["BtoC 的進階使用者工具"] --> f4["效率勝過輕量"]
    f2 --> f5["不看標籤，看用途來決定"]
    f4 --> f5

圖 5: 判斷表中特別重要、標籤與正解逆轉的兩列。

如果趕時間，讀到這一章就停下來也沒關係。 接下來的第 4 章，是把這張表的每一列展開成「為什麼會這樣」「具體要放什麼」。表裡已經寫過的結論不會重複，可以只讀表裡放不下的判斷材料。

4. 各用途的設計方針

4.1 BtoC 工具程式 / 個人用應用程式

在 BtoC 的小型 Windows 應用程式上，「啟動後馬上就能用」 比什麼都強。

特別想重視的是這些。

• 第一個畫面就看得出這是做什麼的應用程式
• 主要操作收斂在一到兩個
• 空狀態不會讓人不知所措
• 危險的操作可以取消
• 不要一開始就把設定項目全部攤開

這裡很容易就會這樣做：把技術上做得到的東西全部排出來。 但在 BtoC 的輕量工具上，馬上就能用 比 功能多 更有價值的場合更多。

Windows 的導覽設計同樣沒有適用於所有應用程式的唯一正解，首先重視的是 一致性、簡單與明快。使用標準控制項與使用者預期的位置，畫面會更容易預測。⁸

所以在 BtoC 取向上，

• 規模小就用單一畫面
• 各區塊是並列關係就用上方導覽列
• 設定分階段呈現
• 主要動作亮一點，其他安靜一點

大致整理到這種程度，通常就夠了。

flowchart TB
    accTitle: BtoC 取向的整理方向
    accDescr: 說明 BtoC 取向以啟動後馬上就能用為軸，規模小就用單一畫面、各區塊並列就用上方導覽列、設定分階段呈現、主要動作亮一點其他安靜一點，整理到這種程度通常就夠的圖。
    g1["啟動後馬上就能用"] --> g2["規模小就用單一畫面"]
    g1 --> g3["並列就用上方導覽列"]
    g1 --> g4["設定分階段呈現"]
    g4 -.-> g5["主要動作亮一點，其他安靜一點"]

圖 6: BtoC 的輕量工具，整理方向要往「馬上就能用」而不是「功能多」靠。

不過，即使是 BtoC，一旦變成 照片編輯、影片剪輯、作曲、投資分析、開發輔助 這類進階使用者取向的應用程式，情況就不一樣了。 這種時候，看 熟練度 與 使用時間，會比看 BtoC 這個標籤更接近正解。

4.2 BtoB 資料登打與後台作業

事務類 BtoB 應用程式重要的，不是外觀上的輕盈，而是 作業不會停下來。

每天使用的使用者，幾天內就會習慣 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 BtoB 監控與維運

監控與維運畫面的 UX，比「好不好用」更重要的是 不漏看、不弄錯、不停下來。

這裡的優先順序，大致是這樣。

• 一眼就看得出有沒有異常
• 看得出異常的嚴重程度
• 除了目前值，也追得到變化與時間序列
• 危險操作的動線不要太輕鬆
• 能馬上跳到日誌、歷史紀錄與原因調查

在這類畫面上，狀態的呈現 是 UX 的核心。 狀態盡量用 顏色 + 文字 + 圖示 + 時刻 這種多重要素來表示會比較安全。 只用顏色表示狀態，容易發生漏看與辨識錯誤，在無障礙上也比較弱。¹¹

flowchart TB
    accTitle: 狀態要用多重要素表示
    accDescr: 說明監控與維運畫面的核心是狀態呈現，只用顏色表示容易發生漏看與辨識錯誤，因此用顏色、文字、圖示與時刻這種多重要素表示比較安全的圖。
    i1["只用顏色表示狀態"] --> i2["容易漏看、辨識錯誤"]
    i2 -.->|"改成"| i3["用顏色+文字+圖示+時刻表示"]
    i3 --> i4["漏看與誤認都減少，比較安全"]

圖 8: 監控畫面的狀態，要用多重要素的組合而不是只用顏色表示。

導覽方面，監控對象多就用左側導覽列，個別對象往下挖用向下鑽研，詳細內容用日誌或時間序列呈現，這樣整理比較好處理。 Windows 的導覽指南也指出，左側導覽列適合 最上層項目很多 的情況，以及頁面切換不會沒完沒了的結構。⁸

在操作方面，把命令只放在一個地方同樣危險。 Windows 的命令設計指南建議，命令要能 從按鈕、內容功能表、快速鍵、手勢等多個面向使用，並且 把所有相關命令都放進內容功能表或 CommandBarFlyout。因為一旦依賴只在 hover 時才出現的操作，在觸控裝置或輔助技術上就無法使用了。¹²¹³

危險操作的確認對話方塊，在這裡也很重要。 不過「總之什麼都確認一下」會有反效果。 真正想確認的，是 停止、刪除、切換、切斷、覆寫 這類偏向不可逆的操作。 要出對話方塊的話，

• 第一行就把會發生什麼寫清楚
• 按鈕文字不要用 OK / Yes，而要像 刪除 / 停止 / 切斷 這樣具體
• 一定要放一個安全的按鈕

這三件事至少要守住。¹⁰

flowchart TB
    accTitle: 確認對話方塊的三個原則
    accDescr: 說明真正想確認的是停止、刪除、切斷等偏向不可逆的操作，要出對話方塊就要在第一行寫清楚會發生什麼、按鈕文字要具體、一定要放安全按鈕的圖。
    j1["只確認偏向不可逆的操作"] --> j2["第一行就寫清楚會發生什麼"]
    j1 --> j3["按鈕文字要具體"]
    j1 --> j4["一定要放安全的按鈕"]
    j2 -.-> j5["「總之什麼都確認」有反效果"]

圖 9: 確認對話方塊要收斂到不可逆操作，並守住三個最低限度。

4.4 BtoB 現場作業用電腦、設備 UI、自助服務機

現場作業用電腦在 Windows 應用程式的 UX 之中，算是相當不同的一類。

• 不是坐著的
• 可能戴著手套
• 只有一隻手空著
• 不會盯著畫面慢慢看
• 有時間壓力
• 在明亮的現場或吵雜的地方使用

這些條件很常出現。

Microsoft 的無障礙指引也指出，好的 Windows 應用程式除了使用者是否有障礙之外，還要考量 強烈日照、共用空間、噪音、安靜、正在做菜之類的情境 等環境限制。²

另外在觸控的設計上，

• 觸控 沒有 hover
• 手指或手掌會 擋住（occlusion） UI
• 畫面上有些位置 以手的姿勢來說很難按
• 視覺回饋很重要

有這些差異。⁴

flowchart TB
    accTitle: 觸控設計的四個差異
    accDescr: 說明觸控沒有 hover、手指或手掌會擋住 UI、畫面上有些位置以手的姿勢來說很難按、視覺回饋很重要這些設計上差異的圖。
    k1["觸控操作"] --> k2["沒有 hover"]
    k1 --> k3["手指或手掌會擋住 UI"]
    k1 --> k4["有些位置以姿勢來說很難按"]
    k4 -.-> k5["視覺回饋變得很重要"]

圖 10: 觸控在 hover 與遮蔽上的前提不同，回饋怎麼呈現成了關鍵。

所以在現場作業用電腦上，大致往這些方向靠。

• 按鈕與清單項目要夠大
• 盡量接近一個畫面一個目的
• 操作後的反應要清楚呈現
• 把流程分成階段
• 輸入盡量從 自由輸入靠向選擇、掃描與制式格式
• 狀態要在畫面上方或中央明快地呈現

反過來想避免的是，

• 小的文字
• 小的可觸發範圍
• 依賴以 hover 為前提的工具提示
• 深的階層
• 一個畫面塞大量資訊
• 長篇的自由輸入

這些。

「因為是 BtoB，所以密度高一點比較好」這種草率的想法，最容易在這個領域失準。 這裡反而是 業務應用程式之中特別以明快為優先 的世界。

flowchart TB
    accTitle: 現場作業用電腦以明快為優先
    accDescr: 說明現場作業用電腦要盡量接近一個畫面一個目的，輸入從自由輸入靠向選擇、掃描與制式格式，操作後的反應要清楚呈現，是業務應用程式之中特別以明快為優先的方向的圖。
    l1["現場作業用電腦、設備 UI"] --> l2["盡量接近一個畫面一個目的"]
    l1 --> l3["輸入靠向選擇、掃描、制式格式"]
    l1 --> l4["操作後的反應要清楚呈現"]
    l2 --> l5["業務應用程式中特別以明快為優先"]
    l3 --> l5
    l4 --> l5

圖 11: 現場作業用電腦要靠向明快、大的操作目標與短的動線，而不是密度。

4.5 專家用的編輯與分析工具

在專家用的工具上，「希望做得更好懂」有時會輸給「不要讓我的手停下來」。

例如，

• CAD
• 波形分析
• 影片剪輯
• 影像處理
• 音樂製作
• 開發輔助
• 資料分析
• 稽核 / 診斷工具

這類的東西。

在這類應用程式上，下面這些要素會派得上用場。

• 資訊密度
• 多窗格
• 索引標籤
• 內容功能表
• 快速鍵
• 版面配置的儲存
• 欄位與顯示項目的自訂
• Undo / Redo
• 作業狀態的復原

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 的導覽指南先指出 沒有一種導覽設計對所有應用程式都有效，再以 一致性、簡單與明快 為原則。此外，把標準控制項放在使用者預期的位置，UI 就會變得容易預測。⁸

flowchart TB
    accTitle: 導覽設計的原則
    accDescr: 說明沒有一種導覽設計對所有應用程式都有效，要以一致性、簡單與明快為原則，並把標準控制項放在使用者預期的位置讓 UI 容易預測的圖。
    s0["沒有唯一的正解模式"] --> s1["一致性"]
    s0 --> s2["簡單"]
    s0 --> s3["明快"]
    s3 -.-> s4["把標準控制項放在預期的位置"]

圖 14: 導覽沒有唯一正解，靠三個原則與標準位置讓畫面容易預測。

在實務上，大致用這張表來切會比較好思考。

Windows 的導覽指南特別給出了下面這樣的取捨。⁸

• 上方導覽列: 想把所有導覽項目都顯示在畫面上時
• 左側導覽列: 最上層項目多、不會頻繁切換頁面時
• 清單／詳細資料: 項目切換多，需要檢視與更新詳細內容時
• 索引標籤: 想動態開關多份文件或頁面時
• 麵包屑: 階層深，想讓回頭的路清楚可辨時

5.1 只有骨架的線框圖

光用文字不容易在腦中成形，所以把四個代表性的骨架並排放上來。 細節請先忽略，只看 什麼東西放在哪裡。

[ 上方導覽列 ]  想把同一層級的頁面全部呈現時
+-------------------------------------------------------------
| AppName        首頁 | 轉換 | 歷程 | 設定
+-------------------------------------------------------------
|
|    主內容
|    靠向一個畫面一個目的
|
+-------------------------------------------------------------


[ 左側導覽列 ]  最上層項目多的時候
+-------------------------------------------------------------
| AppName                                 搜尋 [           ]
+-------------------------------------------------------------
| 儀表板          |
| 設備清單        |    主內容
| 警示            |
| 工作            |
| 報表            |
| 設定            |
+-------------------------------------------------------------


[ 清單／詳細資料 ]  一邊切換項目，一邊檢視與更新詳細內容
+-------------------------------------------------------------
| 搜尋 [          ]  篩選: 未處理 / 全部            [新增] [刪除]
+-------------------------------------------------------------
| 清單             |  詳細 / 編輯
|  > 傳票 1001     |    傳票號碼   1001
|    傳票 1002     |    交易對象   ...
|    傳票 1003     |    明細列     ...
|    傳票 1004     |
|                  |    [ 儲存 ]   [ 取消 ]
+-------------------------------------------------------------


[ 儀表板 + 向下鑽研 ]  找出異常再往下挖
+-------------------------------------------------------------
| 全體   正常 22    注意 3    異常 1        更新於 0.5 秒前
+-------------------------------------------------------------
| 異常 1 件
|   ! B 線檢查設備      沒有回應    48 秒前    [ 詳細 ]
| 注意 3 件
|   - A 線相機          值已過期    12 秒前    [ 詳細 ]
|   ...
+-------------------------------------------------------------
              |
              |  按下 [ 詳細 ]
              v
+-------------------------------------------------------------
| < 回到清單         B 線檢查設備 / 沒有回應
+-------------------------------------------------------------
| 目前值 | 時間序列圖 | 事件日誌 | 操作
+-------------------------------------------------------------

把四個並排之後，選擇的軸就清楚了。

• 上方導覽列與左側導覽列的分界，是最上層項目的數量。全部能橫向排完就用上方，排不完就用左側
• 清單／詳細資料的主角不是右邊，而是左邊的清單。清單的資訊量不夠，就得反覆重新打開詳細內容
• 儀表板的要點，是把「異常有幾件」放在第一行。往下挖之後，一定要準備好回頭的路

總之，導覽不是「外觀上的偏好」，而是 資訊結構與作業結構的呈現。

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 按下的元素要按得下去
• 重要功能要有快速鍵
• 高頻操作要準備便捷鍵或快速鍵（accelerator）

觸控方面則有這些特性。⁴

• 沒有 hover
• 手指或手掌會擋住 UI
• 按得到的位置感覺比看起來窄
• 需要視覺回饋
• 適合直接操作的 UI 和適合間接輸入的 UI 並不一樣

6.1 不用「夠大」，用數字決定

設計審查中最容易爭執的，是 停在「夠大」「清楚一點」就不往下走。 Microsoft 的指南有給數值的項目，直接把那個數值當成合格與否的基準，討論會短很多。

數值定下來之後，審查的說法也會變。 從「這個按鈕會不會太小」變成「這個按鈕是 32px，沒有達到 7.5 mm 的基準」，要不要改的判斷就能當場結束。

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 按下
• 有沒有快速鍵
• 右鍵對應的操作能不能用鍵盤叫出來

雖然不起眼，但這裡一垮，BtoB 的 UX 會相當痛。

7.2 文字放大、對比佈景主題與無障礙

在 Windows 應用程式上，光是好好跟上文字大小與對比，UX 就會穩定不少。

Microsoft 的指南建議 可見文字的對比度至少 4.5:1，並要求文字放大時 控制項與容器也要跟著調整大小與重新排列。⁵⁶

在對比佈景主題方面，則建議

• 不要把顏色寫死
• 使用 SystemColor / Brush 資源
• 用 4 種對比佈景主題測試

這些做法。⁷

這裡容易垮掉的是，

• 以固定寬度為前提的標籤
• 以像素固定的按鈕高度
• 只用顏色傳達意思的設計
• 自訂繪製、不跟著佈景主題調整的 UI

這些。

與其說這一塊是「無障礙支援」，不如把它當成 打造長期不壞的 Windows UI 的基礎工程，感覺會更貼切。

flowchart TB
    accTitle: 撐得住放大與佈景主題的基礎工程
    accDescr: 說明以固定寬度為前提的標籤、以像素固定的高度、只用顏色傳達意思、不跟著佈景主題調整的自訂繪製容易垮掉，不把顏色寫死而使用資源並用對比佈景主題測試，才是長期不壞的 Windows UI 基礎工程的圖。
    y1["固定寬度標籤、以像素固定的高度"] --> y3["放大或切換佈景主題就垮掉"]
    y2["只用顏色傳達意思、自訂繪製"] --> y3
    y3 --> y4["不把顏色寫死，改用資源"]
    y4 --> y5["用 4 種對比佈景主題測試"]
    y5 -.-> y6["長期不壞的 UI 基礎工程"]

圖 19: 跟上文字放大與對比佈景主題，屬於 UI 的基礎工程。

7.3 不要濫用對話方塊

對話方塊很方便，但用過頭就會變成作業的敵人。

Windows 的對話方塊指南把對話方塊定位成需要 通知、核准、輸入補充資訊 時使用的 強制回應（modal）UI，並建議至少放一個 安全且不具破壞性的操作（Close、Cancel 等）。此外也指出，按鈕文字最好寫成 具體的回應。¹⁰

重要的是 不要什麼都做成對話方塊。

尤其是，

• 以欄位為單位的輸入錯誤
• 當場就能改的格式錯誤
• 暫時性的提醒

這些盡量收攏成行內顯示會比較自然。¹⁰

7.4 重要命令要有多條路徑

在 Windows 的命令設計上，重視重要命令要能 從各種輸入方式與 UI 面向叫出來。¹²¹³

這在實務上也很管用。

例如「刪除」，如果有

• 工具列
• 內容功能表
• Delete 鍵
• 必要時的滑動

這樣多條路徑，使用起來就會穩定。

反過來說，

• 只在 hover 時才出現在右端
• 只有右鍵才叫得出來
• 用鍵盤永遠到不了

這種設計，一旦輸入方式改變就會突然變弱。

7.5 用測試工具查看

無障礙與其在腦中想「應該沒問題吧」，不如用工具看還比較快。

Microsoft 的無障礙測試指南介紹了使用 Accessibility Insights for Windows 的 Live Inspect、FastPass 與 Troubleshooting，另外也可以用 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 不只是「按起來很舒服的按鈕」，也由 出事之後回得去 決定。

例如，

• Undo / Redo
• 自動儲存
• 保留編輯中的狀態
• 篩選 / 排序 / 欄寬的復原
• 中斷與繼續
• 長時間處理的進度與取消

這些對 UX 的作用，比外觀大得多。

尤其在 BtoB 或專家取向上，必須重做一次的壓力 會直接變成 UX 的糟糕程度。

flowchart TB
    accTitle: 可復原性決定 UX
    accDescr: 說明 UX 不只是按起來舒服的按鈕，也由出事之後回得去決定，Undo 與 Redo、自動儲存、狀態復原、長時間處理的進度與取消都能減少重做一次的壓力的圖。
    ba1["Undo / Redo、自動儲存"] --> ba4["出事之後回得去"]
    ba2["編輯中狀態、顯示的復原"] --> ba4
    ba3["進度顯示與取消"] --> ba4
    ba4 -.-> ba5["必須重做一次的壓力就是 UX 的糟糕程度"]

圖 21: UX 不只看好不好按，也看出事之後回得去的可復原性。

8. 常見的設計錯誤

8.1 認定「因為是 BtoB，所以做成高密度就好」

這只對了一半。

面向每天使用的熟手使用者時，高密度確實有時候管用。 但在現場作業用電腦、接待櫃台電腦與設備 UI 上，密度反而是敵人。

與其看 BtoB 這個標籤，不如看 熟練度、輸入方式、使用環境，比較不容易失準。

8.2 認定「因為是 BtoC，所以把功能藏太多」

即使是個人取向，只要是熟手取向的工具，效率就是最優先。

如果什麼都往「看起來很簡單」的方向拉，

• 高頻操作變遠
• 每次都要往功能表裡挖
• 一直在切換畫面

這種安靜的地獄就開始了。

flowchart TB
    accTitle: 標籤先入為主的兩個陷阱
    accDescr: 說明「因為是 BtoB 所以做成高密度就好」的想法在現場作業用電腦上會失準，而「因為是 BtoC 所以把功能藏太多」會讓熟手的高頻操作變遠這兩個陷阱的圖。
    ca1["因為是 BtoB 所以高密度"] --> ca2["在現場作業用電腦上密度是敵人"]
    ca3["因為是 BtoC 所以藏起來"] --> ca4["熟手的高頻操作變遠"]
    ca2 --> ca5["改看熟練度、輸入方式、使用環境"]
    ca4 --> ca5

圖 22: 「BtoB 就高密度」「BtoC 就簡單」這種先入為主，會朝反方向失準。

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: 比起「漂不漂亮」，先決定人、地點與輸入方式會不會卡住。

粗略整理起來，是這樣。

• BtoC 優先第一次就看得懂與安心感
• BtoB 事務類 優先持續使用效率與鍵盤支援
• BtoB 監控 優先防止漏看與安全的操作
• BtoB 現場作業用電腦 優先大的操作目標與短的動線
• 專家用工具 優先密度、快速鍵與可自訂性
• 常駐工具 優先不打擾人

而不分用途都共通管用的，是下面這 6 點。

1. 直接了當地使用標準控制項
2. 主要操作能用鍵盤走完全程
3. 用觸控或輔助技術也不會卡住
4. 文字放大或對比佈景主題也不會亂掉
5. 為重要命令準備多條路徑
6. 出事之後回得去

UX 不是裝飾，而是 操作的契約。 這份契約和使用者、環境與輸入方式咬合得越好，Windows 應用程式就會不起眼卻很有力地好用起來。

11. 參考資料

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

BtoB 的業務應用程式應該做成塞滿資訊的高密度 UI 嗎？

只對了一半。每天使用、面向熟手使用者的事務登打類應用程式，高密度帶來的一眼看完的資訊量與鍵盤全程操作，確實對持續使用效率有幫助。但工廠、倉庫、接待櫃台這類現場作業用電腦與設備 UI，密度反而是敵人，應該優先大的操作目標、短的動線與明快。與其看 BtoB 這個標籤，不如看熟練度、輸入方式與使用環境，比較不容易失準。反過來說，即使是 BtoC，影像編輯或投資分析這種進階使用者取向的工具，優先的也是資訊密度、快速鍵與可自訂性，而不是簡單。

設計 Windows 應用程式的 UX 時，最先該決定什麼？

只分 BtoC 或 BtoB 並不夠，要先把 5 個問題講清楚。誰使用（初學者、熟手、混合）、在哪裡使用（辦公桌、現場、戶外、接待櫃台）、用什麼操作（鍵盤、滑鼠、觸控、掃描器、輔助技術）、使用得多頻繁（以第一次為主、每天、整天）、失誤時的成本是什麼（輕微、嚴重、危險、屬於稽核對象）。這 5 點看清楚之後，UI 的密度、導覽、快速鍵、確認對話方塊與可自訂性的優先順序就容易決定了。

導覽模式該怎麼選？

沒有一種導覽設計對所有應用程式都有效，原則是一致性、簡單與明快。大致的參考值是：想把所有導覽項目都顯示在畫面上時用上方導覽列；最上層項目很多時用左側導覽列；一邊頻繁切換項目、一邊檢視或更新詳細內容的資料登打類，用清單／詳細資料；想動態開關多份文件時用索引標籤；階層很深、容易搞不清楚目前位置時用麵包屑。導覽不是外觀上的偏好，而是資訊結構與作業結構的呈現。

確認對話方塊該出到什麼程度？

重點是不要什麼都做成對話方塊。以欄位為單位的輸入錯誤，以及當場就能改的格式錯誤，收攏成畫面內的行內顯示比較自然。真正需要確認的是停止、刪除、切斷、覆寫這類偏向不可逆的操作。要出對話方塊的話，至少守住三件事：第一行就把會發生什麼寫清楚；按鈕文字不要用 OK／Yes，而要像「刪除」「停止」這樣具體；一定要放一個安全且不具破壞性的按鈕。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。