BELONGS
這個名字屬於這裡嗎？
它要符合功能所在的位置、使用者在此處的期待，以及產品既有的命名系統；孤立地「有創意」並不夠。
Apple Developer onepage / WWDC26
UX writing · Design功能命名不是修辭：它在設計使用者的預期與信任
Apple 的 UX Writer Heej 將命名變成可執行的設計流程：先定義什麼叫好名字，再從使用者出發產生候選，最後在真實介面與情境中淘汰。
Content map
影片拆的不是字詞，而是三個設計問題
EXPECTATIONS
它承諾的事，做得到嗎？
名稱會讓人預測點進去之後得到什麼。功能範圍、結果或心智模型不吻合時，介面會消耗信任。
WORKS EVERYWHERE
它離開原畫面還成立嗎？
名稱還要經得起翻譯、不同市場、設定、選單、通知與跨平台重用；不要只在 mockup 裡成立。
Naming flow
把命名納入產品決策，而非最後一輪文案潤飾
1
先描述使用者，而不是先堆詞庫
從目標使用者的「想什麼、感受什麼、要做什麼」開始。這個 think / feel / do 框架會把候選名稱拉回功能真正要完成的工作。
2
大量產生，再用情境縮小
先擴張選項，接著放回 feature、導覽層級、相鄰標籤與品牌語氣中比較；名稱是在系統內競爭，不是在白紙上競爭。
3
依功能權重評估三項準則
不必每個名稱三項都滿分。高風險設定項目可能優先追求清楚預期；品牌功能則可多保留辨識度，但要明知取捨。
4
把決定記成可延續的模式
一個命名會設定後續功能的語言規則。記錄採用理由與未採用詞，讓下一個 feature 不必重新猜一次。
實務啟發
命名 review 應該和 UI review 一樣具體
完整 session 的四段結構是 Introduction（0:00）、Criteria（1:18）、Process（5:25）與 Evaluation（10:34）。它的重點不是提供「完美名稱公式」，而是讓團隊能說清楚：這個詞為何適合這個功能、在哪些情境會誤導、要為哪個取捨負責。
短片與完整 session 的關係：本頁嵌入 Apple Developer 的 short；分析則以官方 WWDC26 完整 session、章節與逐字稿為主要依據，因此不把短片的宣傳長度誤當成全部內容。
導入 checklist
- 在資訊架構裡讀一次：和同層 tab、menu item、設定標籤並排，確認使用者能猜到位置與結果。
- 把名稱拿去做跨情境檢查：至少檢查 onboarding、空狀態、通知、設定與支援文章，不讓一詞多義失控。
- 及早找 localization：避免英文縮寫、文化隱喻或語法依賴；較長的譯名會不會破壞控制項與可讀性？
- 對齊功能承諾：若功能只是建議、預覽或部分覆蓋，不要用暗示完整控制或永久結果的名稱。
風險與遷移注意事項
改名稱可能影響既有使用者的尋找路徑、教學內容、客服關鍵字、分析事件與可及性文案。對已上線功能，先確認舊詞是否仍需要短期別名或搜尋 keyword；對跨平台產品，也要避免 iOS、macOS 與 web 各自長出不同概念名稱。
來源
Apple Developer：Craft clear names for features and labels in your app（官方章節、逐字稿與資源）；Human Interface Guidelines：Writing；Apple Developer YouTube short。