使用者經驗藏寶圖:序

uxtreasuremap.png
Peter Morville 設計出「使用者經驗藏寶圖 」,如圖,說明一個構想是怎麼合理且適切地無中生有,一直到完成設計提出各式文件給客戶的開發流程。我覺得這是每位UI、RD、PM都該知道的流程,同時也是開發產品的必經之路。身為專案成員不應該悶著頭只做自己份內的事,了解團隊如何運作、每個階段該產出什麼,這點非常重要。

  1. 敘述故事:初期的發想為敘事型的段落文字,用較感性的方式描述一則短篇故事,這個故事能幫開發者找出問題,有提示、聯想、反應內心等等的作用。

  2. 找出中心思想:從短篇故事中會發現某種核心思想、某種抽象的理念,也許是一句短短的話,這句話非常重要,未來所有的發想將有可能都由此為中心點。

  3. 創建人物:有了故事與核心概念後,可以採用人物角色法營造一種或數種人物個性,建立他們的操作目標和行為。人物角色法可作為設計和開發的指南,提醒開發者這個人是目標使用者,所有的想法都該繞著這個人打轉。

  4. 代入情境:有了人物角色,請將他放入一個情境之中,觀查他會怎麼行動,考慮看看他真正的需求是什麼。也許不會只有單一個場景,這時候就要回到核心思想,仔細訂定人物的立場。

  5. 整理清單:有了前述的內容,可以開始將這些敘述性的文字圖片整理成清單。可能會是一個表格,或是有組織的文件,擁有明確結構及分類。這個步驟能幫助開發者從資料中更快分析出重點。

  6. 資料分析:從起因、目標、操作、慾望、需求、情緒等等各個角度,開發者會從中整理成合理的資訊。

  7. 使用者調查:為了驗證分析後的結果,需要進行使用者調查,從中發現與分析後資訊的共同點與差距,試著展示這一切,觀察使用者的滿意度。

  8. 製作概念圖:零碎的資料越來越多,需要篩檢統整成可用的部份,概念圖可以幫助開發者加快工作效率。可以看到目前進行到什麼位置、未來將會做什麼、建立標準、澄清關係,並確定方向。概念圖有點類似心智圖,但比心智圖更嚴謹,用將抽象的形容以具體的詞彙表達。有了概念圖後,這項產品包含哪些項目一目了然,建立系統圖會更容易。

  9. 製作系統圖:系統圖可以讓開發者與客戶瞭解這些功能是如何從有變成怎麼做,也代表這項產品真正需要的是什麼,沒列在系統圖理的就是不重要、可以被捨棄的部分。

  10. 訂定頁面流程:確定功能之後,才能訂定頁面流程,這個步驟非常重要,能不能精簡使用者的操作,避免迴圈、死路,讓使用者覺得體貼方便。

  11. 繪製 Wireframe 線稿:待流程都確定後才開始畫 Wireframe 線稿。Wireframe 又稱做介面框線,指的是去除視覺設計細節的原則下,以規劃頁面結構、資訊層次組織、功能以及內容的低保真原型。繪製介面框線的目的在於將每個功能化為實體可操作的介面元素,包含欲呈現的資訊內容、可操作的按鈕位置、版面的編排等等。

  12. 設計故事板:如何要測試線稿圖是我們所要的呢?這時候需要故事板來輔助。隨著故事板中的時間、環境推移,不只可以表達產品和使用者之間的關係,從中能看出兩者之間的互動,發現線稿需要增加或減少的部份。

  13. 概念設計:線稿可說是低保真度的原型,以快速修改、將腦中的構想迅速呈現為目的,並不那麼重視圖象的細節。到了概念設計階段才開始製作高保真度的圖象,加入視覺部份,對畫面細節以 1px 為單位斤斤計較。

  14. 原型設計:我大約分成五個大類,紙上原型、裝置上的靜態圖片、可在裝置上進行互動的介面、影片視訊、程式碼。各有各的優缺點和適用時機,也有不同的限制。

  15. 書面報告:做了這麼多前置工作,該是向客戶提出正式報告的時候了。將之前的概念、發想過程、各種圖表彙整起來,加入分析或建議提出書面報告。可以制定統一格式,為來在開發不同專案時都會派上用場。

  16. 簡報檔:簡報檔也是很重要的環節,客戶不見得會有興趣看到一本厚厚的書面報告,對裡面的字句也不見得有耐心琢磨,要怎麼說服客戶就得靠簡報檔了。加上圖片、影音,讓說明的過程更多元化。要說服客戶,這個案子才有繼續發展的可能。

  17. 排訂工作計畫與項目:客戶點頭同意確認後,總算可以開始規劃時程,排訂工作計畫與項目,分配工作給專案成員,開始撰寫程式、架設伺服器、建立後台等等。

  18. 撰寫規格文件:一個案子從頭到尾都有可能會交派給其他人接手,所以規格文件非常重要,他是從 A 過渡到 B 的一個必要元素。文件寫的越詳細,接手的人就越能無縫接軌。

  19. 介面規範:除了軟體規格外,介面也需要撰寫一份規範文件,從定義風格到每一個介面元素的色彩、尺寸、間距,包含字體、字級、色彩、過場動畫等等,供程式撰寫人員照此數據進行開發,未來若產品改版也可當成延續發展的依據。

  20. 集結成冊成為設計模式:最後一步就是將所有的資料集結成冊,成為一種設計模式。這種設計模式指的不光只是針對這項產品,而是能夠轉換成其他專案也能套用的資源庫。未來在開發類似的產品時,也能用更快速完成開發前的討論工作。

同樣的,除了不精準的翻譯之外,也加上我自己的經驗和個人想法,和原文多少會有不同之處。User Experience Deliverables 原文寫得很棒,都該去看一下。有時候限於公司規模或專案大小、不是這20個步驟都會跑一遍的。時間就是金錢、哪來這麼多錢可以讓 UI 去跑使用者測試這樣燒人日?通常都是腦海裡過個場就直接從製作概念圖下手了(原文也沒提到使用者測試喔科科~)。也有很多公司不會有 UI 的規格文件、介面規範、設計模式等等,因為前無古人後無來者、加上結案就 bye bye 不會再見了沒必要花人力在這部份上。

未來我會針對這 20 個步驟提出個人實際運用心得和操作技巧、方法等。會寫得很苦吧我覺得…

Akane Lee

Akane Lee

如果設計師能和工程師順利合作,那麼老公也就能準時下班了吧!因此努力分享 UI 和 UX 方面的知識、技術、各種踩過的坑與心得。

Comments

wave
comments powered by Disqus

Press ESC to close