每次專案開發，總覺得像在尋寶。
但沒有地圖，怎麼找得到寶藏？使用者經驗藏寶圖，就是我們的指引，
帶領團隊從構想到設計，順利抵達終點。
Peter Morville 設計出「使用者經驗藏寶圖 」
如圖，說明一個構想是怎麼合理且適切地無中生有，一直到完成設計提出各式文件給客戶的開發流程。我覺得這是每位UI、RD、PM都該知道的流程，同時也是開發產品的必經之路。
身為專案成員不應該悶著頭只做自己份內的事，了解團隊如何運作、每個階段該產出什麼，這點非常重要。
- 敘述故事
初期的發想為敘事型的段落文字，用較感性的方式描述一則短篇故事，這個故事能幫開發者找出問題，有提示、聯想、反應內心等等的作用。
- 找出中心思想
從短篇故事中會發現某種核心思想、某種抽象的理念，也許是一句短短的話，這句話非常重要，未來所有的發想將有可能都由此為中心點。
- 創建人物
有了故事與核心概念後，可以採用人物角色法營造一種或數種人物個性，建立他們的操作目標和行為。人物角色法可作為設計和開發的指南，提醒開發者這個人是目標使用者，所有的想法都該繞著這個人打轉。
- 代入情境
有了人物角色，請將他放入一個情境之中，觀查他會怎麼行動，考慮看看他真正的需求是什麼。也許不會只有單一個場景，這時候就要回到核心思想，仔細訂定人物的立場。
- 整理清單
有了前述的內容，可以開始將這些敘述性的文字圖片整理成清單。可能會是一個表格，或是有組織的文件，擁有明確結構及分類。這個步驟能幫助開發者從資料中更快分析出重點。
- 資料分析
從起因、目標、操作、慾望、需求、情緒等等各個角度，開發者會從中整理成合理的資訊。
使用者調查：為了驗證分析後的結果，需要進行使用者調查，從中發現與分析後資訊的共同點與差距，試著展示這一切，觀察使用者的滿意度。
製作概念圖
零碎的資料越來越多，需要篩檢統整成可用的部份，概念圖可以幫助開發者加快工作效率。可以看到目前進行到什麼位置、未來將會做什麼、建立標準、澄清關係，並確定方向。概念圖有點類似心智圖，但比心智圖更嚴謹，用將抽象的形容以具體的詞彙表達。有了概念圖後，這項產品包含哪些項目一目了然，建立系統圖會更容易。
- 製作系統圖
系統圖可以讓開發者與客戶瞭解這些功能是如何從有變成怎麼做，也代表這項產品真正需要的是什麼，沒列在系統圖理的就是不重要、可以被捨棄的部分。
- 訂定頁面流程
確定功能之後，才能訂定頁面流程，這個步驟非常重要，能不能精簡使用者的操作，避免迴圈、死路，讓使用者覺得體貼方便。
- 繪製 Wireframe 線稿
待流程都確定後才開始畫 Wireframe 線稿。
Wireframe 又稱做介面框線，指的是去除視覺設計細節的原則下，以規劃頁面結構、資訊層次組織、功能以及內容的低保真原型。繪製介面框線的目的在於將每個功能化為實體可操作的介面元素，包含欲呈現的資訊內容、可操作的按鈕位置、版面的編排等等。
設計故事板
如何要測試線稿圖是我們所要的呢？這時候需要故事板來輔助。隨著故事板中的時間、環境推移，不只可以表達產品和使用者之間的關係，從中能看出兩者之間的互動，發現線稿需要增加或減少的部份。概念設計
線稿可說是低保真度的原型，以快速修改、將腦中的構想迅速呈現為目的，並不那麼重視圖象的細節。到了概念設計階段才開始製作高保真度的圖象，加入視覺部份，對畫面細節以 1px 為單位斤斤計較。
- 原型設計
我大約分成五個大類，紙上原型、裝置上的靜態圖片、可在裝置上進行互動的介面、影片視訊、程式碼。各有各的優缺點和適用時機，也有不同的限制。
書面報告：做了這麼多前置工作，該是向客戶提出正式報告的時候了。將之前的概念、發想過程、各種圖表彙整起來，加入分析或建議提出書面報告。可以制定統一格式，為來在開發不同專案時都會派上用場。
簡報檔
簡報檔也是很重要的環節，客戶不見得會有興趣看到一本厚厚的書面報告，對裡面的字句也不見得有耐心琢磨，要怎麼說服客戶就得靠簡報檔了。加上圖片、影音，讓說明的過程更多元化。要說服客戶，這個案子才有繼續發展的可能。
排訂工作計畫與項目：客戶點頭同意確認後，總算可以開始規劃時程，排訂工作計畫與項目，分配工作給專案成員，開始撰寫程式、架設伺服器、建立後台等等。
撰寫規格文件
一個案子從頭到尾都有可能會交派給其他人接手，所以規格文件非常重要，他是從 A 過渡到 B 的一個必要元素。文件寫的越詳細，接手的人就越能無縫接軌。
- 介面規範
除了軟體規格外，介面也需要撰寫一份規範文件，從定義風格到每一個介面元素的色彩、尺寸、間距，包含字體、字級、色彩、過場動畫等等，供程式撰寫人員照此數據進行開發，未來若產品改版也可當成延續發展的依據。
- 集結成冊成為設計模式
最後一步就是將所有的資料集結成冊，成為一種設計模式。這種設計模式指的不光只是針對這項產品，而是能夠轉換成其他專案也能套用的資源庫。未來在開發類似的產品時，也能用更快速完成開發前的討論工作。
同樣的，除了不精準的翻譯之外，也加上我自己的經驗和個人想法，和原文多少會有不同之處。User Experience Deliverables 原文寫得很棒，都該去看一下。
有時候限於公司規模或專案大小、不是這20個步驟都會跑一遍的。
時間就是金錢、哪來這麼多錢可以讓 UI 去跑使用者測試這樣燒人日？通常都是腦海裡過個場就直接從製作概念圖下手了（原文也沒提到使用者測試喔科科～）。
也有很多公司不會有 UI 的規格文件、介面規範、設計模式等等，因為前無古人後無來者、加上結案就 bye bye 不會再見了沒必要花人力在這部份上。
未來我會針對這 20 個步驟提出個人實際運用心得和操作技巧、方法等。
會寫得很苦吧我覺得…
