中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

用戶體驗設計這詞大概是我心中揮之不去的幽靈，除非我皈依它的門下，否則絕不給我任何喘息。

作為妥協，先提及一本新書，雖然作者與出版商都沒有給我任何推介費用，更沒有授權我引用相關內容，我還是決定介紹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 ：

在向用戶呈現選擇時，序數排列，邏輯結構，時序，重要度優先序或頻率優先序通常比A-Z列表更好。

對選項列表進行字母排序有兩個主要好處：

如果用戶知道他們所需事物的名字，那么他們可以在列表中迅速找到；

懶惰的設計團隊無需努力尋找更好的結構。

當然，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.

我怕翻譯不準，把原文貼在這里，大意是一個有五個名字的列表，列表的主要功能是點擊這幾個名字，輔助功能是這個列表是可管理的，需要能夠編輯和刪除列表項。

并不復雜，不是嗎？我估計你心里已經有了不止一種設計，不過我覺得有趣的是文章中列出的設計方案所呈現的各種交互方式、設計細節和思考局限?；蛟S你總覺得自己的設計實在完美無敵，但大千世界，更多的接觸他人的作品或許能夠讓我們開拓視野，成為一個更好地設計師吧

其中最受編輯青睞的設計：

結尾，再次向各位抱歉，這篇文章因為個人健康原因而推遲了三天。隨著身體狀態的恢復，我也終于完成了上一周的任務，祝各位這一周一切順利，雖然這句話也姍姍來遲了。

Cheers, everyone, ?and have a very pleasant week!

版權聲明：轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://arslanyard.blogbus.com/logs/76867402.html