先研究使用者，還是先畫介面
這是香港客戶最常問的問題之一。實務上兩者會交替進行：先做少量訪談或觀察，理解使用者現在怎麼完成這件事，再畫出第一版流程；畫完之後回頭驗證，通常會發現原本的假設要調整。
完全不做研究直接畫畫面，風險在於把內部習慣當成使用者習慣。反過來說，研究做到無限期也不實際。我們的做法是設定一個明確的問題範圍，例如「新用戶能否在三步內完成申請」，把研究收斂在會影響設計決策的題目上。
研究太少
把內部作業習慣當成使用者習慣，畫面畫得很順，實際使用卻卡在第二步。
研究太多
題目沒有收斂，訪談一直加，決策卻遲遲沒有往前，時程被吃掉在前期。
需求訪談與現況盤點
專案開始時，我們會跟實際操作的人談，而不是只看管理層的描述。因為流程的困難往往藏在細節裡：某個欄位為什麼要重複填、某個審批為什麼一定要紙本、出錯時誰要負責補救。
- 訪談誰 第一線操作的人、審批的人、以及出錯時要收拾的人，三種角色問法不同。
- 盤點什麼 現有系統、Excel 表單與舊資料庫的欄位定義，還有目前用通訊軟體補位的手動流程。
- 產出什麼 一份欄位與流程的對照清單，標出重複、缺漏與定義不一致的地方。
- 先講清楚，後面才不會蓋在錯的基礎上
資訊架構與使用者流程
資訊架構決定內容與功能怎麼分類、放在哪裡。使用者流程則描述完成一件事要經過哪些步驟。這兩件事做完，畫面的數量與順序才有依據。
對雙語產品來說，這一步特別重要。繁中與英文的字串長度不同，導覽名稱若在中文只有四個字、英文卻要一整句，選單結構就得重新考慮。我們會在架構階段就把語言切換當成正式功能規劃，而不是最後補上。
架構階段的檢查題
- 同一個功能在手機與桌面是否都找得到？
- 切換語言後，選單層級會不會整個變形？
- 一項任務最多幾個步驟，中途能不能存檔？
卡片分類法（card sorting）：請幾位真實使用者把功能卡片自行分堆，看他們的分類和你的選單差多少。
線框圖：先確認結構，再談美感
線框圖只處理版面結構與元素優先順序，不談配色與細節。這個階段最適合快速試錯，改動成本低，也容易讓不同角色聚焦在「這樣安排對不對」而不是「這個顏色好不好看」。
我們通常會針對主要流程各出一版線框圖，涵蓋正常路徑與常見的錯誤情況，例如欄位沒填、資料重複、連線中斷。這些情況不常出現在示範裡，但實際運作時決定了使用者會不會卡住。
版面結構
區塊先後與視覺重量，不談顏色。
元素優先序
哪一顆按鈕該被先看到、哪個欄位可以收起。
錯誤路徑
沒填、重複、斷線三種情況各畫一版。
快速修改
此時改動的成本最低，討論也最具體。
原型與互動驗證
原型把線框圖串成可以點擊的流程，讓人在還沒有程式碼的時候先走一遍。這對於需要跨部門確認的專案特別有用，因為抽象的流程圖很難討論，能點的原型則容易指出問題。
Figma 是我們在這個階段的主要工具，設計稿、元件與註解放在同一個檔案裡，開發端可以直接對照規格。如果專案需要更強烈的互動敘事，例如產品頁或概念展示，Framer 的動畫與發布能力會更接近成品網站。
Figma · 主要工具
設計稿、元件與註解放在同一個檔案裡，開發端可以直接對照規格與狀態。
Framer · 互動敘事
產品頁或概念展示需要更強的動態時，發布後的成品更接近正式網站。
想比較不同工具在實際專案裡的分工，可以接著看 技術與工具。
可用性測試怎麼做
重點是觀察行為，而不是問他們喜不喜歡。
找五到八位接近目標使用者的人，給他們幾個實際任務，觀察他們在哪裡停頓、哪裡按錯、哪裡需要回頭。測試後我們會把問題依嚴重程度排序，先處理會讓任務失敗的項目，再處理造成困惑但可繞過的項目。這些結果會直接回饋到線框圖或原型，形成下一輪修改的依據。
先處理
會讓任務失敗的問題
按了沒反應、找不到下一步、送出後不知道成功沒有。
再處理
造成困惑但可繞過的問題
用詞不一致、選項名稱相近、提示出現的位置太遠。
下一輪
回饋到線框圖或原型
修改後再用同一組任務重測，確認問題真的消失了。
介面設計與設計系統
進入介面設計後，我們會在 Figma 建立可重用的元件，包含按鈕、表單、狀態提示與版面對齊規則。這樣做不只是為了整齊，而是讓後續新增頁面時有一致的基準。
設計系統同時處理狀態，例如載入中、無資料、權限不足、錯誤。這些畫面在設計稿裡常常被省略，但使用者實際遇到的頻率不低。先定義好，開發端就不必臨時發明。
- 元件層 按鈕、欄位、標籤的尺寸與間距固定下來，新頁面直接組裝。
- 狀態層 載入中、無資料、權限不足、錯誤，各有自己的文案與版面。
- 命名層 元件名稱盡量與程式端一致，交接或人員變動時少一層翻譯。
無障礙與響應式設計
無障礙設計涵蓋對比度、字級縮放、替代文字與鍵盤操作。對服務對象廣泛的機構網站來說，這不是加分項，而是基本要求。我們會在設計階段就納入檢查，而不是等上線後補。
響應式設計則處理同一套內容在手機、平板與桌面上的呈現。香港使用者的裝置組合很分散，手機為主但桌面仍佔一定比例，因此版面需要在窄螢幕上仍然成立，而不是把桌面版縮小。
每個階段結束都有一次對稿，確認產出符合預期再往下走。
設計交付與開發協作
交付不是把設計稿丟過去。我們會整理規格、標註間距與狀態、提供元件對應說明，並在開發過程中保持溝通管道暢通。問題越早提出，修改成本越低。
如果專案採用跨平台框架，設計端的元件命名會盡量與程式端一致，減少對照時的理解落差。這在專案交接或人員變動時尤其有幫助。
交付節奏與檢查點
每個階段結束時會有一個檢查點，確認產出符合預期再進到下一步。研究與架構通常佔前期較多時間，線框圖與原型可以快速迭代，介面設計則在結構穩定後展開。
- 研究與架構 前期時間佔比較多，重點是把不確定處收乾淨。
- 線框圖與原型 迭代最快的一段，改動成本低，適合密集討論。
- 介面設計與交付 結構穩定後展開，同步整理規格給開發端。
- 中途要調整範圍，也在檢查點上談
這樣的節奏讓你可以按階段驗收，也讓預算分配更清楚。如果中途需要調整範圍，我們可以在檢查點上討論，而不是等到開發完才發現方向不對。
設計流程一定要全部走完嗎？
不一定。如果需求範圍明確、風險集中在實作而非流程，我們會建議把研究縮短，直接進入架構與線框圖，把預算留給開發。反過來說，牽涉多個部門審批的專案，前面多花一兩週通常省下後面更多時間。
可用性測試需要多少人？
五到八位接近目標使用者的人就能找出大部分明顯的卡點。人數不是重點，任務設計才是：給受測者實際要完成的事，而不是請他們評價畫面。做完一輪修正後，再找同一類人重測一次，通常比一次找很多人有效。
交付包含什麼？開發端拿得到什麼？
交付包含設計稿、可重用元件、狀態畫面、間距與版面對齊規則，以及一份元件與程式端的對應說明。開發過程中的提問管道保持暢通，遇到規格沒寫到的細節會直接補在檔案裡，而不是口頭帶過。
雙語介面會不會拖長時程？
只要在資訊架構階段就把語言切換當成正式功能，後續並不會明顯拖慢。真正麻煩的是等到畫面定稿才補上英文，因為導覽、按鈕與表單欄位都得重排。繁中與英文的字串長度差異，越早看到越好處理。
想從哪一步開始
如果你已經有明確的功能清單，可以從線框圖開始；如果連問題範圍都還沒收斂，先做一輪研究會比較省事。把目前的做法、卡住的地方與時程寫給我們，我們會回覆建議的起點與階段安排。
- 工作室
- Equator 數碼產品工作室
- 時間與地點
- 週一至週五 09:00–18:00
Almatı şehri, Abay caddesi, 143, ofis 2
流程走到最後，驗收的是使用者的那一步，不是報告的厚度。