我的知識庫

UIUX · 2026-10-20

閱讀時間約 24 分鐘

今天換一個角度：昨天談的是「生成式介面能不能被檢查」，今天找到四份能直接拿來用的實務材料。NN/G 10 月 9 日 Caleb Sponheim 以新版 Siri 為案例，提出 AI 助理介面的六個設計做法，其中最具體的一條是「確認過的資訊要在整個任務流程中保留」，案例是 Siri 說要用 Emmett 的地址當出發地，開啟的 Google 地圖卻顯示「你的位置」。Smashing 10 月 6 日 Vitaly Friedman 的《A Practical Guide To Naming Things》整理了元件、設計 token 與變數的命名資源。GOV.UK Design System 在 8 月起用「試用（Trial）」狀態標籤發布新元件，10 月的 GOV.UK Frontend 6.6.0 則把字數計數元件的算法換成 Intl.Segmenter。KDE Plasma 6.8 在 10 月 14 日內建了停留點擊（dwell clicker）。

四件事的共通點是：介面的可靠度常常不在畫面，而在「名稱、狀態標示、計數規則、輸入方式」這些容易被忽略的細節。每一節最後都給可以當天動手的做法。先對帳。

📖 學

一、昨天待驗的對帳

昨天的待驗今天查到狀態
USWDS 兩個承諾週期的更新與 GSA 回應GitHub 討論區清單前十筆中，維護者 ryparker 最新貼文仍是 9 月 22 日（「USWDS: our priorities」等），最新一筆是 10 月 5 日社群成員提的 React Native 元件庫點子，0 則回覆。Shipping news 2026 維基頁最新紀錄是 9 月 17 日編輯的八月底至九月初進度，沒有 10 月條目。GSA 回應沒查到無新增，查不到
HomeView pt 規格Apple 設計「What’s new」頁最新兩筆仍是 10 月 13 日的 Widgets（加入 HomeView 指引）與 Live Activities，其後沒有新條目；沒有看到 pt 規格仍未公布
Pitre 測試的模型與評分規則、Guidelines 遵守率今天沒有重新搜尋，沒有新資料待驗
11 月 13 日實機字高自算距今 24 天待驗
Intelligent UI 元件的無障礙說明今天沒有查到待驗

這張表和前幾天一樣：公開清單上看不到的，不代表不存在，只代表我沒讀到。

二、NN/G 的新 Siri 案例：AI 助理介面的六個做法

Sponheim 的論點是新版 Siri 的優勢不在「更聰明」，而在手機上本來就有的個人脈絡（訊息、相片、聯絡人、行事曆）加上把脈絡變成結果的能力，兩者缺一不可。依 NN/G 摘要，新 Siri 在 9 月 14 日開始以英文 beta 推出；我只讀到文章的抽取摘要，沒有自己操作，以下的測試描述都是 NN/G 的觀察，不是我的測試。

文章用四個任務做比較，結果並不一面倒：問「我哥哥 Emmett 推薦了哪些紐約的餐廳」，Siri 從簡訊找出三間早餐店並能回答「我去過嗎」的追問，ChatGPT 即使連了工作帳號也做不到；請它找出旅行相片，舊版 Siri 給網路圖片，新版找到作者自己的；請它「把 Emmett 推薦的餐廳清單傳給 Anna」，新版準備好正確的收件人與內容，舊版選錯聯絡人，還把指令原文當成訊息本文；但請它導航到 Emmett 的地址，Siri 先確認了「用 Emmett 的地址當出發地」，開啟的 Google 地圖卻顯示「你的位置」。這最後一個是文章的重點之一：模型在對話裡理解了，確認過的資訊卻在交棒給另一個 App 時掉了，使用者看到的是「它說了一套、做了另一套」。

文章歸納的設計做法，我整理成可以檢查的形式：

做法要檢查的問題
顯示搜尋了哪些來源，找不到時說明缺口並給復原路徑回答「找不到」時，使用者知道它找過哪裡嗎
不同解讀會導向不同動作時，先詢問它是否在含糊時直接動手
確認過的細節要保留到最後一步，包括跨 App最後一個畫面的參數，和對話裡確認的一致嗎
示範用的提示語要對應「真的搜得到」的資料範例提示語是否保證做得到
說明「搜了什麼」還不夠，要說明為什麼相關透明不等於使用者理解
高代價動作（例如傳訊息）要確認寄錯人時有沒有最後一道關

這和昨天的「生成式介面五問」互補：昨天的問題是畫面可不可信，今天的是任務流程中資訊會不會掉。兩者的共通工具是「預覽再執行」：在不可逆的動作前，把「我要用什麼資料做什麼」列在使用者看得到的地方。

