最近一陣有些難以抑制的腦癢手癢，閱讀和碼字的欲望也漸增；卻受時間精力等絕對客觀因素所限，不得不維系一周一篇譯文的頻率，感覺多少有那麼點沮喪和無奈。
關于本文，其實在标題上猶豫了蠻久。這篇内容是新書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個人的數量剛好。
來自yingying同學的指正，thanx!
計劃籌備
選擇測試任務
我們未必可以測試到app的方方面面，在時間和各種資源條件有限的情況下，可以盡量選擇最重要的、使用最頻繁的功能，來設計測試任務。
好的任務描述文案讀起來應該更像劇情腳本，而不是簡單的引導說明；對比下面兩種風格：
- “查找一種沙爹醬的替代品”——不是非常給力。
- “今晚，有位朋友會來你家用餐，他對堅果過敏。看看有什麼方法可以相應的調整一下食譜？”——很好，具有很真實的情景感和帶入感。
記得自己先把這些任務過一遍，確定在正式開始測試之前，原型本身不會出現明顯的錯誤和問題。
制定考量标準
測試結果通常會反映出大量可用性方面的問題；量化的标準可以幫我們很直覺的比較出每輪測試之後産品在設計和功能方面的疊代成果。有以下幾方面的考量标準需要特别留意：
- 任務完成度：使用者成功的完成任務了沒？
- 完成任務的時長：使用者花了多長時間來完成任務？
- 所需的步驟：使用者在完成任務的過程裡，需要通路多少頁面，會産生多少次觸摸或點選？
- 使用者在完成任務的過程中犯了多少錯誤，嚴重程度如何？
- 使用者滿意度如何？(5分制)
選擇使用者
必須選擇“有價值”的使用者進行測試。對于烹饪類的應用來說，找那些一周多數時間裡以冷批薩為主食的使用者來參與測試，将是一件即無厘頭又坑爹的事。
可以基于早期的使用者人格與市場方面的調研來描述你希望尋找的目标使用者。尋找的範圍和方式大緻包括：
- 親朋好友以及業界相關的聯系人
- 通過你的網站或部落格釋出招募資訊
- 在社交媒體中尋找與目前産品領域相關的使用者
- 使用公告闆、郵件清單等
酬謝回饋
如果你覺得很難找到測試對象，那麼除了思考招募途徑方式以外，也可以考慮為參與測試的使用者提供一些酬謝回饋。大緻的形式包括：
- 産品推出之後優先或免費使用的特權
- 酬金
- 代金券(網購優惠券或實體票券等)
- 吃吃喝喝
選擇測試工具
有很多現成的工具服務可以對使用者測試工作起到推動和輔助作用。
Feedback Army會随機邀請一些使用者來回答你的測試任務問題，并以文本的形式進行回饋。如果你的産品閱聽人面很大，那麼這種方式還不壞，否則你将很難得到你所需要的方向性很強的回饋。
UserTesting則更加高端些，他們會幫你選擇合适的使用者群，并通過視訊記錄下使用者完成測試任務的過程，然後将結果發送給你，而且成本還算廉價。一個弊端是，他們對使用者的篩選是基于統計資料的，是以如果你希望參與測試的使用者應該是那些每周至少5天會在家做飯的人，那麼你能依靠的就隻有使用者的誠實了。另外，你也無法在測試過程中針對重要的互動環節向使用者提出具體問題。
如果你需要與使用者進行遠端交流互動，那麼螢幕錄制和分享等功能是必不可少的。Adobe ConnectNow和Skype在這方面都很給力，iShowU(Mac)和Camtasia Studio(Windows)也是不錯的選擇。
當然，最好的測試方式，還是在面對面的互動中對使用者微妙的反應進行觀察和分析。最好攝像頭和麥克風來記錄下整個會話過程，并在測試結束後使用Silverback(Mac)或Morae(Windows)這類工具回放，進行分析。
引導測試進行
在測試的當天，做好一切準備，對測試所需的軟硬體進行最後的測試。歡迎參與者的到來，對他們花時間參與測試表示感謝。
盡量讓使用者覺得輕松自在，以保證測試可以自然的進行。預先将酬勞支付給他們，避免他們會擔心“隻有正确的完成測試才能拿到報酬”。向參與者解釋清楚測試的目的，要讓他們明白真正的測試對象是app産品，而不是他們自身。告訴他們對接下來的任務盡力而為就好，完全不必顧慮是否會犯錯。
最好事先簽訂一份簡單的授權協定，告知使用者接下來的測試過程會被影音記錄，并用于今後的内部分析。要確定使用者的隐私得到充分的保護，影音資料不會被在外部公開。
最重要的一點，要鼓勵參與者大膽的思考及表述，不要擔心什麼；不過同時要讓他們知道，你不會回答任何關于怎樣使用app完成任務方面的問題。你要盡量營造出一種參與者正在獨自使用産品完成任務的情景。
作為測試的主持者，你的責任是保持客觀，認真傾聽。一開始可以設定一些簡單的任務，讓參與者可以比較從容的進入角色。切記，在布置任務和提問的過程中，要避免引導出你希望得到的答複。多對參與者進行鼓勵，給予一些非承諾性的回饋；如果他們在操作過程中犯了錯誤，首先給出一定的時間讓他們自己思考和修正，隻有在确實無法進行下去的時候再進行必要的幹預。
向使用者提問的時候，不要加入“選項”的因素。下面幾種問法比較得當：
- “你可以描述一下你正在做什麼嗎？”
- “你正在思考什麼？”
- “這和你的預期一緻嗎？”
測試之後
測試結束之後，記得要再次向參與者表示感謝；他們很有可能成為産品的第一批口碑傳播者，尤其是當他們正好屬于産品的目标使用者群的話。在測試任務全部結束後，可以讓他們對産品滿意度進行簡單的打分。
測試結束後，立刻記錄你在測試過程中洞察到的各種細節問題，越詳盡越好。即使其中一些想法是沒什麼價值的，也可以在接下來的分析過程中剔除掉。
和你的團隊一起回顧整個測試過程，對發現的問題進行歸納和總結，理清優先級，并盡快在下一輪的産品原型疊代中做出相應的改進和調整。
總結
最後，我們來歸納一下本文中關于Web應用原型設計及相關測試的内容要點：
- 列出原型所需的視覺元素，按照功能優先級排序分組。
- 使用紙和筆簡單的勾畫低保真原型。
- 對應用的關鍵界面視圖，使用輔助工具設計制作線框圖和高保真原型。
- 在邀請使用者進行原型測試之前首先進行内部測試評審。
- 在使用者測試前，充分制定好考量标準。
- 使用情景腳本風格的測試引導。
- 參與測試的使用者應該與app的目标市場有契合點。
- 對參與者給予适當的酬勞。
- 使用影音裝置記錄下測試過程。
- 作為測試的主持者，要保持客觀，在布置任務和提問的過程中，避免引導性的問題。
- 測試結束後立刻記錄過程中發現的問題，及時分析測試結果，對原型進行疊代。