[ 平面理論教程 ] UI設計如何了解用戶操作習慣和畫線框圖- 設計教程 - 骨子愛創意

教學主題: UI設計如何了解用戶操作習慣和畫線框圖

大家好!! 小編今天來和大家分享關於 設計教程中的平面理論教程教學

今天的這個教學主題是: UI設計如何了解用戶操作習慣和畫線框圖

這教學的重點為這幾點 [ 操作,習慣,用戶,了解,設計,如何,Flow,UI,怎麼,功 ]

希望你可以從這幾點中領悟到修圖的精華

本文重點

設計UI時的思考順序，各位覺得該是什麼樣子的呢？先出線框圖，再來想用戶會怎麼操作，還是先確認用戶會怎麼使用產品功能，再來思考 Wireframe 怎麼畫。今天Akane_Lee這篇好文分析，幫你想清楚這個抉擇。

設計UI時的思考順序，各位覺得該是什麼樣子的呢?先出線框圖，再來想用戶會怎麼操作，還是先確認用戶會怎麼使用產品功能，再來思考 Wireframe 怎麼畫。今天Akane_Lee這篇好文分析，幫你想清楚這個抉擇。

作者介紹：

Akane Lee，台灣UI/UX 設計師，上可徒手擼代碼，下可作圖寫教程，生活中是個能和程序員談笑風生和甲方鬥智斗勇的人。個人博客：http://blog.akanelee.me，歡迎圍觀。

課堂上我很強烈要求學員，做任何思考都要有「依據」，沒有依據憑空想象出來的設計很容易被推翻，也無法說服別人、讓別人理解自己的思考邏輯和原因。所以我的答案會是「2」，先確認用戶會怎麼使用產品功能，再來思考 Wireframe 怎麼畫。

如果你有了功能，就直接開畫 Wireframe ，再拿 Wireframe 來確認用戶怎麼操作功能，恭喜，你會陷入無限漏圖補畫面的寰場

使者怎麼操作功能這件事和視覺沒有絕對的關係，「操作功能」和用戶的邏輯比較有關。今天在什麼畫面都不給你的情況下，要你憑空說出「會員註冊」的操作流程，你會怎麼思考?

以下是某訪客留言：

UI Flow 主要就是規劃頁面層級的彼此關係, 所以在其上並不會規劃其頁面中有哪些哪些內容, 因為那些”內容”並不是頁面, 除非那些”內容”有個整體概念(例如用戶點擊頁面上某個按鈕跳出Contact相關的信息, 但不會從UI Flow上知道Contact里具體包含什麼) ?

內容=文字、圖片、聲音、影片。

光 UI Flow 這份文件，的確看不出來這一頁包含哪些「內容」。

但是所有的文件都不是獨立存在，每一份文件皆環環相扣關連性很大。當你在看 UI Flow 時，要把其他文件攤在桌上一起對照。

從上圖中可以看到 UI Flow 在塔中間位置，下方還有 User Story、Functional Map、Flow Chart 這三份文件。更多關於 UX 研究的文件我就沒列入了。

即使 UI Flow 看不到「內容」，但其他文件會補完這個部分。

2. 其實UI Flow就是在規劃頁面了, 到底一個網站會有哪些頁面, 就是這時候要規劃完畢(當然之後有可能會因為討論Wireframe后回來再修), 其實在UI Flow之前的所有規劃也不見得很具體知道需要哪些頁面, 例如在Functional map也是整理歸納顧客想在這個網站內包含的內容, 以及功能, 除非他自己有說我一定要有什麼什麼頁面, 而且裡面要有什麼信息, 不然在UI Flow階段, 這時候頁面到底有幾層, 有哪些, 都必須自己想 ?

你忘記有 Flow Chart 這份文件了。有寫 Flow Chart，根本不用煩惱 UI Flow 怎麼生出來。

本文一開始我就有提到，做設計有「依據」，沒有依據或跳過步驟就會發生「不知道數據怎麼來」、「這玩意我要怎麼腦補生出來」的情況。

在「沒有 Flow Chart」的情況下就開始規劃 UI Flow，等於在自己不曉得功能和用戶之間的關係、不知道用戶怎麼操作功能、不知道用戶在操作任務過程中會發生什麼事，就要思考要提供哪些頁面給用戶…通靈啊!

(當年我在不知道 Flow Chart 的時候也是有了功能就直接跳去 UI Flow…事後補畫面補到死各種出包漏東西。驚覺自己肯定忽略什麼不然怎麼 UI Flow 可以用這麼沒頭沒尾的方式冒出來，圖還畫得這麼痛苦。)

就 UI Designer 的角度可以把 Flow Chart 看成「這個情境下用戶怎麼操作完成任務、軟件怎麼響應」，把 UI Flow 延伸為「因為用戶這樣操作、以及我們有這些功能和信息要呈現，所以頁面和頁面之間如此串接」。

關於Flow Chart 和 UI Flow ，這裡有篇小介紹：

Flow 就是「流程」，UI Flow 是頁面流程，而 Flow Chart 是流程圖，兩者是完全不同的圖表。

UI Designer 很熟悉 UI Flow，對 Flow Chart 可能不太熟。在軟件開發中 Flow Chart 通常是由 SA 撰寫，重點在「判斷」上…沒有那麼難，把它當成雜誌附的心理測驗，選「是」走右邊、選「否」走左邊就好了。

