UI/UX 設計流程怎麼走？六階段產出物與驗收重點完整拆解

第一次發包介面設計的企業，收到的第一份東西常常是一疊灰白色的方框圖：沒有顏色、沒有照片、連字都是灰的。這時心裡冒出的疑問通常是——這樣就算一個階段的交付嗎？

這個疑問問對了地方，只是問錯了方向。UI/UX 設計流程的每個階段都在解決一個特定的問題，也各自有一份可以被檢查的產出物。看不懂產出物，就會在錯的階段給錯的意見：在只該討論結構的時候爭論按鈕顏色，在只剩上線倒數的時候才發現少了一整條使用者流程。

以下把 UI/UX 設計流程拆成六個階段，逐一說明這個階段會產出什麼、需求方要提供什麼、驗收該檢查哪幾件事，以及跳過它通常要付出的代價。

UI 與 UX 不是同一件事，分工搞錯就會驗收錯東西

先把最容易混淆的兩個字釐清。

根據 Nielsen Norman Group 對使用者經驗的定義，使用者經驗（UX）涵蓋終端使用者與一家公司、它的服務、它的產品互動的所有面向，並不只是某個畫面看起來如何、行為如何。UI 則是指產品的外觀與可操作的介面本身。

Nielsen Norman Group 舉過一個好懂的例子：一個電影評論網站，即使找電影的介面做得完美無瑕，只要底層資料庫只收錄大片廠作品，想查獨立製片資訊的使用者，體驗依然是糟的。介面沒有錯，體驗還是壞的，因為問題出在介面之外。

換成商業情境會更有感。一套報價查詢系統，畫面乾淨、按鈕漂亮，但使用者要查一筆報價得先登入、再選公司別、再選年度、再選專案——這是 UI 不錯、UX 做壞了。反過來，流程順暢但按鈕小到按不準、錯誤訊息只寫「操作失敗」，那是 UX 想對了、UI 沒做好。

驗收時要問的問題因此不同：

• 驗收 UX 要問的是——使用者要達成的事，最少幾步能完成？中途會不會卡住？卡住時他知道怎麼辦嗎？
• 驗收 UI 要問的是——這個元件的狀態齊全嗎？資訊層級清楚嗎？在手機上還讀得到嗎？

這兩種問題會出現在流程的不同階段。分清楚之後，接下來的六個階段才看得懂。

設計流程是迭代的，不是一條直線

拆階段之前，要先破除一個更根本的誤解：設計流程不是「做完一關再進下一關」的闖關遊戲。

國際標準 ISO 9241-210 以人為本的互動系統設計把以人為本的設計歸納成四項活動：理解並界定使用脈絡、界定使用者需求、產出設計解決方案、對照需求評估設計。標準特別強調的是——這四項活動是迭代進行的，評估結果會回頭修正前面的產出，直到達成可接受的結果。

另一個業界廣泛使用的框架，是英國 Design Council 提出的雙鑽石模型（Double Diamond）。這個框架 2003 年開始發展、2005 年公開發布，2019 年更新為更完整的創新框架，但保留了原本的 Discover（探索）、Define（定義）、Develop（發展）、Deliver（交付）四階段。

重點在那兩顆鑽石的形狀。每顆都是先發散再收斂：第一顆處理「問題到底是什麼」，把使用者的實際狀況攤開，再收斂成一個明確定義的問題；第二顆處理「解法是什麼」，先發想多種可能，再收斂成要做的那一個。

發包時最常見的狀況，是直接從第二顆鑽石的後半段開始——「我要做一個像某某網站那樣的頁面」。第一顆鑽石整個被跳過，於是走到一半才發現，真正該解決的問題不是官網不好看，而是詢價表單問了太多題目導致沒人填完。

所以下面的六個階段不該被讀成六道關卡，而是六種產出物，中間會來回。

UI/UX 設計流程六階段完整拆解

以下把設計實務常見的流程整理成六個階段。不同團隊的名稱與切法會有出入，產出物則大致相同。先看整體對照，再逐段展開。

階段	主要產出物	需求方要提供	驗收檢查點	跳過的代價
1 使用者研究與需求釐清	使用者輪廓、情境描述、排序後的需求清單	目標客群輪廓、既有數據、客服常被問的問題	需求有沒有排優先序？敘述能不能被驗證？	做出「內部喜歡但沒人用」的功能
2 資訊架構與使用者流程	網站地圖／功能架構圖、使用者流程圖	現有內容清單、既有系統限制	主要任務能不能在圖上走完？有沒有死路？	上線後才發現分類不合理，全站重整
3 線框圖 Wireframe	灰階頁面結構圖、區塊配置與元件位置	各區塊的實際文案量級	每個畫面的主要行動是什麼？資訊優先序對嗎？	帶著錯誤結構直接上色，改版等於重做
4 視覺稿 Mockup	上了品牌色、字體、圖片的完稿畫面	品牌識別規範、圖片素材	各斷點都出稿了嗎？狀態齊全嗎？	工程端自行猜測樣式，做出來不一致
5 可互動原型 Prototype	可點擊操作的模擬介面	願意受測的真實使用者名單	不看說明能不能走完主要任務？	把可用性問題留到寫完程式才發現
6 可用性測試與修正	測試發現清單、修正後的設計稿	測試時間、內部決策者出席	問題有沒有分級？修正有沒有回測？	讓真實客戶當第一批受測者