三、命名：Smashing 的整理與一個可以自動檢查的規則

Friedman 的文章本身是資源彙整，不是研究，也沒有新數據；價值在把散落的工具放在一起。依我讀到的摘要，內容包括：Classnames（依主題整理的命名字詞庫）、David Aerne 的顏色名稱庫（文中寫 30,355 個名稱）、Javier Cuello 的命名準則（好名稱要「合邏輯、簡短、有意義、人人看得懂、與視覺屬性無關」）、Nate Baldwin 寫的 Intuit 設計 token 分類案例（服務 Mailchimp、QuickBooks、TurboTax、Mint 等多個產品）、Romina Kavcic 的 token 命名互動工具、Iain Bean 的 Component Gallery（文中寫超過 50 種 UI 元件的別名對照）、Vodafone UK 的變數分類圖（四個集合，從品牌與原始值對應到語意與頁面），以及 Erin Gannon 談功能命名的文章。

我認為最值得實作的是 Cuello 那一條「名稱不與視覺屬性綁定」。道理很實際：如果按鈕背景叫 blue-500，改品牌色或做深色模式時，名稱就變成謊言；如果叫 action-primary，換色只改一處對應。分層可以這樣做（這是業界常見的三層做法，Friedman 的文章只談到 Vodafone 的「從品牌與原始值到語意」，沒有逐字這樣寫）：

層例子誰可以引用
原始值（primitive）blue-500只有 token 檔自己
語意（semantic）color-action-primary元件
元件（component）button-background單一元件

這個規則可以用機器檢查：元件的樣式檔裡不應該出現原始值或寫死的顏色碼。我寫了一個極簡的掃描器，並在一份三行的範例 CSS 上驗證過會報出違規行；實際專案要自己加入白名單與檔案範圍，它只是起點。

// scan.mjs — 用法: node scan.mjs components/button.css
import { readFileSync } from 'node:fs';
const prim = /var\(--(?:red|green|blue|gray|grey|yellow|orange|purple|pink)-\d{2,3}\)|#[0-9a-fA-F]{3,8}\b/g;
const css = readFileSync(process.argv[2], 'utf8');
css.split('\n').forEach((line, i) => {
  const hits = line.match(prim);
  if (hits) console.log(`${i + 1}: ${hits.join(', ')}`);
});

對範例檔（第 1 行定義 --blue-500，第 3 行的 badge 直接引用它並寫死白色）它輸出第 1 行與第 3 行；第 1 行是 token 定義本身，所以要把掃描範圍限制在元件檔，不含 token 檔。

四、GOV.UK：「試用」狀態與字數計數的算法

GOV.UK Design System 的「What’s new」頁記載，8 月發布的 GOV.UK Frontend 6.5.0 新增兩個元件：回饋（Feedback）與語言導覽（Language navigation），兩者都掛上新的「Trial」狀態標籤。依其貢獻準則頁，一個元件要進入設計系統前，提案要證明有用且獨特，發布前要通過可用、一致、通用等準則，且必須用有代表性的使用者（含身障者）做過研究；「試用」是給「可能還沒滿足所有貢獻準則」的新元件或變體，先釋出以取得社群回饋。讀到的 GitHub 議題 5515 號（7 月 17 日開、8 月 21 日關）顯示，Feedback 指引頁要寫明為什麼是試用、做了哪些研究、要什麼才能升為穩定版，並附一個討論串。

這個做法對設計系統團隊很實用，因為它解決的是「全有或全無」問題：要嘛元件穩定了才給、要嘛私下流傳沒人知道狀態。把狀態寫在元件頁上，團隊才能決定要不要在正式服務使用，也才有地方回報問題。語言導覽元件頁的內容值得看：它說「除非能用另一種語言提供頁面上所有關鍵資訊，否則不要使用」；標記上是帶 aria-label 為 Language 的導覽區，目前語言用 aria-current 標示、其他語言為連結並帶 lang 與 hreflang；aria-label 要翻譯成頁面語言；深色背景用 inverse 修飾，並維持 4.5 比 1 的文字對比。這些都是我讀頁面摘要所得，沒有逐行核對原始碼。

另一個細節是 6.6.0 的字數計數元件。依 GitHub 發行頁摘要，這版改用 JavaScript 的 Intl.Segmenter 計數，新增 countType 選項（characters 或 words），舊的 maxwords 選項被棄用，改用 maxlength 搭配 countType 的 words（發行頁摘要的年份標示和 GOV.UK 頁面的 2026 年不一致，我判斷是抽取錯誤，以 2026 年 10 月為準，確切日期請回發行頁確認）。為什麼要換？我在本機（Node 25.8.2）跑了一個對照：

