存在於 UI 設計與開發之間的大問題
前言
介面設計是軟體設計抉擇的一部分而不是規格，並且它遠遠不止於一張圖片，如果把設計稿視作規格往往不足以反映真實需求
Continuous Delivery 在 The Biggest Problem With UI 影片中點出了我多年來對於產品 UI 開發流程最大的疑惑：為什麼 UI 設計與開發的流程總是如此不順暢不協調？
UI 作為產品規格的一部分總是由設計團隊精心設計後交付給開發團隊實作，但過程有太多不協調因素，舉我自己親身經歷：
- 不理解 UI 的人很容易將介面設計視為一張張靜態圖片而不是動態的體驗，並且再怎麼高還原度的設計稿也無法完全反映真實的使用者體驗（還很燒時間製作）。
- 如果開發端對於設計抉擇有異議，來回溝通意味彼此的進度相互阻擋，除了效率低下之外也傷及工作體驗。
- 讓任一職位獨攬所有介面設計決策是不可能且危險的事，滿足使用者需求背後需要更多領域的協作，如產品團隊、開發團隊、使用者研究……等，要如何協調不同領域又保持效率？
「有沒有辦法讓團隊穩定高效的產出真實滿足用戶需求的產品？」是本篇文章探討的核心問題。
開發者眼中的 UI 問題
我是一名前端工程師，工作中會將工作職責分得非常清楚，產品根據需求撰寫規格書，UI 再根據規格書設計，開發再根據設計稿實作，看似明確清晰的分工，但卻沒有想像中協調。
這樣的流程讓我不被鼓勵允許在規格上提出任何意見，當我對於設計抉擇有歧異時只能選擇默默接受（甚至不知道為什麼採取這項決定），或是找時間一層一層向上溝通，但這樣的溝通往往會耗費大量時間，只為了回過頭修改已經被訂下的設計抉擇，如果每當任何一個疑惑冒出來還要開一個請求給 UI 團隊或是啟動會議……大多數人都會放棄！
當被迫把實踐問題的方法侷限在上級提供的設計抉擇時，總是會忽略掉用戶真正的需求與開發上的困難，就像是我很難短時間內轉達我的考量給設計師，並且大多時候上層也不會有足夠的時間去了解這些技術細節。
在職責清晰的工作模式當中，每個人只會關心自己職責內的事情，並沒有什麼真正的協作發生。
所以 UI 該怎麼做？
在 The Biggest Problem With UI 影片的觀點中提到，工程師雖然強項不在於 UI，但或多或少都是某種程度的深度使用者，對於 UI 都相較於他人有某種程度的認知。
根據 Team Topologies 觀念，UI 團隊可以作為 Enabling Team 來彌補 Stream-aligned team 的不足，這使得開發團隊有時間獲取和發展能力，而不會佔用他們的主要目標的時間。
Enabling Team 主要致力於透過專注於問題而不是解決方案來增強團隊的能力，從而提高 Stream-aligned team 的自主權。Stream-aligned team 應該可以自行解決 80% 常見問題，可以透過努力來降低跨團隊的需求，藉由：
- 經驗分享與訓練
- 定義良好的 UI 文件與慣例
- 定義可重複使用的素材與元件
總結
我們會認為工程端將每個需求與外觀一比一的實踐出來就是優秀的，但這只是基礎，真正的優秀是能夠洞察真實需求並提高整個團隊的運作效率，站在大局思考促進團隊的成功我認為才算是真正解決問題。