收到一封 Mail，其中提到幾個(gè)關(guān)于設(shè)計(jì)流程和 Prototype 的問(wèn)題。UI設(shè)計(jì)流程：Wireframe->低保真Prototyple->Mockup->高保真Prototyple，這樣的流程是對(duì)的嗎？今天來(lái)聊聊一個(gè)完整的 UI 設(shè)計(jì)流程應(yīng)該是怎樣的，收干貨！

根據(jù)上過(guò)課的學(xué)員響應(yīng)、以及自身經(jīng)驗(yàn)，目前業(yè)界的情況大多是 UI 設(shè)計(jì)師收到「開(kāi)工啦」的通知，然后就從 Wireframe 開(kāi)始下手。用戶怎么操作、有哪些功能、用戶和客戶的需求是什么往往靠 PM 簡(jiǎn)單口述。

Wireframe 為什么會(huì)長(zhǎng)這樣？在 Wireframe 之前還有哪些事要做？

全部都靠通靈。

所以執(zhí)行項(xiàng)目期間都在改來(lái)改去，撐到最后一天總是可以結(jié)案就解脫了嘛，再開(kāi)始下個(gè)改來(lái)改去的輪回。

開(kāi)發(fā)流程

基本上我自己在開(kāi)發(fā)產(chǎn)品的流程大致上不會(huì)脫離這張圖太遠(yuǎn)。

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

使用者要什么？ > 從需求中整理出功能 > 用戶怎么操作這些功能？ > 操作的過(guò)程需要哪些頁(yè)面？ > 頁(yè)面要放什么內(nèi)容/組件？怎么被操作？ > 使用者看到的頁(yè)面長(zhǎng)什么樣子？

各家有各家的作法，沒(méi)有標(biāo)準(zhǔn)或正確一定要這樣做的流程，但我在做自己的玩具時(shí)都會(huì)這樣干。

有 UX 團(tuán)隊(duì)的大公司會(huì)把上述流程拆的更細(xì)，還會(huì)做使用者研究之類；一人 UI/UX 通包的小型團(tuán)隊(duì)…這 7 項(xiàng)是最低一定要產(chǎn)出的文件，依個(gè)人想偷懶的慘痛經(jīng)驗(yàn)，再刪除精簡(jiǎn)化就會(huì)在執(zhí)行項(xiàng)目的過(guò)程中漏東漏西，之后補(bǔ)洞反而花更多時(shí)間和心力。

1. User Story

功能怎么來(lái)的？從「使用者要什么」或「客戶預(yù)期使用者想要什么」開(kāi)始。依用戶的身份不同，想要的功能也會(huì)不同，完成的任務(wù)不一樣嘛。

比如「Blog」：

• 我是讀者，我要看到這位作者寫(xiě)的所有文章。
• 我是作者，我要撰寫(xiě)并發(fā)布文章。
• 我是平臺(tái)提供商，我要看到所有會(huì)員身份和繳費(fèi)狀態(tài)。

這三種身份對(duì)「Blog」這項(xiàng)產(chǎn)品的需求和預(yù)期完全不同。

2. Functional Map

寫(xiě)了 User Story，才會(huì)知道有哪些大小功能要做。針對(duì)不同使用者的需求，從故事中挑出功能。使用者的身份不同往往影響他們能使用的功能，整理歸納出共通和差異處。

3. Flow Chart

當(dāng)開(kāi)發(fā)者知道使用者想要什么、也有了功能，才有辦法思考「用戶怎么操作功能完成他的任務(wù)或達(dá)到目的」。

UI 設(shè)計(jì)師常說(shuō)：「配合用戶的習(xí)慣與行為來(lái)設(shè)計(jì)操作流程」。就是在這一階段規(guī)劃。如果跳過(guò) Flow Chart，只要產(chǎn)品功能復(fù)雜起來(lái)，你家的 RD 就會(huì)抱著頭哀嚎了。

4. UI Flow

知道用戶會(huì)怎么操作一項(xiàng)功能時(shí)，才有辦法規(guī)劃操作動(dòng)線。UI Flow 指的是頁(yè)面與頁(yè)面之間的操作流程，用戶想完成任務(wù)會(huì)經(jīng)過(guò)多少頁(yè)面之類。

有另一位讀者傳訊問(wèn)道，為什么我之前的文章說(shuō)不要用圖片版的 UI Flow、要用文字版的呢？

首先，這是雞生蛋蛋生雞的問(wèn)題。如果這個(gè)項(xiàng)目從零開(kāi)始，把 Flow Chart 規(guī)劃完后接著做 UI Flow，這時(shí)候哪來(lái)的圖片版可以串 Flow？連 Wireframe 都還沒(méi)開(kāi)始畫(huà)哩！

第二，當(dāng)你的產(chǎn)品頁(yè)面一多的時(shí)候…也不用太多，20頁(yè)，用圖片串出一個(gè) UI Flow ，這個(gè) Flow 圖表尺寸有多大張？誰(shuí)有那個(gè)心力在一張大圖上用手掌工具來(lái)回移動(dòng)看頁(yè)面走向？

第三，很多人做圖片版的 UI Flow 時(shí)，線條連接的是「頁(yè)面」和「頁(yè)面」，這時(shí)候你也只知道「喔～這一頁(yè)的下一頁(yè)會(huì)到這里」，但你完全不會(huì)知道為什么會(huì)到這一頁(yè)。要點(diǎn)哪里、或是發(fā)生什么事所以跑到這里來(lái)？猜猜看啊～