字串length展開後元素數Segmenter 字素數
Hello555
你好嗎333
家庭表情符號（三人）851
台灣旗幟421
e 加組合重音（拆開寫法）221

也就是用 length 計數時，一個家庭表情符號算 8 個字，使用者看到的是 1 個。字素計數對使用者來說才是「看到幾個就算幾個」。字數（words）模式更需要小心：我測的英文「Don’t stop-believing 3.5 times」得到 5 個字，中文「今天天氣很好」得到 3 個，這取決於各瀏覽器內建的詞典，不同環境可能不同，所以中文的字數限制不要靠它，改用字素計數較穩。元件頁的使用準則也值得抄：限制要設得高於大多數人需要的長度；超過限制時仍允許輸入並顯示錯誤，讓人能貼上完整答案再修剪；螢幕閱讀器只在停止輸入後朗讀計數，避免逐字干擾；只有研究顯示需要時才使用計數。

五、KDE Plasma 6.8：內建停留點擊

KDE Plasma 6.8 在 10 月 14 日發布（正好是 KDE 的 30 週年），並結束 X11 工作階段支援，只留 Wayland。新增的無障礙功能是停留點擊（dwell clicker）：指標停止移動一下就送出一次點擊，對癱瘓或無法按實體按鍵的人，不必再另外裝應用程式。依 Phoronix，它取代 X11 時代 KMouseTool 的功能，補上 Wayland 的缺口，實作分成兩個合併請求：KWin 提供核心功能，Plasma Desktop 提供設定小程式與控制模組；依報導有可調整的延遲、停留時間與動作門檻（各來源用詞不同，我沒有查到預設數值）。KDE 部落格同一週的紀錄還提到中鍵自動捲動多了「按一下進入、再按一下離開」的選用模式，比較接近 Windows 的 Autoscroll。

這件事對設計者的意義不在 Linux，而在「你的介面會被停留點擊與類似的輔助輸入使用」：這類使用者不是點擊，而是停留，所以介面要避免三種設計。第一，只靠 hover 才出現的選單與操作，因為停留到哪就點到哪，路過的元素會被誤觸；第二，過小而密的點擊目標，停留點擊的指標需要穩定落在目標上；第三，點擊後立刻出現的內容覆蓋，造成連鎖誤觸。WCAG 1.4.13（懸停或焦點內容）要求懸停出現的內容可關閉、可停留、持續到不再需要，這和停留點擊是同一個方向；10 月 18 日算過的 WCAG 2.5.8 最小目標 24 CSS 像素也是同一個方向。我沒有查到 Plasma 的實際門檻與誤觸率，所以不能說這些規則「足夠」，只能說它們是合理的方向。

🧠 記

  • NN/G 新 Siri 案例（10 月 9 日，Sponheim）： 個人脈絡加上把脈絡變結果的能力，缺一不可；確認過的資訊要保留到跨 App 的最後一步（導航案例掉了出發地）；高代價動作要確認；顯示搜尋來源並說明缺口。Siri AI 依摘要 9 月 14 日起英文 beta。
  • Smashing 命名指南（10 月 6 日，Friedman）： 資源彙整，沒有新數據；Cuello 準則是名稱不綁視覺屬性；Vodafone UK 用四個變數集合從原始值對應到語意與頁面。
  • 三層命名與掃描： 原始值只給 token 檔、元件引用語意名；掃描元件檔裡的原始值與色碼，掃描器是我自寫並在三行範例上驗證。
  • GOV.UK Trial 狀態： 6.5.0（8 月）新增 Feedback 與 Language navigation 兩個試用元件；6.6.0（10 月）字數計數改用 Intl.Segmenter，maxwords 棄用。
  • 字素計數（自測，Node 25.8.2）： 家庭表情符號 length 為 8、字素 1；中文的「words」模式視詞典而定，不穩。
  • KDE Plasma 6.8（10 月 14 日）： 內建停留點擊，Wayland 專屬；中鍵自動捲動新增切換模式；預設數值沒查到。
  • USWDS / HIG： USWDS 維護者最新貼文仍 9 月 22 日、10 月 5 日為社群點子；HIG 最新仍 10 月 13 日。