對 RD 來說，寫程序前都必需先知道「邏輯」，也就是由各種「判斷」組成的操作架構。對 UI 而言邏輯也很重要，不然用戶操作后要給他什麼響應?

最陽春的會員登入

以「會員登入」為例，用戶輸入賬號密碼，輸入正確就自動跳轉到會員信息頁，輸入錯誤就提示錯誤…

光從 Functional Map 就想畫 UI Flow 常常忽略「用戶操作錯誤怎麼辦」，最後一刻才發現有缺就是 UI 緊急加畫漏掉的頁面、 RD 苦命塞功能不優雅，提示錯誤又不是放下一個階段或是有空再補的東西，頁面和程序也不是靠嘴巴在畫在寫…

亂輸入就給你驗證碼

好像很簡單喔?才不只這樣。實際畫起來會發現很多東西在 UI Flow 上很容易忽略沒考慮到的部份。(而且怎麼可能就只有這樣不加功能?)

有時候用戶會一直輸入錯誤，合理猜想是有人試着盜賬號。常見的阻擋方法是讓輸入多次錯誤的用戶多填一個驗證碼的字段。所以 Flow Chart 就變成：

上圖只是簡單的流程示範，不過是隨口多一句「喂、幫我加個驗證碼功能」，Flow Chart 就會突然肥一截。真正的會員登入驗證還有更多花樣以及安全性考慮，比如登入錯誤 3 次就多提示一句「忘記密碼」等等，更狠的直接鎖賬號請用戶找客服申訴。

Flow Chart 和 UI Flow 相輔相成，甚至是先有 Flow Chart 才有 UI Flow 。在沒有 Flow Chart 、不知道要處理多少判斷時就產出 UI Flow，規劃不周掉頁面漏功能的機率非常非常高。

若只有 UI Flow 沒有 Flow Chart，RD 勉勉強強可以憑畫面想象 Flow Chart、判斷式怎麼下，但系統越大會容易出包有 Bug，依 RD 經驗值決定出包機率。但連 UI Flow 都沒有，光憑几張 Wireframe 或 Mockup，根本就是瞎子摸象，看單張靜態圖 RD 不會知道頁面怎麼串，純靠腦補不錯才怪。

如果什麼都不給，直接扔 Prototype 給 RD 叫他照抄，說一模一樣做一個出來、很簡單吧?RD 還要每個畫面每個按鈕按都戳戳看、試過各種錯誤才會知道功能怎麼接。對 RD 是有多大恨這樣整人家…

就 UI Designer 的角度可以把 Flow Chart 看成「這個情境下用戶怎麼操作完成任務、軟件怎麼響應」，把 UI Flow 延伸為「因為用戶這樣操作、以及我們有這些功能和信息要呈現，所以頁面和頁面之間如此串接」。

UI Designer 不一定要會畫 Flow Chart，但一定要看得懂。常見流程圖符號是固定的，不要因為長得丑就自己設計個新樣式，RD 絕對來翻桌。

有句名言「婚前腦袋進的水就是婚後流的淚」，套到軟件開發上，開工前少花的腦就是開工后要傷的肝。有多少功能前期沒想到、就有多少工時後期沒料到…

如果先畫 Wireframe 再來思考用戶怎麼操作呢?

這和「精心準備菲力牛排招待客人，但客人不吃牛肉」有什麼不一樣啊?

「對～我們猜用戶會怎麼操作，畫了這些 Wireframe，再做 Prototype 讓用戶實測驗證，就不會出錯了唷～」

除非是已經套程序的 Prototype ，不然測不出「錯誤狀態」的啦，不要以為什麼都可以靠用戶測試找出問題好嗎?而且項目都進行到做套程序階段，再來抓漏不覺得太晚了嗎?萬一測出來發現有問題，打掉重練?當套程序的 RD 吃飽很閑嗎?沒事就陪着 UI 一起改來改去?

為什麼不一開始就調查好客人不吃牛，都上菜了才發現他不能吃，連忙補洞生出其他料理充數?

現在 UI、UX、UCD 什麼的一堆新興名詞，都在強調「以用戶為中心」，依用戶的操作習慣去設計。然後在畫 Wirefream 上卻是自己先弄個什麼出來再來想用戶怎麼操作，順序錯了吧。

套一句去年我在 Mopcon 演講的內容：「有這個功能，我們產品一定會大賣啊!」

最好有功能就會賣，用戶要的不是功能，要的是解決他問題的方法。

「有畫 Wireframe，用戶就會配合操作啊!」

「我們要教育用戶!」

所以你知道產品功能怎麼解決用戶的問題、用戶如何操作產品完成任務的操作流程沒有?

沒有，我只是負責畫 UI 擼圖的。

看完小編分享的教學之後 是不是對平面理論教程中的設計教程教學更熟悉了呢?

希望我們所介紹的 UI設計如何了解用戶操作習慣和畫線框圖 這教學會喜歡

文章標題: 骨子愛創意- UI設計如何了解用戶操作習慣和畫線框圖–轉載請註明來源處

本教學分類為平面理論教程中的 設計教程相關教學

文章相關關鍵字為: 操作,習慣,用戶,了解,設計,如何,Flow,UI,怎麼,功

本文永久連結 :UI設計如何了解用戶操作習慣和畫線框圖

本文轉載自 :VIA