Jesse James Garrett的《用戶體驗要素：以用戶為中心的產品設計》（The Elements of User Experience: User-Centered Design for the Web and Beyond，Second Edition）大概是UX入門的必讀作品了，前陣子在整理資料的時候順手把這張圖漢化了：

這張圖就是出自這本書，也是這本書內容的主要綱領，綱領都做了，順帶看一下原文也是情理之中。書本身的內容比我想象中要簡明，在我最初了解 UX的時候，我一直覺得這是一件不言自明的事情，在看過這本書之后，才發現領域的不同帶來的鴻溝竟是如此巨大：對于一把椅子來說，其功能性與用戶體驗是密不可分的，沒有良好的體驗的椅子，其功能性幾乎無從談起，而對于互聯網產品而言，功能與體驗的相關性就沒那么強（尤其在功能大量同質化的今天，產品體驗反而成為了成敗的關鍵）。現在 UX 或者 UCD已經成為一個流行詞匯，就像前兩年（乃至現在仍在）流行的“互聯網思維”，老板們開始試著重視這些東西是因為它們確實能帶來更高的效益。雖然四處都在招UX Designer，但我更傾向于另一種說法，UX是無法“被設計”的，用戶所有的體驗，都應當是順理成章理所當然清晰明了的，我們只能順著這些“理”，圍繞目標用戶的基本特質去設計我們的產品。書里試圖將“作為信息系統的網站”和“作為軟件界面的網站”融合起來，其實作為中國互聯網的年輕一代或者大多數，很少有經歷過單純“作為信息系統的網站”的時代，我接觸互聯網的時候，中國互聯網已經有了三大門戶，各種工具不一而足。我一直以為只要目標明確、手段清晰、技巧得當，最終產品總不會太糟糕，因而在我看來，這本書可能其實是在講產品經理在做的事——開發產品的流程（難怪豆瓣用戶都喜歡把這本書丟進產品經理的書單里）。為何用戶體驗要貫穿產品開發的始終，在本書中所提到的第一個層面，戰略層，其所指與網站的功能或內容都毫不相干，然而卻在潛移默化中影響著最終的功能形態和內容構成。誠如書最后所言，產品的開發過程應該更類似于馬拉松，而不是一個一個階段的短跑沖刺。如果產品最終的流程如絲般順滑，用戶在任何一個角落都可以輕松找到自己想要的內容而歡欣鼓舞，那么這個產品的基礎，也就是其戰略目標，一定是清晰的。而就算瞎貓碰上死耗子，漫無目的的產品仍舊產出了良好的體驗，要么你可能需要回頭修改你的戰略，要么就很有可能有更大的潛藏的問題（比如用戶喜歡，你卻得不到盈利？）

用戶體驗要素的分層

這張圖是上面那張圖的綱領形態，五個層面對應五層所需的行動。雖然作者將產品開發流程分為5個層面的行動，但這5個層面并非彼此割裂孤立的，向上反饋是必要且重要的，及時修正上一層面操作中所出現的問題，可以為將來的發展鋪墊得更好。

戰略層

研究思考產品為何而生，于人于己的意義何在？品牌形象如何融入？用戶細分及用戶研究，并撰寫戰略文檔都是此階段要做的事情。

公司開發一個產品，肯定是為了賺錢或者省錢，個人開發某個產品也許只是為了自己爽，而賺錢或省錢的方式各有千秋，每個人G點也不同，所以產品目標應該是基于雙方（開發者及使用者）需求提出的，找到需求點，提出問題及解決方案。

而這也就勢必牽涉到對用戶的分析，目標用戶群體是怎樣的，他們的年齡段，對互聯網的使用習慣，生活習慣，人生三觀，以及針對產品的一些特殊需求等

等，通過不同的手段將用戶分成不同類別。然后就是對這些用戶群體的研究，可以是通過他人已經完成的研究成果，也可以自己去做。我不太喜歡調查問卷（因為我

自己本身就是一個習慣性問卷作弊者…），實際的操作記錄及用戶測試相對更加可靠，最終根據測試和調研結果，虛構若干個“使用者”，將具有代表性的需求分配

給這些“使用者”，這樣產品出產會更加順利。

而對于開發者而言，開發產品的目的大抵是明確的（假裝他是明確的，不明確的不要做了趁早洗洗睡吧），這里需要額外思考的是品牌形象的整合，與如何將