邊界： 本文所有網頁內容（NN/G、Smashing、GOV.UK 各頁、GitHub 發行頁與議題、KDE 公告與部落格、Phoronix、USWDS 討論區與維基、Apple 設計「What’s new」頁）都經網頁抽取摘要，沒有讀完整原文，也沒有親自操作 Siri、KDE 或 GOV.UK 元件。NN/G 的 Siri 測試描述是作者觀察，樣本與測試條件我沒讀到。GOV.UK 發行頁摘要的年份與日期有出入，已註明。命名三層是業界常見做法，非 Smashing 或 GOV.UK 的原文。掃描器只在三行範例驗證，非完整工具。字素與字數的結果是我在單一環境（Node 25.8.2）的一次測試，瀏覽器可能不同。停留點擊的預設參數沒查到，WCAG 對應是我的連結，不是 KDE 的說法。USWDS 與 HIG 的「沒有更新」只代表我在公開頁面沒看到。

✍️ 實踐

用 40 分鐘，替自己的元件庫做一次命名與狀態盤點，再試一次輔助輸入。

  1. 把 token 分成原始值、語意、元件三層，各列 5 個實際例子；找出名稱含顏色（blue、red）或尺寸形容（big、small）卻被元件直接引用的 token，列出前 10 筆。
  2. 用上面的掃描器掃元件樣式檔（排除 token 檔），記下違規行數；這是基準值，之後每次改版再掃一次。
  3. 為元件庫的每個元件標上狀態：穩定、試用、棄用。仿 GOV.UK，試用元件的頁面寫三句話：為什麼是試用、做過什麼研究、要什麼才能升為穩定。
  4. 如果你的表單有字數限制，用下面這段檢查它計算的是不是字素：
const seg = new Intl.Segmenter('zh-TW', { granularity: 'grapheme' });
const count = (s) => [...seg.segment(s)].length;
console.log('👨‍👩‍👧'.length, count('👨‍👩‍👧')); // 預期 8 與 1

把表單輸入同一個表情符號，看計數顯示 8 還是 1；若是 8，把計數改成字素；中文字數限制不要用 words 模式。 5. 對照第二節的六項做法，替你團隊的 AI 助理或自動化流程，挑一個跨兩個畫面的任務，記錄「對話裡確認的參數」與「最後一個畫面實際用到的參數」是否一致，把不一致的寫成一條缺陷。 6. 用鍵盤或系統內建的停留點擊（Windows、macOS 與 Linux 都有類似的輔助功能，各自名稱不同），把你的產品主要流程走一遍，只用停留、不按鍵，記下所有被誤觸的懸停元素與太小的目標。

🔗 延伸學習

💬 問 AI

我想把設計系統的命名、元件狀態與輸入方式做一次盤點。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、版本號、數字或引文,也不要給任何投資或財務建議。
 
背景(請當待查證主張):
1. NN/G 2026-10-09 Sponheim 文章以新版 Siri 為案例:導航任務中 Siri 確認用「Emmett 的地址」當出發地,但開啟的 Google 地圖顯示「你的位置」,屬於跨 App 的脈絡遺失;建議顯示搜尋來源、含糊時先詢問、確認的細節保留到最後一步、高代價動作要確認。
2. Smashing 2026-10-06 Friedman《A Practical Guide To Naming Things》:命名資源彙整,引用 Cuello「名稱不與視覺屬性相關」與 Vodafone UK 四個變數集合的分類圖。
3. GOV.UK Frontend 6.5.0(2026-08)新增 Feedback 與 Language navigation 兩個「Trial」狀態元件;6.6.0(2026-10)字數計數改用 Intl.Segmenter、新增 countType、棄用 maxwords。
4. KDE Plasma 6.8(2026-10-14)內建停留點擊(dwell clicker),取代 X11 的 KMouseTool 功能,僅 Wayland。
5. 我自測(Node 25.8.2):家庭表情符號 length 為 8、字素 1;英文 words 模式 Don't stop-believing 3.5 times 得 5 個字,中文今天天氣很好得 3 個。
 
請做:
A. 逐點驗證 1 到 4,標示「成立/部分成立/查不到」並附一手連結;特別確認第 3 點 6.6.0 的發布日期與 maxwords 的遷移方式,以及第 4 點停留點擊的預設延遲與動作門檻。
B. 針對第 5 點:不同瀏覽器與 Node 版本對字素與詞的切分是否一致?中文字數限制該用什麼計法?
C. 設計 token 分三層(原始值、語意、元件)時,常見的失敗模式有哪些?我該如何用 lint 規則檢查「元件不得直接引用原始值」,並避免誤報?
D. 為「試用/穩定/棄用」三種元件狀態,各寫進入條件、頁面需要的資訊與退出條件。
E. 列出會讓停留點擊使用者誤觸的 5 種常見介面模式,並各給一個可自動檢查或需人工測試的判準。
不要評論公司或人事,只談設計實務、量測方法與證據強度。

反向連結