步步為營的用戶體驗設計

　　之前搞了兩篇響應式Web設計方面的譯文，包括什麼是響應式Web設計？ 應該怎樣進行？ ，以及 通過CSS3 Media Query實現響應式Web設計 ;今天換個口味，來點兒務虛的。本文作者從一名用戶體驗設計團隊leader的角度出發，簡要介紹了UX設計相關工作在公司內部是怎樣步步為營的從無到有展開的。沒有不切實際的大道理，也沒有什麼技術細節的講解，通篇更像是作者對工作中典型階段的回顧與總結，包括團隊組建、理念及影響力的培養、部門協作、項目介入方式等方面。廢話不多說，走著。

　　多數時候，新的方式方法不會被很容易的付諸實踐。特別是在舊有習慣已經根深蒂固的情況下，前行過程中的每一個階段，在參與者看來，都好像是一種很新奇的玩意兒。不是所有人都喜歡新鮮事物，但是作為確切目標的執行者，大家必須學會新的思維方式與實踐方法，並貫徹到實際工作中。

　　在本文中，我(英文原文作者)將以公司網站的改版項目作為思路梗概，進行工作的回顧總結，並分析我們的團隊是怎樣在整個改版過程中步步為營的貫徹用戶體驗設計思路的。下面的插圖展示了改版前後兩個版本之間的顯著變化。

　　UX設計團隊(UED)組建伊始

　　最近，我被法國的一家主流電子商務網站聘請去組建一個用戶體驗設計團隊。在我赴職之前，這裡的UX團隊基本就是一個願望良好但組織松散的項目委員會，成員包括一名項目經理、一名功能及技術規范撰寫人員，以及一位自稱是人機工程專家的自由職業平面設計師。當這個委員會無法就某個最終設計方案達成一致時，他們會投票;通常的結果是，他們會接受全盤接受彼此的方案，因為投票結束時，開發周期所剩下的時間已經不允許他們做任何的修改和迭代了。本質上說，這個UX團隊對於所謂的“以用戶為中心的設計(UCD，user-centered desgin)”或是交互測試等沒有任何實際的進程規劃。

　　“用戶體驗”的概念適用於任何地方，但要使這個概念有足夠的吸引力和影響力，以至於可以在組織或公司內部形成這樣一個令人尊敬的部門，你首先要解決一筐的問題。無論這個團隊中是否有真正意義上的管理角色存在，用戶體驗設計的相關工作其實一直存在於整個組織中，只是在執行方式與注意力是否集中等方面，會有很大差異。組建UX團隊、樹立精神與目標並將其作為團隊核心價值焦點——這需要一個緩慢而穩健的過程，我們不能寄希望於所有的問題都能在一夜之間被解決。

　　然而，很多人都希望，正式組建起來的UX團隊可以為那些一直以來困擾著他們的問題帶來答案。其實，“用戶體驗設計”並非用來獲取答案，它應該為項目執行方式的選擇提供建議，或是為更好的設計開發流程創建架構。所以，一開始，我做了很多“傾聽”的工作，去了解各方面的問題和意見——比如參加了一些項目評審會，或是與設計師進行交流。在這些傾聽與交流的過程中，有一點我需要清楚，就是在項目的實際進程裡，到底是哪些角色對設計方案有最終決策權。我還要了解目標市場，了解有哪些潛在因素會使正確的方案在經濟上缺乏可行性;在項目中期，我還必須與IT及軟件架構等相關團隊有效配合。

　　做過傾聽與交流的工作之後，我就可以寫自己的“腳本”了：我和那些會與UX團隊密切配合的上下游團隊做了進一步的深入交流，特別是產品部以及前端開發人員;在了解了他們在項目中的實際作用和角色後，我開始從公司內部挖人……我招募到一名人機工程顧問，專門做眼動跟蹤及其他的可用性研究;從市場部搞來一名有標准化UI設計實踐經驗的實習生。有了這些人才，我們的UX團隊開始吸引人們的目光了;我們收到了越來越多的關於提升產品用戶體驗的研究需求，並且開始逐的步集約規范內部的設計流程。

　　三大職能要素：信息架構、人機工程、視覺設計

　　對於電子商務網站來說，有三個重要的方面將成為整個用戶體驗設計相關工作的支柱：信息架構、人機工程和視覺設計。正如前面所說，我已經挖到後面兩方面的相應人員了，並著手招募信息架構方面的人才。

　　我做了一個幻燈片，對相關部門進行了宣講，描述了UX團隊在補充進信息架構方面的人員之後會怎樣有效的改善設計流程。我將很多與市場需求相關的內容文案、媒體文件等作為信息碎片，向大家描述信息架構的職能是怎樣將這些重要信息通過線框圖原型有效的組織起來的;而人機工程交互設計方面，又是怎樣基於有效組織的信息架構去提升可用性，改進交互的;最後，我們的視覺設計師又是怎樣將所有這些整合起來呈現在頁面上的。