要靠猜猜看才會(huì)看懂的文件看它（寫(xiě)它）干嘛？不要浪費(fèi)時(shí)間啊。

文字版的 UI Flow 我拿來(lái)當(dāng)「目錄」用，對(duì)照 Wireframe 的編號(hào)，找圖看細(xì)節(jié)的時(shí)候快。

圖片版的 UI Flow 我會(huì)用在「優(yōu)化」舊產(chǎn)品的操作時(shí)使用，連接線會(huì)從「組件到頁(yè)面」，而不是「頁(yè)面到頁(yè)面」，并在圖片和線條旁邊寫(xiě)上文字說(shuō)明，才會(huì)知道哪個(gè)步驟可以省略或修改得更易于使用。

5. Wireframe

有畫(huà) Wireframe 不代表工程師就看得懂這要干嘛，光看臉皺成一團(tuán)的表情你也不知道他是踢到腳指還是吃到酸梅。文字說(shuō)明才是 Wireframe 的重點(diǎn)，包含觸發(fā)、回饋、狀態(tài)變化等等。

一開(kāi)網(wǎng)頁(yè)就自動(dòng)出現(xiàn)廣告、還是開(kāi)啟網(wǎng)頁(yè)后等個(gè)3秒才出現(xiàn)廣告？廣告出現(xiàn)10秒自動(dòng)消失，還是要按(X)按鈕？網(wǎng)頁(yè)停止30秒沒(méi)有操作要不要出現(xiàn)廣告？

工程師只會(huì)照你寫(xiě)的去做、不會(huì)照你想的去做。工程師不是神也不是蛔蟲(chóng)，他們是一般人，沒(méi)有他心通這種神力，溝通上肯定會(huì)有認(rèn)知落差，所以話要講清楚，設(shè)計(jì)師的常識(shí)不等于工程師的知識(shí)。

Flow Chart、UI Flow、Wireframe 這三份文件寫(xiě)到一半發(fā)現(xiàn)什么東西漏掉回頭補(bǔ)上是正?，F(xiàn)象，不可能一次到位。

6. Mockup

視覺(jué)稿…照 Grid 和 Guideline 做吧，之后還有切圖和標(biāo)示文件要弄。

好處是切圖和標(biāo)示文件都有外掛工具可以代勞，甚至設(shè)計(jì)師只要顧好原始檔、切圖和標(biāo)示文件都用 Avocode 或 Zeplin 解決。

壞處是，如果不太知道技術(shù)限制，做出來(lái)的東西工程師不能用就算了，他們還白挨設(shè)計(jì)師的罵。

「為什么你做出來(lái)的東西和我畫(huà)的差了幾px？」

「拜托！RWD 不可能完全和你畫(huà)的一模一樣好不好？」

「是你能力不夠還是偷懶？我的圖畫(huà)得出來(lái)為什么你做不出來(lái)？」

「干…」

7. Prototype

那位讀者問(wèn)另外問(wèn)了關(guān)于 Prototype 的問(wèn)題：

高保真Prototyple是在切圖給RD之后制作，那做出來(lái)的用意是在RD程序還沒(méi)完成前再次確定操作上有無(wú)任何問(wèn)題嗎?
那高保真Prototyple就是跟成品長(zhǎng)的一樣還可以操作啰??

做 Prototype 的目的通常是測(cè)試和驗(yàn)證，不管是給使用者操作看看、觀察使用者操作狀況做使用者測(cè)試；還是工程師套完程序上線前先測(cè)看看有沒(méi)有蟲(chóng)或哪邊爆炸了。所以它一定要可以被操作，不能被實(shí)際操作是要怎么測(cè)試？腦內(nèi)補(bǔ)完？

Prototype 要可以被操作！Prototype 要可以被操作！Prototype 要可以被操作！

不能被操作的都不是 Prototype。

Wireframe 可以做 Prototype，低保真原型。Mockup 可以做 Prototype，高保真原型。切圖叫工程師寫(xiě)程序套版做一個(gè)，高保真原型。

我自己大多做完 Mockup 后才會(huì)出 Prototype 測(cè)試。因?yàn)?，Wireframe 做的低保真原型一般使用者看不懂也沒(méi)感覺(jué)，沒(méi)辦法做使用者測(cè)試 =_=

Wireframe 做的 Prototype 頂多內(nèi)部測(cè)試吧，但內(nèi)部測(cè)試常常不太準(zhǔn)，工程師和設(shè)計(jì)師的思維和一般人不一樣，測(cè)一測(cè)重點(diǎn)常常歪掉…

補(bǔ)充說(shuō)明

另一位讀者看了本文后若有所感，傳訊跟我討論了下。

今天也和老板談了是否要有 Functional Map 和 UI Flow 等等這些流程，讓我們?cè)谇懊嬗懻摰臅r(shí)候就可以厘清，而不是在視覺(jué)稿才修改增減，他也直言我們沒(méi)有那么多時(shí)間無(wú)法照這樣流程，真的很無(wú)力…

沒(méi)有那么多時(shí)間無(wú)法照這樣流程？當(dāng)然啊，因?yàn)橐褧r(shí)間留在后面改來(lái)改去嘛～～～～～

時(shí)間總是要花的，看是花在前期規(guī)劃還是后期補(bǔ)洞而已。說(shuō)沒(méi)時(shí)間無(wú)法照流程的是根本沒(méi)流程可以照吧。

想逼走員工、降低團(tuán)隊(duì)士氣，盡量亂改沒(méi)關(guān)系，反正大家都知道亂改的那個(gè)人連自己要什么都不知道只好胡亂張嘴下指令。

原文地址：blog.akanelee.me