雜談設計工具
Persona 人物型格
很多時候,人們都認為人物型格是根據目標使用者來確定的,儘量貼近目標使用者,以此來作為設計的依據。但問題是,目標使用者是不確定的,是一群人,有各種差別,但是人物型格卻高度確定,是一個人,所有東西都已經限定好了。此外,每個人對於目標使用者的理解是不同的,如果按照這個思路,就無法得出一個確定的人物型格。所以說,人物型格的目的並不是為了給目標使用者做一個模型。
那麼它的目的是什麼?根據上面的分析,我們知道,在設計中需要做各種權衡,大家會有各種碰撞,但是為了最後設計效果的統一,每個人都必須做一些妥協,形成一個標準。人物性格就是這樣一個標準目標使用者,它的作用是讓所有專案參與者達成共識,所以,求的是精確而不是準確。
有了精準的人物型格定義,在做判斷的時候,我們就有了標準。比如:是選用純圖示的按鈕,還是選擇圖示加文字的按鈕?已知純圖示的按鈕更加符合當前的頁面風格,而且圖示也已經有約定俗成的標準,不過也有設計師認為加上文字更清楚一些。設計師之間產生了爭執,怎麼辦?看看人物型格,是一位36歲,在IBM工作的軟體工程師。好了,既然是在軟體業工作的人,肯定對於這一塊領域比較熟悉,所以,最終的設計決定就是,選用純圖示的按鈕。
人物型格的作用就在於此。
Sketch & Prototype 草稿圖和產品原型
很多設計師認為,草稿圖、線框圖以及低保真互動模型等等是給客戶看以換取反饋的。可是,在絕大多數情況下,客戶並不是設計師,也沒有經過相關的訓練,無法對於草稿圖、線框圖等等進行評判和反饋。經常會有客戶認可草稿圖和線框圖,但是卻對最終產品非常不滿的狀況。
實際上,草稿圖和線框圖以及低保真互動模型都是為了設計師之間進行交流,呈現給客戶的,永遠應該是他們能夠看懂和看明白的版本。汽車行業的設計師是不會拿一部木頭做的概念車來進行測試的,而是拿一部和真實成品相差無幾的車來進行測試。這輛車的外形、材料等等都使用了和最終成品非常相似的材料,所以人們可以對它進行全面的測試和反饋。
數字產品的設計也應該是如此。
也許你會問,這樣不就失去了草稿的意義了嗎?其實沒有。正如之前所說,草稿等工具的目的是為了設計師之間相互交流,相互碰撞,這是沒有必要呈現給客戶的。設計的最終產出物一定是優美的,漂亮的,完整的,這樣客戶才能進行反饋。幸好,現在我們的技術已經非常高效,足以使我們快速產出一個完整的原型產品,供客戶進行快速反饋和修改。
Feedback 反饋
要做好設計,反饋非常重要,但反饋也分高低等級。
高等級的反饋:我們希望使用者能通過這個頁面對我們的產品有一個大體的瞭解,讓使用者覺得安心,但這個頁面沒有給我這樣的感覺。
低等級的反饋:頁面的配色不太好,需要換成一個更加有活力的顏色。或者:頁面資訊架構有一些問題,需要調整一下。
設計師之間的反饋應該是低等級的,即站在資訊架構、設計心理學、風格、美術等等專業的領域來進行的反饋和討論。而客戶的反饋應該是高等級的,即站在產品、公司、業務等層面來進行反饋。
現在的問題是,很多客戶會直接對設計進行低等級的反饋,這是不恰當的。
首先,對於設計以及任何一個系統工程來說,每個細節都是整體的一部分,是無法單獨提出來進行修改的。對於某一個部分的修改往往會牽涉其他多個部分的協同配合。正如我們很難把臉部五官漂亮的人各取一部分然後組成一個超級大美人一樣,設計也是很難單獨把某一個細節改動,形成更好的設計。
其次,設計是一項專業性非常強的活動,設計師的設計也許經過了千錘百煉,多次討論和妥協,最終得出的結果。而這些妥協和討論之中,很可能已經包括了客戶想到的修改,所以客戶不應該對細節直接進行反饋。
客戶直接提出高等級的反饋,由設計師理解,領會之後形成新設計,這固然完美,但這不是當前的現實。那麼,怎麼面對客戶提出的低等級反饋?設計師本身應該具備高超的交流技巧,這其中也包括對客戶的反饋進行引導和梳理。當客戶提出某個細節反饋時,比如字號改大一些,設計師應該幫助客戶梳理其高等級的反饋是什麼:
字號要改大一些。
(為什麼需要改大一些?)
這樣看得更清楚一些。
(現在的字號已經挺清楚的了,而且符合人眼覺得舒適的比例。為什麼需要更清楚一些呢?)
因為我年齡大了,帶著老花鏡,希望能看得更清楚一些。
(我來看看,我們的人物型格是,52歲的退休教師,果然。這個年齡的使用者確實常有老花的情況,我們應該考慮這一點,此外,還有一些圖片的大小也有一些問題,我們也會一併整改。)
這樣,就整理出了一個高等級的反饋,即:頁面的設計無法吸引到目標使用者群體,即中老年使用者,因為頁面的設計不符合他們的使用習慣。此外,根據這一個高等級的反饋,設計師還應該進行相關的其他整改。
這就是所謂的 designer as communicator。
Lean UX Design 精益式使用者體驗設計
Lean UX 意味著去除設計過程中的浪費。設計過程中的最大的浪費不外乎做出來的東西客戶不滿意,需要修改或者重做。雖然說客戶不滿意的原因很多,但是隻有一個原因是真正有意義的,那就是設計沒能解決客戶的問題。
產生這個問題的原因在於我們把設計的分成了客戶需求和交付產出兩個部分。可是,客戶需求是會不停變化的,而與之對應的交付產出也會有不同。按敏捷的思維來做,我們可能會用小迭代的方式,不斷的更新需求和交付產出,最終達到客戶的要求。不過,這樣做有兩個問題。第一是其浪費仍然很多,因為我們仍需不斷解決需求變動的問題。第二是迭代較小,為了解決需求變動的問題,呈現給客戶的必然是中間產物,如此前所說,客戶無法通過中間產物給出合適的反饋,從而失敗。
Lean UX 採用了一種顛覆性的思維來看待這個問題。
我們知道,資訊媒體可以分為結構、展現和內容幾個部分,而結構是最穩定的。如果我們希望能消除浪費,就必須找到比需求更穩定的設計參照物。這個參照物就是客戶希望能通過設計達到的效果(outcome)。在設計之前,我們會提出多個假設,並通過設計所達到的效果來驗證這些假設,一旦通過驗證,則意味著設計成功。驗證有人文和數字兩個方面。且待下回分解。
相關文章
- 設計模式雜談設計模式
- 範型程式設計雜談程式設計
- Mac雜誌設計工具Mac
- 雜篇:隨筆程式設計雜談錄–《隆中對》程式設計
- 函數語言程式設計雜談函數程式設計
- 【IT雜談】十年程式設計師程式設計師
- 程式設計雜談——Non-breaking space程式設計
- 隨筆程式設計雜談錄–《隆中對》程式設計
- 雜談!設計師表達溝通策略
- 今日頭條:iOS 架構設計雜談iOS架構
- 軟體設計雜談(一)--需求分析與系統設計 (轉)
- C++程式設計雜談:物件導向 (轉)C++程式設計物件
- 後端技術雜談8:OpenStack架構設計後端架構
- 軟體設計雜談(二)--軟體設計與設計人員的個人素質 (轉)
- 計算機編碼方式雜談計算機
- java遊戲開發雜談 - java程式設計怎麼學Java遊戲開發程式設計
- Swift雜談Swift
- synchronized雜談synchronized
- IT者雜談
- fragment雜談Fragment
- 面試必談的雜湊,.Net 程式設計師溫故而知新面試程式設計師
- 軟體專案計劃-估算雜談
- 談談設計模式 —— Iterator設計模式
- 談談程式設計師程式設計師
- 複雜性系統設計:福特CEO談特斯拉的三個特點
- 漫談世界觀敘事設計中的工具鏈
- CodeReview雜談View
- 【雜談】策略模式模式
- 資料雜談
- 雜談 CSS IN JSCSSJS
- 雜談其一
- 免殺雜談
- 數學雜談 #??
- 正則雜談
- 談談面試--雜湊表系列面試
- PHP 設計模式(雜項)PHP設計模式
- 雜想程式設計師程式設計師
- 一些雜感雜想(一)談談加班、團隊