收到一封 Mail，其中提到幾個關于設計流程和 Prototype 的問題。UI設計流程：Wireframe->低保真Prototyple->Mockup->高保真Prototyple，這樣的流程是對的嗎？今天來聊聊一個完整的 UI 設計流程應該是怎樣的，收干貨！ 根據上過課的學員響應、以及自身經驗，目前業界的情況大多是 UI 設計師收到「開工啦」的通知，然后就從 Wireframe 開始下手。用戶怎么操作、有哪些功能、用戶和客戶的需求是什么往往靠 PM 簡單口述。 Wireframe 為什么會長這樣？在 Wireframe 之前還有哪些事要做？ 全部都靠通靈。 所以執行項目期間都在改來改去，撐到最后一天總是可以結案就解脫了嘛，再開始下個改來改去的輪回。 開發流程 基本上我自己在開發產品的流程大致上不會脫離這張圖太遠。

1. User Story
2. Functional Map
3. Flow Chart
4. UI Flow
5. Wireframe
6. Mockup
7. Prototype

使用者要什么？ > 從需求中整理出功能 > 用戶怎么操作這些功能？ > 操作的過程需要哪些頁面？ > 頁面要放什么內容/組件？怎么被操作？ > 使用者看到的頁面長什么樣子？ 各家有各家的作法，沒有標準或正確一定要這樣做的流程，但我在做自己的玩具時都會這樣干。 有 UX 團隊的大公司會把上述流程拆的更細，還會做使用者研究之類；一人 UI/UX 通包的小型團隊…這 7 項是最低一定要產出的文件，依個人想偷懶的慘痛經驗，再刪除精簡化就會在執行項目的過程中漏東漏西，之后補洞反而花更多時間和心力。
1. User Story 功能怎么來的？從「使用者要什么」或「客戶預期使用者想要什么」開始。
依用戶的身份不同，想要的功能也會不同，完成的任務不一樣嘛。 比如「Blog」： 我是讀者，我要看到這位作者寫的所有文章。
我是作者，我要撰寫并發布文章。
我是平臺提供商，我要看到所有會員身份和繳費狀態。 這三種身份對「Blog」這項產品的需求和預期完全不同。
2. Functional Map 寫了 User Story，才會知道有哪些大小功能要做。針對不同使用者的需求，從故事中挑出功能。使用者的身份不同往往影響他們能使用的功能，整理歸納出共通和差異處。
3. Flow Chart 當開發者知道使用者想要什么、也有了功能，才有辦法思考「用戶怎么操作功能完成他的任務或達到目的」。 UI 設計師常說：「配合用戶的習慣與行為來設計操作流程」。就是在這一階段規劃。如果跳過 Flow Chart，只要產品功能復雜起來，你家的 RD 就會抱著頭哀嚎了。
4. UI Flow 知道用戶會怎么操作一項功能時，才有辦法規劃操作動線。UI Flow 指的是頁面與頁面之間的操作流程，用戶想完成任務會經過多少頁面之類。 有另一位讀者傳訊問道，為什么我之前的文章說不要用圖片版的 UI Flow、要用文字版的呢？ 首先，這是雞生蛋蛋生雞的問題。如果這個項目從零開始，把 Flow Chart 規劃完后接著做 UI Flow，這時候哪來的圖片版可以串 Flow？連 Wireframe 都還沒開始畫哩！ 第二，當你的產品頁面一多的時候…也不用太多，20頁，用圖片串出一個 UI Flow ，這個 Flow 圖表尺寸有多大張？誰有那個心力在一張大圖上用手掌工具來回移動看頁面走向？ 第三，很多人做圖片版的 UI Flow 時，線條連接的是「頁面」和「頁面」，這時候你也只知道「喔～這一頁的下一頁會到這里」，但你完全不會知道為什么會到這一頁。要點哪里、或是發生什么事所以跑到這里來？猜猜看啊～ 要靠猜猜看才會看懂的文件看它（寫它）干嘛？不要浪費時間啊。 文字版的 UI Flow 我拿來當「目錄」用，對照 Wireframe 的編號，找圖看細節的時候快。
圖片版的 UI Flow 我會用在「優化」舊產品的操作時使用，連接線會從「組件到頁面」，而不是「頁面到頁面」，并在圖片和線條旁邊寫上文字說明，才會知道哪個步驟可以省略或修改得更易于使用。
5. Wireframe 有畫 Wireframe 不代表工程師就看得懂這要干嘛，光看臉皺成一團的表情你也不知道他是踢到腳指還是吃到酸梅。文字說明才是 Wireframe 的重點，包含觸發、回饋、狀態變化等等。 一開網頁就自動出現廣告、還是開啟網頁后等個3秒才出現廣告？
廣告出現10秒自動消失，還是要按(X)按鈕？
網頁停止30秒沒有操作要不要出現廣告？ 工程師只會照你寫的去做、不會照你想的去做。工程師不是神也不是蛔蟲，他們是一般人，沒有他心通這種神力，溝通上肯定會有認知落差，所以話要講清楚，設計師的常識不等于工程師的知識。 Flow Chart、UI Flow、Wireframe 這三份文件寫到一半發現什么東西漏掉回頭補上是正常現象，不可能一次到位。
6. Mockup 視覺稿…照 Grid 和 Guideline 做吧，之后還有切圖和標示文件要弄。 好處是切圖和標示文件都有外掛工具可以代勞，甚至設計師只要顧好原始檔、切圖和標示文件都用 Avocode 或 Zeplin 解決。 壞處是，如果不太知道技術限制，做出來的東西工程師不能用就算了，他們還白挨設計師的罵。 「為什么你做出來的東西和我畫的差了幾px？」
「拜托！RWD 不可能完全和你畫的一模一樣好不好？」
「是你能力不夠還是偷懶？我的圖畫得出來為什么你做不出來？」
「干…」
7. Prototype 那位讀者問另外問了關于 Prototype 的問題：