　　在招募到了信息架構師之後，我就得到了一條完整的設計角色鏈條。

　　另外，我算了筆帳，並決定再引進一名平面設計。還記得前面提到過的那個自由設計師嗎，公司付給他的薪水幾乎與全職設計師持平了，但限於兼職的性質，我們幾乎不能與他面對面溝通，這使得視覺方面的工作進度很難與新團隊的步伐保持一致。一個全職的、優秀的視覺設計師，除了在工作職能中的貢獻之外，對塑造用戶體驗設計團隊的氣質、性格和影響力等方面也會起到重要的作用。

　　改變團隊觀念

　　UX團隊的人員到位了，接下來要進入一個相對困難的階段了——改變團隊觀念。這裡所說的團隊不是指UX方面，而是整個公司內部與項目設計開發相關的組織團隊。我們需要改變的，是其他部門對於用戶體驗團隊在項目每一個階段中的產出成果的預期方式。正如前面講到的，當我剛剛赴職時，UX團隊內部的角色劃分是相當模糊的，在其他部門看來，其中任何一員都應該是全能角色。當時，視覺設計師在產品開發的每個階段都必須提供完整的“最終”視覺稿，然後其他相關部門會根據這個“原型”進行接下來的評審等流程。

　　我知道，對於其他相關部門的那些多數沒有設計經驗的人來說，要讓他們拿著一份未完成的草稿或是線框圖來進行分析和反饋，確實不是一件容易的事。但我嘗試著讓他們知道這些初稿和線框圖的價值——這些原型可以幫助整個團隊盡快完成初期設計方案及後續迭代，而不必被那些與當前階段無關的因素牽扯精力，譬如配色、元素的精確布局等。他們慢慢的明白了，線框圖並不等同於最終的視覺設計稿，它只是一種抽象，其最大的作用是幫助項目相關人員以及參與可用性測試的用戶在短時間內針對最主要的問題進行反應和回饋，而無需等待視覺設計師花費時間和資源去將大量尚未確定的元素呈現在高保真視覺稿中。

　　交互設計與可用性測試

　　正如下圖左側所示，線框圖不需要將頁面元素精確定位，不需要豐富多樣的配色，不需要看上去像任何最終稿。在進入復雜且耗時的視覺設計流程之前，我們使用線框圖進行了一些可用性測試，發現了很多潛在的障礙與缺陷，有效的避免了這些問題遺留到視覺稿中才被發現。公司曾經的做法是，將可用性測試環節放在進入開發階段之前的倒數第二部，也就是最終視覺設計流程之前;而我則將它向上游進行了推進，包括需求討論、評審等階段，因為我個人覺得可用性測試更重要的作用是告訴你哪些東西不OK，而不是哪些東西OK;越早介入，越能發現問題，而不至於到即將進入開發環節才告訴大家壞消息。

　　不僅要早，而且要盡量多的進行可用性測試。強大靈活的設計工具可以保證對原型進行迅速修改，為頻繁的測試奠定基礎。正像多數同行一樣，我們使用 Axure。在一些成功的項目中，我們使用Axure設計交互模型，直接對這些原型進行評審，驗證了很多設想中的方案，從而為後面的視覺設計流程爭取了大量時間。

　　現在，我們甚至可以在對兩個用戶進行可用性測試之後，就立刻調整和修改那些有問題的交互模型與設計元素——就在第三名測試者上手之前。當有兩名用戶在頁面上的同一個地方產生了迷惑並停止操作流程時——他們通常會說“我不知道……我不太清楚需要怎樣做才能完成這一步……”——你就應該知道這個地方一定是存在著什麼問題的。

　　在實際項目中，我們有一個小原則小手段：搞清楚誰是當前項目中最高級別的決策制定者，尤其是那些對視覺相關問題有最終決策權的人——不要將視覺稿過早的交給他們去評審，他們會對很多在設計流程初期無關大局的細節部分提出過多的意見，這會嚴重打亂設計師在流程初期的節奏。舉個例子，如果頁面裡有很多的文字內容，而設計師還沒有進行到處理這部分內容的階段，他們看到當前的設計稿，多半會說：“在這裡多做些圖標來代替文字吧!”……優秀的圖標設計其實是一項很專業的工作，它需要設計師投入大量時間;每一個圖標都必須通過全部的評審階段，並且要作為可用性測試中的專門一項，保證用戶可以全部理解。本質上說，圖標設計工作就好像是巫術——你要創造很多小巧的象形圖文，並保證他們能夠表達出正確的含義(下圖展示了設計師在制作圖標時的一些手稿)。反饋意見所來自的決策者的級別越高，你就越難把它擱置下，哪怕它會打亂你的正常流程與步驟。

　　標准化