階段一：使用者研究與需求釐清

這一段對應雙鑽石的第一顆鑽石，也對應 ISO 9241-210 的前兩項活動。

實務上不需要學術等級的研究。中小企業值得做的，通常是幾件成本很低的事：把客服或業務最常被問到的問題列出來、翻一下既有網站的行為數據看使用者卡在哪一頁、找三到五位真實客戶聊二十分鐘。

驗收要看的是需求有沒有被排序。 好的需求清單不會是平鋪直敘的功能表，而會標明哪些是核心任務、哪些次要、哪些這一期先不做。如果每一項都很重要，等於沒有排序，取捨會被推遲到時程壓縮時才發生——那是最糟的決策時機。

階段二：資訊架構與使用者流程

需求確定之後，要決定的是東西放在哪裡、使用者怎麼走。

資訊架構回答靜態問題：有哪些頁面、如何分類、選單怎麼長。使用者流程回答動態問題：訪客從進站到完成詢價，會經過哪幾個畫面、每個決策點有哪些分支、失敗了被帶到哪裡。

這個階段的產出物看起來最不像設計，卻是整個專案最便宜的修改時機。在流程圖上搬動一個步驟只要幾分鐘，等程式寫完再搬，代價是好幾天。

驗收要看的是主要任務能不能在圖上走完，而且沒有死路。 挑三個最重要的任務——例如找到某項服務的說明、送出詢價、查詢訂單狀態——在圖上實際走一遍，每一個失敗分支都要有明確的去處。

階段三：線框圖（Wireframe）

線框圖是低擬真的結構工具，用來界定頁面結構、資訊分佈與互動路徑。它通常只用方框、線條與灰階，刻意不上色、不放照片——因為這個階段要討論的是什麼資訊放在哪裡、誰比較重要，顏色和照片會嚴重干擾判斷。

這也是誤解最集中的階段。繁體中文設計社群早就指出過這個現象：團隊常把線框稿視為一次性、非必要的流程，不願花時間討論，結果產品建構在草率的藍圖上，造成日後維護與修改的資源浪費（參考寫點科普對 Wireframe、Mockup 與 Prototype 的整理）。

另一個常見摩擦是：非設計背景的關係人看到線框稿會困惑「這就是最終設計嗎？」——所以交付線框稿時說明它的角色與目的，本身就是流程的一部分。

驗收要看的是每個畫面的主要行動是什麼。 一個畫面如果說不出使用者被期待做的那一件事，通常代表結構還沒收斂。另外要檢查文案量級是否貼近真實：用假文填出來的漂亮版面，換成實際三百字的服務說明常常就崩了。

階段四：視覺稿（Mockup）

視覺稿是在線框圖之上加入品牌色調、字型與視覺美學的那一層「外皮」，讓人預覽最終成品的樣貌。

這是需求方最有感的階段，也最容易只憑喜好決策。要讓討論不變成品味之爭，有兩個做法：先確立品牌識別的基本規範（主色、輔色、字體階層），把可討論的範圍收窄；再把「狀態」納入驗收，而不是只看漂亮的那一版畫面。

所謂狀態，指的是同一個畫面在不同情況下的樣子：資料還在載入、一筆資料都沒有、輸入錯誤、權限不足、內容超長被截斷。這些狀態在真實使用中出現的頻率遠比想像高，而它們如果沒有出稿，工程端只能自行發揮。

驗收要看的是斷點與狀態的完整度。 桌機、平板、手機是否各自出稿或至少說明縮放規則；每個表單是否有錯誤狀態；每個列表是否有空狀態。

階段五：可互動原型（Prototype）

原型是中到高擬真、可以實際點擊操作的版本，目的是模擬使用者與介面之間的互動。它不是程式，卻能在寫程式之前先驗證流程對不對。

原型的擬真度可以選擇，也直接影響工作量。只需要驗證流程的話，把主要畫面串起來、能點能跳就夠；如果要驗證動效與轉場感受，成本會明顯上升。這是需求方可以主動控制預算的一個槓桿。

