用戶體驗設計這詞大概是我心中揮之不去的幽靈，除非我皈依它的門下，否則絕不給我任何喘息。
作為妥協，先提及一本新書，雖然作者與出版商都沒有給我任何推介費用，更沒有授權我引用相關內容，我還是決定介紹The UX Booth 對本書的一段引用：Winning a User Experience Debate 。這篇文章引用了原書第五章的一段內容，我僅引述若干並綜合一些要點：
要將用戶設計體驗融入商業核心，你必須說服同事信任你的意見與專長。良好處理批評/批判是贏得信任的重要方式。輕率的否定他人會讓你辛苦的工作輕易的化為烏有。絕不要草率的忽略利益相關者（stakeholder，泛指公司決策層、相關部門、其它相關利益方、用戶等所有利益關聯方）的意見。每個設計師都會犯錯，而這世上總有你尚未考慮到的方式可以用來解決問題。最糟糕的用戶體驗設計師莫過於那些認為利益相關者都是設計文盲的夜郎自大者。你的商業夥伴、同事或許確實無法像你一樣將想法通過視覺方式表達出來，然而聰穎的利益相關者永遠是一個用戶體驗設計師的優勢所在。
如果你懷疑利益相關者的要求，無論如何先對這一要求做出嘗試，然後再以你的方式去做。這會花費更多的時間與精力，但你也是在通過顯示自己能夠聽取反饋而獲得他們的信任。你也許能（因此）說服利益相關者為什麼你的設計更好，又或許你會發現他們的建議其實更好。
書中談到驗證棧（Validation Stack）這一自創概念，從三個層面為你的設計決策辯護，這三個層面分別是：
- 用戶證據（User Evidence），即直接從用戶得來的數據，無論是可用性測試還是系統使用日誌，這是為設計決策辯護最有力的證據；
- 用戶研究（User Research），沒有直接的用戶數據，相關的用戶研究和設計原則（Design Principles）是下一選擇，例如我們談到過的表單設計；
- 設計理論（Design Theory），如果前兩者都缺失，那麼諸如Fitts Law，或是某條心理學/社會學理論或許能成為“救命稻草”，然而設計商業產品不是做科學研究，一個缺乏完美理論支持但用戶測試良好的設計總是比一個“理論正確”的設計更好。
當表單設計中被要求加入一個你認為“非必要”的問題，或者已是擁擠的頁面被要求再增添廣告時，你要如何為用戶辯護呢？或許我們會說，認知負擔是積累效應，這樣一些小的改動會損害用戶體驗，但如果對方說：證明給我看！ （Prove it!）你會怎麼辦呢？幾十上百條糟糕設計的積累效應或許明顯，但多加一個表單問題這樣微小的改變或許難以察覺。你要如何挑起用戶體驗這一責任？原書的意見請大家看原文 ，算我賣個關子，包括所謂什麼叫FY閾值（FY Threshold）。
下面說說我的一點個人想法。
既然被稱作用戶體驗設計師，那麼主要責任就是保證用戶體驗保持在公司期望的狀態內，雖然你必須理解如公司的長远战略、商業目標，甚至包括一些設計決策背後可能削弱用戶體驗的邏輯依據，但這並不代表你要弱化自身立場。你的職責不是平衡各方利益而使所有人皆大歡喜，你是用戶的捍衛者，是他們對公司產品體驗的發聲者，如果用戶不喜歡增添廣告，不喜歡被多問問題，那麼這就是你的立場。如果連你都認為，作為用戶還是可以忍受多一點廣告的，那麼一個用戶體驗設計師的存在意義在哪裡呢？如果設計決策影響了用戶體驗，你的職責是收集所有證據評估這一影響，使設計團隊得到充分的信息（對你來說就是提供用戶信息）做出設計決策。
對商業目標的理解是用戶體驗設計師與其它團隊成員交流溝通合作的基礎之一，是作為團隊成員理解並接受某一平衡決策的邏輯依據，但不是弱化自己立場的理由。你可以提出你的設計思路，向團隊陳述如何更大的保障用戶體驗的同時平衡商業目標，並告知這樣設計對用戶體驗的代價是什麼。但你的職責不是妥協各方，達成設計決策，而是將用戶體驗質量最優化。如果你每遇目標衝突便弱化甚至失去自己的立場，那麼這個職位本身就沒有意義了。
UX Booth對Undercover User Experience Design這本書的作者有一個專訪文章 ，如果你有興趣，不妨一讀。
EuroIA 2010
上一周提到歐洲信息架構峰會（Euro Information Architecture Summit 2010）。 這個鏈接 提供了幾乎所有講演的slides（我真不知該怎麼翻譯了， PPT？非也。幻燈片？好像也不對。只好請各位將就一下英文了），在你鼓起勇氣一一打開那20多條鏈接前，我推薦你先讀一下James Kelway的文章 。
工具與問題
工具是用來解決問題的，每種工具也有其針對的問題域。如果不理解這種對應關係，那麼拿著大砲轟蚊子，拿著手術刀切西瓜就不只是笑話了。
Daniel Ritzenthaler 在這一周的52 Weeks of UX 上寫了一篇文章Match the Tool to the Problem （將工具與問題配對）。談論的是這樣一個老話題：sketches（草圖），wireframes（線框圖），mock-ups（實體模型），HTML prototypes（HTML原型），哪個更好？下面我直接翻譯好了：
- 草圖 ，一般為手繪圖，包括屏幕概念（screen idea），或是描述抽象層面問題或解決方案的繪圖。這些草圖在概念未完全經過探索、成型和實現時極具價值。草圖可以幫助你理解大概需要哪些組成部分以達成目標。
- 線框圖 ，大多由計算機生成以闡釋內容的組織結構，特性和功能。將設計中的元素優先化（prioritization）並決定大概的頁面佈局可能是項目中相當繁雜的部分。一個架構良好的線框圖可以幫助你將各組成元素分離，並確定他們是否符合當前頁面的目標。
- 實體模型 ，豐富的圖形化產物（一般用Photoshop等軟件製作，一個例子 ），以模擬一個項目的外觀與感受，使你可以理解視覺元素對品牌的影響。實體模型可以設定正確的印象並溝通項目的情感元素與個性。
- HTML原型 ，一個網站的部分實現版本，用來理解頁面之間的互動和流程。當目標的實現涉及大量複雜交互時，HTML原型確實可以幫助你找到初始計劃中的空白點。
舉例：
你要構建一個基本的營銷網站 而且你已經理解該網站的目標，並自信於此類網站的佈局以及頁面間的交互。那麼直接使用實體模型是最有效利用時間的方式，這樣在最短時間內你就能得到最接近最終結果的效果圖。
這是你第九次構建一個已經被廣泛清晰理解的Web應用 ，而你已經深刻理解其目標以及頁面交互，但你希望自己的設計能夠完美的適應到客戶的設計開發團隊中。這時線框圖成為首選，它們能幫助你在Web應用如何組織，以及發掘潛在方式，使界面更加本能、直覺化（intuitive）等方面進行溝通。
你以一個全新的概念 起步，而最艱難的部分是真正把握概念並決定頁面如何工作。這時你很可能需要在草圖與HTML原型間反复，直到你自信已經抓住概念的核心目的。而這些初始HTML原型可以成為非常好的測試工具，用來收集你的團隊和潛在用戶的反饋。
每個項目或許都需要這些工具中的一個甚至全部，這取決於你所面對的挑戰。所以討論的內容並不應該是哪個工具更好或者如何將他們納入一個正式嚴格的設計過程中。而應該是哪一種工具，在給定的時點，可以給予設計者對設計理念的最大清晰度並提高設計效率。
或許你的實際經驗與上面的說法相左，非常希望聽聽你的經驗之談。
如何使用用戶體驗設計師
Jason Buck寫了一篇文章，名為How should a user experience designer be used? （用戶體驗設計師該被如何使用）。一看到這題目就讓我想到很多家用電器使用手冊：The handbook for …不知哪天誰會寫本“戶體驗設計師使用手冊”，當然這只是玩笑，Jason列出的建議：
- 檢查你的用戶體驗設計技能：誰都可以畫線框圖。但（用戶體驗設計師）他們必須能夠進行（最終用戶）研究，組織實現（與他人的）討論和研討會，與客戶辯論，優秀的口頭與視覺溝通者，專注於GTD（Getting things done）；
- 在早期納入用戶體驗設計；
- 允許用戶體驗設計師與客戶接觸；
- 確保對交付物以及項目最終成果的共同理解；
- 讓用戶體驗設計師（向客戶）呈現他們的工作。
然而我覺得Jonathan Lupo在How to Design for the End-User 上寫的一篇回應 似乎更值得一讀。其中對於線框圖Jonathan談道，交互設計師或信息架構師必須說明設計決策如何達成商業和用戶目標，這一邏輯依據與設計情境（context）必須與線框圖一起提交，而且實現目標的決策必須是可評估測算的（measurable）。從這個角度來說，線框圖不是什麼人都能夠製作的。
BTW，說到線框圖，想起Onextrapixel有一篇文章收集了40個“brilliant”線框圖 。如果你和我一樣是個只會畫圈畫框和火柴人的程序員出身，那麼諸如流程圖、線框圖這樣圓圈方塊的應該是感覺相當親切了（其實時序圖和狀態圖畫起來也是很好玩的，當然，好玩在於邏輯的分析與呈現過程，並不是線框本身了）。
字母排序（大多）該死了
可用性名人Jacob Nielson的文章Alphabetical Sorting Must (Mostly) Die ：
在向用戶呈現選擇時，序數排列，邏輯結構，時序，重要度優先序或頻率優先序通常比AZ列表更好。
對選項列表進行字母排序有兩個主要好處：
- 如果用戶知道他們所需事物的名字，那麼他們可以在列表中迅速找到；
- 懶惰的設計團隊無需努力尋找更好的結構。
當然，Jacob的文章不止這麼四句開場白，不過你大概已經知道他的意思了。這篇文章讓我想起另一個問題，上一次你在某網站上選擇所在省份、所在城市是怎麼完成的？聯想Jacob的這篇文章，你大概多少也知道我的意思了。
Bing與Google的可用性比較
如同在第一周提到的GMail，Hotmail和Yahoo! Mail的可用性比較，Web Design Ledger用類似的方式比較了Bing和Google ，當然，只是從首頁佈局來測試。上次八卦了一下三種郵件服務的得分，這次我建議讀一讀文章對可用性測試所提出問題的分析，至於得分，留待你去發現吧。
Instant Amazon Search
我猜想大家都聽說了Google Instant ，然而它至今只限於美、英、法、德、意、西、俄這幾個國家的用戶。它所帶來的交互方式以及由此產生的用戶體驗，用一句標準廢話叫做“有待觀察”，不過估計不少可用性實驗室正在做這個測試吧。剩下我們要如何體驗呢？找個代理或許是個主意，不過The Next Web 介紹的Shelfluv 或許能夠帶給你一些體驗，試試吧。
一次UI設計模式設計帶來的創意
CSS-Trick組織了一個團隊設計項目 ，項目目標是一種設計模式：A list with functions。假設前提：
The design pattern we are going to tackle is a list with functions. Think of a list of five names. The primary function of this list is to click the names. The secondary function of the list is that the list needs to be manageable. There needs to be some kind of functionality to edit and delete each list item.
我怕翻譯不准，把原文貼在這裡，大意是一個有五個名字的列表，列表的主要功能是點擊這幾個名字，輔助功能是這個列表是可管理的，需要能夠編輯和刪除列表項。
並不復雜，不是嗎？我估計你心裡已經有了不止一種設計，不過我覺得有趣的是文章中列出的設計方案所呈現的各種交互方式、設計細節和思考局限。或許你總覺得自己的設計實在完美無敵，但大千世界，更多的接觸他人的作品或許能夠讓我們開拓視野，成為一個更好地設計師吧
其中最受編輯青睞的設計：
結尾，再次向各位抱歉，這篇文章因為個人健康原因而推遲了三天。隨著身體狀態的恢復，我也終於完成了上一周的任務，祝各位這一周一切順利，雖然這句話也姍姍來遲了。
Cheers, everyone, and have a very pleasant week!
版權聲明：轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://arslanyard.blogbus.com/logs/76867402.html
特別注意：本站所有轉載文章言論不代表本站觀點，本站所提供的攝影照片，插畫，設計作品，如需使用，請與原作者聯繫，文章轉自alibuybuy