產品早期的原型設計與用戶測試
最近一陣有些難以抑制的腦癢手癢，閱讀和碼字的慾望也漸增;卻受時間精力等絕對客觀因素所限，不得不維繫一週一篇譯文的頻率，感覺多少有那麼點沮喪和無奈。
關於本文，其實在標題上猶豫了蠻久。這篇內容是新書A Practical Guide to Web App Success的第15章;主題顯然應該在Web應用方面，但是本章單獨拎出來看的話，卻又適用於各種常見類型的Web產品。whatever，不矛盾。 作者Dan Zambonini在本文中將向我們闡述Web應用在原型階段的設計與測試工作的重要性，並從實際執行的角度出發，介紹一些經驗方法和常用工具。走著。
產品在原型階段的設計與測試工作，是決定一款移動應用能否成功的重要因素。提到原型設計和用戶測試，人們往往容易產生厭倦與迴避的感覺。這也不奇怪，在很多實際項目中，這方面的工作似乎就是「隨意性強」，「耗時」，「高成本」一類的代名詞。
不過在我看來，它們其實是整個設計流程裡最重要的環節。無論你或你的團隊在用戶界面視覺設計等方面有多高的造詣，我都建議各位對原型環節的相關工作提 高重視。基於高保真原型的用戶測試，可以讓很多關於需求、功能、界面設計等方面的潛在問題儘早暴露出來;這類問題往往直接關乎著產品的成敗。
另外，原型階段的工作非但不代表「耗時」與「高成本」，實際上正相反。從整個項目的角度講，在原型的設計與測試過程中發現問題並加以解決，比將問題留到視覺設計和開發流程中再處理，要省時省力的多。
原型設計
原型設計工作需要相關人員具備交互設計、構圖、網格系統、風格繼承等方面的知識技能。如果你在一個小團隊內工作，儘量讓相關同事也參與到原型設計的工 作中，從每個職能角度提出意見和建議。如果你們在為客戶開發移動應用，那麼在這個階段要與他們儘可能多的進行需求溝通，保證及時有效的反饋與迭代。
不過有一點需要注意，在參與原型設計的人員範圍方面要做好把握。參與者應該包括與產品功能決策相關的產品及設計等上下游職能人員。我在實際項目中碰到 過很多次這樣的情況，就是開發部門的技術人員在原型設計階段進行了過多的介入，除了常規的技術評審之外，還提出了很多以技術開發為中心的原型設計建議，這 顯然是本末倒置的。
1.選擇最重要的視圖界面
如果你有足夠多的時間及技術資源去為每個視圖界面都創建對應的線框原型，這也不壞。不過通常情況下，你只需要搞幾個最重要的、最具代表性的界面就OK了;其他多數可以通過同一張原型圖去代表。
舉例說，Twitter和Facebook的首頁動態與用戶個人界面在形式上是很相似的，用一個原型就可以解決了。對這兩個應用來說，真正必要的關鍵視圖界面原型只有大約4個的樣子，包括用戶註冊、動態列表、用戶搜索和用戶搜索結果等。
對於「最小可用產品」(Minimum Viable Product,MVP)，那麼4到5個關鍵屏已經足夠多了。在後續的功能開發和迭代的過程中，可以再繼續為那些相對獨立的、非最簡化核心的功能界面設計新的原型。
2.列出視覺元素
接下來，列出所有需要用到的視覺元素，包括文本、按鈕、表單、圖形、菜單等;不要忘記那些默認不會顯示出來的元素，比如警告和出錯信息、狀態提示、操作反饋等。對於簡單的項目，使用紙和筆來完成這步工作就夠了。
由於這些UI元素是需要被覆用的，所以在使用它們構建原型的時候，我們可以從最重要的視圖界面入手，也就是包含了最多內容結構和功能的、用戶會花很多時間進行瀏覽和操作的界面。這樣可以儘早確保UI元素的功能合理性。
回到我們的烹調app上(貫穿本書前幾章的演示案例)，從「最小可用產品」的角度，我們只需要一個主要功能：查找食材。在主界面中，包含的視覺元素及模塊大致有：
●搜索框
●搜索失敗的提示
●熱門搜索關鍵詞
●隨用戶輸入而顯示的搜索建議
●飲食分類，包括素食、健康、低糖等
●app的功能服務簡述
●添加食材的入口鏈接
●用戶的最近搜索關鍵詞
●logo
3.將視覺元素分組並進行優先級排序
從功能及內容的角度，將上面列表中的元素條目進行分組，並按照優先級從高到低的順序排列：
●搜索框、搜索失敗提示、搜索建議
●熱門關鍵詞、飲食分類、最近搜索關鍵詞
●logo、app的功能服務簡述
●添加食材的入口鏈接
對於最簡化可實行產品來說，分組和排序的工作會很容易進行。如果app的功能比較複雜，視覺元素和模塊過多，你可以嘗試卡片排序的方式。將每個元素條 目寫在卡片上，使形式更加實體化、獨立化，便於操作。讓團隊相關人員參與進來，徵詢分組建議，最終達成一種統一的模式。
4.為每組視覺元素製作低保真原型
草圖時間，開始動手吧。低保真階段，不需要任何藝術美化方面的因素介入。
不必介意能否一開始就把所有元素畫的得當和到位，這是一個創作的過程，完全可以多嘗試嘗試你頭腦中不同的方案。而且我們之前的分組方案也不是絕對的， 在製作草稿的過程裡，如果你覺得最近「搜索關鍵詞」在邏輯上與搜索框更加貼近，那麼就修改一下分組，沒問題。要記得，在原型設計的整個過程裡，我們有一個 大原則，就是讓迭代與更新發生的儘量早些。
目前還不用考慮各元素在「一致性」方面的問題，不必為他們之間的位置和尺寸關係牽扯精力;現在我們只要關注每個元素獨立的個體。
5.線框圖
是時候把這些UI元素的低保真原型撮合到線框原型中了;不要忘記我們之前對它們進行分組時的優先級排序。在這期間仍然會頻繁的發生迭代，所以不必過多 考慮精確的網格對齊、配色或字體一類。線框原型的設計製作過程，就是評估UI元素之間的平衡性、優先級和互動關係的過程。(可以參考閱讀我們之前關於線框 原型的本質及實踐應用方面的文章)
在之前的低保真原型階段，紙和筆就足夠了;但是在線框原型的製作過程中，我們通常需要對模塊化、可復用的UI元素集合進行佈局規劃和調整。這時，我們可以使用一些工具來提高效率;試試看下面這些：
便簽貼紙
恩，最基本的方法，並且仍然沒有脫離紙筆，但不失靈活性與可行性。在每張便簽貼紙上畫一個UI元素，或是一組已經模塊化的UI元素集合，根據需求隨意調整組合方案及佈局位置。如果某元素或模塊本身需要調整，重新畫一枚即可，無需調整全局。
PowerPoint(PPT)或Keynote
首先說明，我個人很討厭使用此類作演示用的軟件工具進行設計方面的工作，不過必須承認，在快速草圖和分組歸類設計元素等方面，它們還算好用。
Google文檔的繪圖工具
Google文檔工具套裝中的繪圖應用也不錯。雖然它並非專為Web設計而打造，但它的基本功能可以滿足我們製作線框圖的需求，而且遠程多人協作等方面的功能特色也相當實用。
獨立Web應用
可以試試那些專門用來製作線框圖的基於瀏覽器的Web應用。有的還不錯，比如Mockingbird，很容易上手，基本功能一應俱全。Pencil Project也是一個選擇，它是一款Firefox擴展。
桌面應用軟件
Balsamiq Mockups是一款不錯的線框原型設計工具，它是商業軟件。當然，如果你已經有Microsoft Visio或是OmniGraffle的話，也可以使用它們提供的網頁線框模板。
我個人比較喜歡那些提供了低保真草圖風格的軟件，這種風格的線框圖可以顯得更加原始和自然，避免摻雜過多的視覺美化方面的因素。下圖左側為手繪草圖，右側為OmniGraffle的線框原型輸出。
對於以上幾種類型的工具，我傾向於Web應用或是桌面應用軟件，因為它們多數都內置了很全面的GUI組件庫。
低保真原型可以用於產品相關部門內部進行小規模的評審和測試。
6.高保真原型
該創建用於測試的高保真原型了。雖然高保真原型中的界面在接下來的流程中還需要被多次迭代，但是目前我們已經可以儘量加入視覺風格及涉及用戶體驗的相關要素了。
高保真原型通常分為兩類，一類是可以通過Photoshop、Fireworks等設計工具來創建的圖片文件，純粹用以展示界面效果。另外一類是真正 意義上的交互原型。在使用高保真交互原型進行測試的過程中，不必加入人工解說或行為路徑引導，對於被測試者來說，體驗更加流暢，操作感更接近於實際產品。
高保真原型的交互功能並不需要基於真正生產級別的代碼，我們只要保證頁面元素可以根據用戶行為進行必要的反饋即可。這種反饋可以通過硬編碼或腳本來實現。
通常，我們可以通過以下幾種方法來創建高保真交互原型：
●將界面效果圖嵌入HTML，通過map和area標籤，在圖片上添加熱點鏈接，用以響應用戶的點擊。
●使用Photoshop或Fireworks將界面效果圖快速切片，並直接生成HTML靜態頁面，實現簡單的響應功能。
●如果你的前端能力OK，手頭夠快，不妨代碼伺候，直接上HTML、CSS、JavaScript，或使用Blueprint CSS和IxEdit這樣的前端框架。
●使用更專業的原型工具軟件，如Axure RP或Serena Prototype Composer等，創建原型並導出成為可交互的頁面集合。
●最後一種，希望不會與你的價值觀產生衝突...我們可以直接使用Dreamweaver、Microsoft Expression Web或Adobe Muse等軟件的所見即所得(WYSIWYG)設計模式來快速創建原型。反正目的在於快速製作並測試原型的交互方式;再說高保真原型的代碼通常也不會被用 作接下來的前端或後台開發。
用戶測試
通過用戶測試，我們可以直接和有效的洞察到產品在用戶行為、界面可用性、用戶期望與功能契合程度等方面的表現。本文所側重的原型階段的測試，更是可以幫助我們在項目初期就能達到以下幾方面的目標：
●在產品進入開發流程之前，發現並解決那些需求和功能設計合理性方面的問題。
●辨識並去除那些多餘的功能，節省接下來的開發成本。
●儘早發現結構佈局和交互方式等方面的問題，在接下來的迭代過程中，有針對性的優化用戶體驗，提升最終產品的用戶滿意度，推動產品在市場中口碑的樹立。
用戶測試的大致方式及流程其實並不複雜：選擇合適的用戶作為測試對象，向他們提出一系列需要使用app原型來完成的目標，記錄他們的行為及口頭陳述反饋。需要花些時間和心思去琢磨的的是整個測試工作的計劃與執行過程中的細節問題。
當然，你可以僱用那些可用性測試方面的專業代理，由他們打包搞定所有的問題，比如用戶選擇、任務設計、會話時長的規劃、調查結果分析等;只要你的團隊有足夠多的經費預算用來支付外包費用。
幸運的是，有一些實踐性強、成本低廉的方法和原則可供我們參考借鑑，自己解決問題。另外，雖然多數的第三方代理在專業水準方面值得信賴(並且價格昂 貴)，但他們畢竟無法像我們自己一樣可以從頭到尾的瞭解我們的產品和需求，他們最終提供的分析報告往往無法達到能夠指引我們立刻採取反應措施的程度。
測試規模
每輪會話的時常最好不要超過45分鐘，目標任務保持在5個以內;否則，疲勞因素會導致用戶希望結束測試，進而影響其行為。
如果測試會持續一整天，那麼每輪測試會話之間要留有20到30分鐘的間隔，讓你和團隊相關人員有時間對前一輪的測試情況進行討論。
參與測試的用戶數量取決於你的應用產品的規模級別。對於一些最小可用產品的原型，測試用戶的行為上有很強的關聯性，重要的問題基本都可以在前面兩輪測 試中很清楚的呈現出來。對於複雜的應用，test subjects are more likely to identify unique issues, with diminishing returns as the total number of test users increases.Jakob Nielsen suggests that five users offer the best insight before diminishing returns kick in significantly.(「...隨著測試用戶數量的增多而產生收益遞減的現象。Jakob Nielsen建議，在收益遞減的效應變的顯著之前，5名測試用戶可以帶來最好的測試效果。」 不敢斷譯，求各位觀眾的幫助和指正。)
對於複雜的應用，
由於每位用戶在測試中都可以有她獨特的發現，那麼隨著用戶數量的增加，這種獨特性會降低，重複的發現會增加，這樣我們花的時間，金錢和精力就用在發掘重複的issue上了，這不是理想的效果，經過研究5個人的數量剛好。
計劃籌備
選擇測試任務
我們未必可以測試到app的方方面面，在時間和各種資源條件有限的情況下，可以儘量選擇最重要的、使用最頻繁的功能，來設計測試任務。
好的任務描述文案讀起來應該更像劇情腳本，而不是簡單的引導說明;對比下面兩種風格：
●「查找一種沙爹醬的替代品」——不是非常給力。
●「今晚，有位朋友會來你家用餐，他對堅果過敏。看看有什麼方法可以相應的調整一下食譜?」——很好，具有很真實的情景感和帶入感。
記得自己先把這些任務過一遍，確保在正式開始測試之前，原型本身不會出現明顯的錯誤和問題。
制定考量標準
測試結果通常會反映出大量可用性方面的問題;量化的標準可以幫我們很直觀的比較出每輪測試之後產品在設計和功能方面的迭代成果。有以下幾方面的考量標準需要特別留意：
●任務完成度：用戶成功的完成任務了沒?
●完成任務的時長：用戶花了多長時間來完成任務?
●所需的步驟：用戶在完成任務的過程裡，需要訪問多少頁面，會產生多少次觸摸或點擊?
●用戶在完成任務的過程中犯了多少錯誤，嚴重程度如何?
●用戶滿意度如何?(5分制)
選擇用戶
必須選擇「有價值」的用戶進行測試。對於烹飪類的應用來說，找那些一週多數時間裡以冷批薩為主食的用戶來參與測試，將是一件即無厘頭又坑爹的事。
可以基於早期的用戶人格與市場方面的調研來描述你希望尋找的目標用戶。尋找的範圍和方式大致包括：
●親朋好友以及業界相關的聯繫人
●通過你的網站或博客發佈招募信息
●在社交媒體中尋找與當前產品領域相關的用戶
●使用公告板、郵件列表等
酬謝回饋
如果你覺得很難找到測試對象，那麼除了思考招募途徑方式以外，也可以考慮為參與測試的用戶提供一些酬謝回饋。大致的形式包括：
●產品推出之後優先或免費使用的特權
●酬金
●代金券(網購優惠券或實體票券等)
●吃吃喝喝
選擇測試工具
有很多現成的工具服務可以對用戶測試工作起到推動和輔助作用。
Feedback Army會隨機邀請一些用戶來回答你的測試任務問題，並以文本的形式進行回饋。如果你的產品受眾面很大，那麼這種方式還不壞，否則你將很難得到你所需要的方向性很強的回饋。
UserTesting則更加高端些，他們會幫你選擇合適的用戶群，並通過視頻記錄下用戶完成測試任務的過程，然後將結果發送給你，而且成本還算廉 價。一個弊端是，他們對用戶的篩選是基於統計數據的，所以如果你希望參與測試的用戶應該是那些每週至少5天會在家做飯的人，那麼你能依靠的就只有用戶的誠 實了。另外，你也無法在測試過程中針對重要的交互環節向用戶提出具體問題。
如果你需要與用戶進行遠程交流互動，那麼屏幕錄製和分享等功能是必不可少的。Adobe ConnectNow和Skype在這方面都很給力，iShowU(Mac)和Camtasia Studio(Windows)也是不錯的選擇。
當然，最好的測試方式，還是在面對面的互動中對用戶微妙的反應進行觀察和分析。最好攝像頭和麥克風來記錄下整個會話過程，並在測試結束後使用Silverback(Mac)或Morae(Windows)這類工具回放，進行分析。
引導測試進行
在測試的當天，做好一切準備，對測試所需的軟硬件進行最後的測試。歡迎參與者的到來，對他們花時間參與測試表示感謝。
儘量讓用戶覺得輕鬆自在，以保證測試可以自然的進行。預先將酬勞支付給他們，避免他們會擔心「只有正確的完成測試才能拿到報酬」。向參與者解釋清楚測 試的目的，要讓他們明白真正的測試對象是app產品，而不是他們自身。告訴他們對接下來的任務盡力而為就好，完全不必顧慮是否會犯錯。
最好事先簽訂一份簡單的授權協議，告知用戶接下來的測試過程會被影音記錄，並用於今後的內部分析。要確保用戶的隱私得到充分的保護，影音資料不會被在外部公開。
最重要的一點，要鼓勵參與者大膽的思考及表述，不要擔心什麼;不過同時要讓他們知道，你不會回答任何關於怎樣使用app完成任務方面的問題。你要儘量營造出一種參與者正在獨自使用產品完成任務的情景。
作為測試的主持者，你的責任是保持客觀，認真傾聽。一開始可以設置一些簡單的任務，讓參與者可以比較從容的進入角色。切記，在佈置任務和提問的過程 中，要避免引導出你希望得到的答覆。多對參與者進行鼓勵，給予一些非承諾性的回饋;如果他們在操作過程中犯了錯誤，首先給出一定的時間讓他們自己思考和修 正，只有在確實無法進行下去的時候再進行必要的干預。
向用戶提問的時候，不要加入「選項」的因素。下面幾種問法比較得當：
●「你可以描述一下你正在做什麼嗎?」
●「你正在思考什麼?」
●「這和你的預期一致嗎?」
測試之後
測試結束之後，記得要再次向參與者表示感謝;他們很有可能成為產品的第一批口碑傳播者，尤其是當他們正好屬於產品的目標用戶群的話。在測試任務全部結束後，可以讓他們對產品滿意度進行簡單的打分。
測試結束後，立刻記錄你在測試過程中洞察到的各種細節問題，越詳盡越好。即使其中一些想法是沒什麼價值的，也可以在接下來的分析過程中剔除掉。
和你的團隊一起回顧整個測試過程，對發現的問題進行歸納和總結，理清優先級，並盡快在下一輪的產品原型迭代中做出相應的改進和調整。
總結
最後，我們來歸納一下本文中關於Web應用原型設計及相關測試的內容要點：
●列出原型所需的視覺元素，按照功能優先級排序分組。
●使用紙和筆簡單的勾畫低保真原型。
●對應用的關鍵界面視圖，使用輔助工具設計製作線框圖和高保真原型。
●在邀請用戶進行原型測試之前首先進行內部測試評審。
●在用戶測試前，充分制定好考量標準。
●使用情景腳本風格的測試引導。
●參與測試的用戶應該與app的目標市場有契合點。
●對參與者給予適當的酬勞。
●使用影音設備記錄下測試過程。
●作為測試的主持者，要保持客觀，在佈置任務和提問的過程中，避免引導性的問題。
●測試結束後立刻記錄過程中發現的問題，及時分析測試結果，對原型進行迭代。
本文來自Be For Web