驗收要看的是不看說明能不能走完主要任務。 如果原型必須靠人在旁邊講解才能操作，那要修的不是原型，是流程本身。

階段六：可用性測試與修正

原型做出來的最大價值，是可以拿去測。這一段對應 ISO 9241-210 的第四項活動：對照需求評估設計。測試怎麼做才不會流於形式，後面單獨談。

線框圖、視覺稿、原型：三份文件的分工

這三個詞在報價單與會議中經常被混用，是驗收認知落差的主要來源。整理如下：

比較項目	線框圖 Wireframe	視覺稿 Mockup	可互動原型 Prototype
擬真度	低	高（靜態）	中到高（可操作）
回答的問題	資訊放哪裡、誰重要	看起來是什麼樣子	操作起來順不順
有沒有顏色	通常沒有，灰階為主	有，含品牌色與圖片	有，通常沿用視覺稿
能不能點擊	不能	不能	能
適合用來做什麼	內部確認結構	確認視覺方向、給工程對樣式	給真實使用者測試
這階段該討論	版面、層級、流程	色彩、字級、間距、狀態	卡點、誤解、走不完的地方
這階段不該討論	顏色好不好看	少了一個功能	換一個主色

最後兩列是實務上最有用的部分。把「這階段不該討論什麼」講清楚，可以省掉大量來回。

設計交付給工程之前，該準備哪些規格

設計稿定案不等於可以開工。設計與工程之間的斷層，是專案後期最常見的返工來源——工程師照著看起來的樣子做，做出來卻和設計師想的不一樣。

目前多數團隊以 Figma 作為介面設計與交付工具。Figma 的 Dev Mode 開發者模式就是為了處理這個交接環節，其中幾個功能直接對應到常見的斷層：

• 標註（Annotations）：設計師可以在設計檔上加註額外說明、規格與尺寸，讓工程端不會漏掉關鍵指示。
• 狀態標記（Status）：可對區段、畫面或元件標記「Ready for dev」，明確區分哪些已定稿可開工、哪些還在改。對分批開發的專案特別有用。
• 變數與 Design Token：顏色、間距、字級應引用變數而不是寫死數值。工程師看到的若是語意化名稱而不是一組色碼，就能直接對應到程式碼裡的變數，不必反覆確認這個色碼是不是同一個。

除了工具本身，交付前值得逐項確認的還有：狀態是否齊全（載入中、空資料、錯誤、成功、權限不足、內容過長）；響應式規則是否明確（斷點在哪、哪些元素換位、哪些隱藏）；互動細節是否說明（hover 與點擊變化、動畫時間、捲動行為）；文字規則是否定義（超長標題怎麼處理、日期格式）。

還有一項最容易被忽略、代價卻最大：檔案權限與所有權。專案結束後拿不到可編輯的原始檔，下一次改版就得從頭畫起。若專案涉及 APP 端介面，工作量還會再乘上平台數，這一點在請人寫 App 多少錢這類討論開發成本的內容裡，也是反覆出現的變數。

UI/UX 設計的計價方式與工作量因子

在談具體金額之前，更值得先搞懂的是計價結構——因為多數報價落差不是來自單價，而是來自對範圍的認知不同。台灣市場常見三種方式：

計價方式	適合的專案	主要風險	事前要談定什麼
以頁（畫面）計價	頁數明確、互動單純	「一頁」的定義模糊	三個斷點算一頁還是三頁？狀態算不算獨立畫面？
專案總包計價	範圍已談清楚、時程固定	範圍蔓延無處計價	變更的認定標準與加價機制
時數／人月計價	需求會滾動、需研究與多輪測試	總額難以預估	時數上限、分階段結算與中止點

不論採哪一種，推高工作量的因子都是同一組：畫面數量與狀態數量（同一畫面的載入、空、錯誤、權限不足各是獨立的設計工作）、響應式斷點數、是否包含研究與可用性測試、是否從零建立設計系統、原型擬真度、交付規格深度、改版輪次上限。

看報價單時，把注意力從總價移到這幾項的定義上，通常比比價更能避免後續爭議。

可用性測試該怎麼做才有用

可用性測試是最容易在時程壓力下被砍掉的一段，也是最被誤解的一段。

最常被引用的一條經驗法則來自 Nielsen Norman Group：測試 5 個人，可以找出大部分的可用性問題。但這句話有個關鍵前提經常被漏掉——NN/g 關於測試人數的說明指出，5 人法則適用的是質性測試，也就是實際觀察受測者操作產品的那一種。他們的主張是與其一次找很多人，不如 5 人一輪、修完再測 5 人，反覆迭代。

如果要做的是量化研究，例如想知道有多少比例的使用者能完成結帳，5 人遠遠不夠，需要依統計顯著性推算樣本數，量級會大得多。把兩者混為一談，是誤讀這條法則最常見的方式。

