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

 

方面。廢話不多說，走著。

 

        多數時候，新的方式方法不會被很容易的付諸實踐。特別是在舊有習慣已經根深蒂固的情況下，前行過程中 的每一個階段，在參與者看來，都好像是一種很新奇的玩意兒。不是所有人都喜歡新鮮事物，但是作為確切目標的執行者，大家必須學會新的思維方式與實踐方法， 并貫徹到實際工作中。
在本文中，我(英文原文作者)將以公司網站的改版項目作為思路梗概，進行工作的回顧總結，并分析我們的團隊是怎樣在整個改版過程中步步為營的貫徹用戶體驗設計思路的。下面的插圖展示了改版前后兩個版本之間的顯著變化。
 
UX設計團隊(UED)組建伊始

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

        改變團隊觀念

 

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

 

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

 

        交互設計與可用性測試

 

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

        不 僅要早，而且要盡量多的進行可用性測試。強大靈活的設計工具可以保證對原型進行迅速修改，為頻繁的測試奠定基礎。正像多數同行一樣，我們使用Axure。 在一些成功的項目中，我們使用Axure設計交互模型，直接對這些原型進行評審，驗證了很多設想中的方案，從而為后面的視覺設計流程爭取了大量時間。
現 在，我們甚至可以在對兩個用戶進行可用性測試之后，就立刻調整和修改那些有問題的交互模型與設計元素——就在第三名測試者上手之前。當有兩名用戶在頁面上 的同一個地方產生了迷惑并停止操作流程時——他們通常會說“我不知道…我不太清楚需要怎樣做才能完成這一步…”——你就應該知道這個地方一定是存 在著什么問題的。

 

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

 

        標準化
        創建了風格化的線框圖原型，謹慎的使用紙質原型——甚至在產品經理還在完善需求文檔的時候，我們就已經一步一個腳印的取得了一些小成果。用戶體驗設 計的相關工作在項目早期就介入進來是很重要的，否則，你就很可能必須沿著錯誤的早期規劃路線進行跟進，更有甚者，產品部門甚至是開發人員會交給你一份他們 自己做的、“已經通過評審和確認”的設計原型要你去跟進，縱使這些原型在多數時候根本沒有可取之處，縱使你拿著設計指南與UI規范向他們指出錯誤。
所以我們在項目任務之外，還花了不少時間去編寫原型文檔；你至少可以用這些規范來向相關部門的人員解釋一些標準化模型的功能和流程，讓他們知道不需要重新發明輪子。

 

        從 整個產品的角度來看，初期，你也許需要從UX團隊中劃分出一小部分資源，去協助一些“低價值”項目，使功能盡快上線；而團隊的主要精力，將集中放在接下來 的優化與迭代的過程里，比如將全站的UI元素進行風格統一化。具有一定規模的網站中，通常會有這樣的情況：不同頁面的表單會有不同的設計，雖然他們的功能 基本一致，但往往會發生表單項順序不一致、字體規則和對齊方案不一致等等的現象；對于需要跨越幾個頁面的表單操作流程，有時相同的商品在不同頁面中的信息 呈現方式也不一致。更不用說那些正處于改版狀態的網站，新舊風格往往會混雜在同一個頁面中。我們需要花時間處理這些問題，設計出全局化統一化的UI組件和 模塊模型，使用戶在不同頁面的操作體驗保持一致。

 

        UI設計規范
        在我們著手對頁面UI進行統一化的過程里，一個大項目順水推舟的介入了進來——全站的視覺改版。這是個好事，我們可以在這個大項目里完善UI設計規范，還可以同時基于網站的UI風格進行企業識別(CI)方面的設計工作(什么是企業識別 / CI)。說到CI，其實可以外包給其他設計代理公司，但是我們覺得他們未必可以很好的挖掘公司品牌深層的本質，況且這筆開銷也不小，所以還是自力更生了。 后，我們將統一化的UI元素設計模式與新的CI標準文檔整合了起來，包括配色方案、模板參考、圖標選擇等方面。
 

 

        規 范中，有一篇文檔涵蓋了很多技術細節，其中我們不必自己撰寫全部的內容，有很多實施要則是鏈接到相關的wiki頁面的。我們的規范可以幫助我們有據可循的 向相關協作部門展示各種設計方案的道理，這些可以幫助我們逐步產生影響力，傳播我們的用戶體驗設計理念與執行方式，使我們的團隊可以越來越多的在新項目初 期就介入其中發揮作用。

 

        作為UX團隊，我們并沒有在項目中壟斷設計思路，我會邀請項目中其他相關部門的同事按照我們提供的一些游戲規則去從他們的職能角度思考贗品用戶體驗方面的問題。