一整套戰略完整地傳達給團隊中的每一個人，畢竟就算制定了策略，最終的實施者卻是實際開發的團隊成員，倘若他們不知道策略如何，談何實施。最后應該是成功

標準，有了目標，就要有是否達成目標的標準，倘若不是轉化率注冊率之類的數字，訪問量停留時間這樣的指標也可以。

范圍層

需求定義。

之前根據用戶需求提出了產品目標，現在則是根據產品目標提產品需求：內容和功能上的。為了滿足用戶以及我們的種種需求，這個產品需要囊括哪些內容，

需要建立哪些功能，這些功能又需要哪些內容，這些內容又需要哪些功能來支撐。所以其實我不太懂把功能和內容割裂思考的方式，它們本來就是水乳交融。

所有的需求都要寫下來，并且盡量避免抽象（最受歡迎）、主觀（高大上）或者略語（等等），這些需求應該是可以確定是否已經滿足的，像“時尚時尚最時

尚”這種表述，鬼知道什么產品能滿足。內容需求則應該涉及到文字、圖像、影音文件的相關數量及更新頻率等等，并且根據使用者的不同區分出不同的內容需求。

最后確認這些需求的優先級，以及它們跟戰略目標之間的關系，如果某個功能或內容需求無法滿足戰略目標，那就要思考是哪邊的問題，并及時修正（刪掉這個需求，或者修改戰略）。

結構層

交互設計與信息架構。這倆都是術語，也已經自成學科。對于交互設計來說，產品功能通過怎樣的流程行進，如何能滿足用戶潛意識下的反應，通過隱喻或者其他方式讓用戶減少思考，令其能夠憑直覺使用網站的功能，并通過各種方式減少用戶犯錯的機會，及其所造成的挫敗感（及時糾錯），大抵就是交互設計在做的事。這里包含了各種各樣的模式，比如：當人們填寫完查詢表單并點擊提交的時候，希望看到的是查詢結果而非廣告或注冊窗口。

信息架構是網站內容的分類管理，這些內容的分類可以根據戰略層的產品目標逐一細分需求得到，也可以通過范圍層的內容需求進行分類整合，最好的做法是二者配合進行，最終令細分下來的內容符合內容需求，整合出的內容符合戰略需求。一個適應性強的信息架構系統，是有極強的擴展和統合能力的，如果很好奇這部分內容的話，我覺得去給 wiki做頁面分類是個不錯的選擇…內容整合或細分的困難點就在于如何留下足夠的彈性空間去容納新的部分而不破壞原本整體的架構，以及根據新的需求重新定義分類或增加分類方式。這些所有的信息分類組合，都要建立在前面所描述的需求及目標之上，能夠預知用戶的期望并將其納入設計。

在這個部分作者提到了網站架構圖——記錄網站頁面或文件的群集、獨立以及彼此之間的關系，在他的官網上有一份文檔描述如何制作架構圖，現在可能叫 User Interface Flow 的也有。名字和形態都不重要，這份圖表的最重要目的是將之前所有抽象的工作轉化成可操作的具體的事項，因為接下來，開發流程就要進入到一個完全具象化的世界里。

框架層

線框圖來了。

讓界面與用戶的習慣一致，讓對的東西出現在對的位置上，使用對的元素傳達對的信息（突出該突出的，讓按鈕成為按鈕）。讓用戶有能力在頁面之間跳轉

——有意識的或者是無意識的，應該至少提供一種方法。把信息分類組合，提供給界面和功能。把這些內容全部組合在一起，使用線框圖來呈現最終的結果。

表現層

把線框圖與美學合二為一，傳統的設計學終于登場。

使用多種感知方式，保證對比和一致性，做好配色和排版。如果需要的話，可能還要產出一份視覺 guideline，用于維護品牌一致性，并能夠為后繼者提供足夠的參考資料。

用戶體驗要素的取舍

開頭就說了這本書近乎于在講產品開發的流程，但是誰都知道能夠完整完成這套流程的團隊鳳毛麟角，那么是否就應該拋棄某些沒有實質性產出的部分呢……？

答案當然是否。在產品的開發設計過程中，所遇到的問題和奇怪的意見，只要拿來和目標與需求比對，就基本都能夠搞清楚是否采納或者如何反駁。所以產品

的目標與需求可以一步完成，需求與架構可以同步完善，甚至把線框也一起囊括，但總的來說，這些步驟所描述的具體內容都應該逐步完成，這樣才能最大限度地避

免各種潛在問題。