務實的做法是：

• 找 5 位條件接近真實客戶的人，不要找同事，更不要找設計師。
• 給任務，不要給步驟。說「請找出這項服務的收費方式」，不要說「請點右上角的選單」。
• 讓他們邊做邊說出在想什麼，觀察者不要提示。
• 記下卡住的位置與原因，而不是他們的建議。使用者擅長指出哪裡不對，不擅長設計解法。

沒有預算做完整測試時，還有一個成本更低的替代方案：用 Nielsen 十大可用性原則自行檢查。這十條原則由 Jakob Nielsen 與 Rolf Molich 於 1990 年提出，1994 年根據 249 個可用性問題的分析加以精煉，之後原則本身維持不變。其中幾條特別適合非設計背景的人當成檢查表：

• 系統狀態要可見：使用者按下按鈕之後，有沒有東西告訴他發生了什麼事？
• 用使用者的語言：介面上有沒有出現只有內部才懂的術語或代碼？
• 辨識優於回憶：使用者需不需要記住上一頁的資訊才能填完這一頁？
• 協助使用者從錯誤中復原：錯誤訊息有沒有用白話說明問題出在哪、下一步該怎麼做？

自我檢查不能取代真實使用者測試，但可以先掃掉一批明顯的問題，讓寶貴的測試場次用在更難發現的地方。

設計系統：什麼時候該建，什麼時候不必

設計系統這個詞近年出現頻率很高，也很容易被過度推銷。

設計系統指的是一整套標準、準則與元件的集合，包含可重複使用的 UI 元件——按鈕、字級、色彩、間距——以及使用原則、樣式規範、文件與維護方式。它比「元件庫」的範圍更廣，元件庫只是其中一部分。

支撐它的技術基礎之一是 design token。Token 是跨平台的鍵值對，把視覺決策存起來，讓設計工具與程式碼共用同一組定義。好處很直接：改一次主色，所有引用它的地方一起更新，不必在幾百個元件裡手動找替換；深色模式切換也變成抽換一組 token。

但這些好處要成立，前提是產品夠大、改版夠頻繁、使用它的人夠多。判斷方式可以很簡單：

• 十幾頁、一年改一次的形象官網——完整設計系統通常不划算，一份基本樣式規範（色彩、字級、按鈕與表單元件）就足夠。
• 會持續迭代的系統或 APP，且有多位設計師或工程師同時修改——從一開始把 token 與元件規則定義好，長期省下的時間會遠超過前期投入。
• 同時有網站、後台、APP 三個介面，且希望它們看起來像同一家公司——這是設計系統價值最明顯的場景。

換句話說，設計系統是為「重複」而存在的。沒有重複，就沒有攤提的對象。這個邏輯和客製化網頁設計的取捨很接近：值不值得投入前期規劃，取決於這套東西未來要活多久、要被改多少次。

流程裡最常被砍掉的環節，以及它的代價

時程一壓縮，被刪掉的順序幾乎是固定的：先砍可用性測試，再砍使用者研究，接著把線框圖併進視覺稿，最後連狀態設計都省了，交付時只給一份「正常情況」的漂亮畫面。

這四刀砍下去，專案確實會提早進入開發，代價則遞延到後面才出現：

• 砍掉研究，會做出使用率偏低的功能，維護成本照付。
• 併掉線框圖，結構問題會被顏色掩蓋，等到上線才被使用者發現。
• 省掉狀態設計，工程端自行補位，錯誤處理不一致，日後每次調整都要重談。
• 砍掉測試，等於讓真實客戶當第一批受測者，而流失的客戶不會回頭告訴你原因。

真正該做的取捨，不是「做或不做」，而是「做到什麼深度」。研究可以從三場二十分鐘的客戶訪談開始；測試可以從 5 個人的質性觀察開始；設計系統可以從一份兩頁的樣式規範開始。這些輕量版本的共同點是：它們保留了流程要解決的問題，只是縮小了規模。

UI/UX 設計流程常見問題

把流程當成共同語言

UI/UX 設計流程的價值，不在於它有幾個階段、用了哪個框架，而在於它讓需求方、設計端與工程端在同一個時間點討論同一件事。

線框階段就討論結構、視覺階段就討論樣式、原型階段就討論操作、測試階段就討論真實反應。當每個階段的產出物和驗收標準都事先講清楚，專案裡那些「我以為是這樣」的爭執，多半在發生之前就被擋掉了。

先想清楚要解決什麼問題，再決定畫面長什麼樣子——順序對了，後面每一步的成本都會低一些。若手上正有一個網站、系統或 APP 專案，想在動工前把介面流程、需求範圍與交付規格一次談清楚，瞻新資訊可以協助評估適合的規劃深度。