高保真Prototyple是在切圖給RD之后制作，那做出來的用意是在RD程序還沒完成前再次確定操作上有無任何問題嗎?
那高保真Prototyple就是跟成品長的一樣還可以操作啰??

做 Prototype 的目的通常是測試和驗證，不管是給使用者操作看看、觀察使用者操作狀況做使用者測試；還是工程師套完程序上線前先測看看有沒有蟲或哪邊爆炸了。所以它一定要可以被操作，不能被實際操作是要怎么測試？腦內補完？ Prototype 要可以被操作！
Prototype 要可以被操作！
Prototype 要可以被操作！ 不能被操作的都不是 Prototype。 Wireframe 可以做 Prototype，低保真原型。
Mockup 可以做 Prototype，高保真原型。
切圖叫工程師寫程序套版做一個，高保真原型。 我自己大多做完 Mockup 后才會出 Prototype 測試。
因為，Wireframe 做的低保真原型一般使用者看不懂也沒感覺，沒辦法做使用者測試 =_= Wireframe 做的 Prototype 頂多內部測試吧，但內部測試常常不太準，工程師和設計師的思維和一般人不一樣，測一測重點常常歪掉… 補充說明 另一位讀者看了本文后若有所感，傳訊跟我討論了下。

今天也和老板談了是否要有 Functional Map 和 UI Flow 等等這些流程，讓我們在前面討論的時候就可以厘清，而不是在視覺稿才修改增減，他也直言我們沒有那么多時間無法照這樣流程，真的很無力…

沒有那么多時間無法照這樣流程？當然啊，因為要把時間留在后面改來改去嘛～～～～～ 時間總是要花的，看是花在前期規劃還是后期補洞而已。說沒時間無法照流程的是根本沒流程可以照吧。 想逼走員工、降低團隊士氣，盡量亂改沒關系，反正大家都知道亂改的那個人連自己要什么都不知道只好胡亂張嘴下指令。