Vitaly Friedman 在 Smashing Magazine 的〈A Practical Guide To Naming Things〉(2026-10-06)主張,命名是設計系統與產品裡常被低估的問題:名稱會塑造團隊怎麼思考一件事,而設計師、工程師、產品經理與使用者各說各的詞,就是溝通成本的來源。讀到的程度:我用網頁擷取工具讀到這篇,回傳的是工具整理的摘要而非逐字原文,所以引文只放短句;文章本身多半是資源彙整,我沒有逐一打開文中列出的外部工具,也沒有驗證它們的內容與現況。
📖 學
一、名稱的兩種失敗方向
依摘要,文章指出名稱可能太籠統,意思不清楚;也可能太具體,限制了彈性與重用。這在 design token 上最明顯:名稱若綁死外觀(例如寫成某個顏色),日後換主題或改品牌色時名稱就會說謊;名稱若只寫「主要」「次要」,又讓人不知道用在哪裡。這是文章點出的取捨,具體怎麼拿捏,需要依自己的系統規模判斷。
二、最好的名稱是團隊與使用者都懂的名稱
摘要提到,文章認為好名稱是團隊與使用者雙方都能理解的,因為各角色用不同詞彙會讓團隊白白損失時間。文章甚至提出,功能採用率低有時是命名問題,因為功能找不到可能出在名字沒有傳達結果,建議把命名衝突記在待辦清單裡追蹤。功能名稱則應來自使用者自己的用語,並暗示功能帶來的成果。我的判讀(非原文):這等於把命名當成可以被排進 backlog 的設計債,而不是開會時順口決定的小事。
三、依對象分層的命名資源
文章的結構是按命名對象分段,每段推薦外部資源,而不是提出一套自己的規則。依摘要,涵蓋以下幾類:
| 命名對象 | 文中推薦的資源與重點 |
|---|---|
| 程式碼(class、函式) | Classnames 主題字詞清單 |
| 顏色 | 約 30,000 個社群整理的顏色名稱與 Color Parrot |
| 圖層與群組 | goodpractices.design:邏輯清楚、簡短、有意義,不綁視覺屬性 |
| Design token | Intuit 的彈性 token 分類法,跨多個產品共用 |
| UI 元件 | Component Gallery(列出超過 50 種元件與別名)、Name That UI(視覺字典) |
| 新功能 | Erin Gannon 的功能命名指南,用使用者的語言 |
| 變數 | Vodafone UK 的 Variables Taxonomy Map,四層串起品牌、原始值、語意與頁面 |
| Token 命名工具 | Romina Kavcic 的命名指南與產生器,以及 token 名稱盤點試算表 |
| 產品 | Onym,開源的命名工具與方法集合 |
四、元件命名:先看別人怎麼叫
摘要明確說,文章在 UI 元件這段沒有給出詳細的命名規範,只建議先比對其他設計系統對相似元件的叫法,再用 Component Gallery 這類詞彙對照表確認別名。實務上這能解決一個常見狀況:團隊內部把同一個東西叫 popover、tooltip、flyout 各有各的說法,導致程式碼、設計稿與文件對不上。對照外部命名,至少能找到一個大家比較熟悉的共同詞。
五、限制
這篇是資源導覽,各工具的品質與是否仍在維護,我沒有親自檢查;摘要裡的數字(約 30,000 個顏色名稱、超過 50 種元件)是文章或摘要的說法,我沒有核對。文章結尾還有 Smashing 工作坊的宣傳內容,與命名主題無關。命名準則也受語言影響,例如中文團隊在設計稿用中文、程式碼用英文,兩套名稱之間的對照又是另一層問題,文章摘要沒有談到。
🧠 記
- 來源: Smashing Magazine,Vitaly Friedman,2026-10-06;讀到的是工具摘要,非逐字原文,外部資源未逐一驗證。
- 兩種失敗: 太籠統不清楚,太具體不能重用。
- 標準: 團隊與使用者都懂;功能名用使用者的語言並指向成果。
- 做法: 把命名衝突當成 backlog 項目追蹤;元件名先對照其他設計系統。
✍️ 實踐
花十五分鐘盤點自己設計系統的命名。第一步,列出五個最近讓人爭論過的名稱,標出爭論來自太籠統還是太具體。第二步,挑三個 token,檢查名稱是否綁了外觀值,若綁了,試著改成語意名稱,看換主題時是否仍成立。第三步,把設計稿、程式碼與文件中同一元件的叫法並排,若不一致,到 Component Gallery 之類的對照表找一個共同詞,寫進團隊詞彙表。第四步,挑一個採用率偏低的功能,問三位使用者「你會怎麼稱呼這個東西」,把答案與現在的功能名稱比較。
🔗 延伸學習
- A Practical Guide To Naming Things(Smashing Magazine)
- Accordion Icons: Which Work Best?(Smashing Magazine)
- Smashing Magazine 文章列表
💬 問 AI
我們的設計系統命名很亂:同一個元件在設計稿、程式碼與文件裡有不同叫法,部分 design token 名稱還綁了顏色值。請幫我:1) 設計一份團隊詞彙表的欄位(設計稿名稱、程式碼名稱、使用者用語、別名);2) 說明 token 名稱「太籠統」與「太具體」各會造成什麼問題,並給三組改名範例;3) 設計一個三到五人的簡易測試,確認使用者怎麼稱呼某個功能;4) 說明如何把命名衝突排進 backlog。請標明哪些是通用慣例、哪些需要用我們自己的資料驗證。