來源：beforweb
最近一陣有些難以抑制的腦癢手癢，閱讀和碼字的慾望也漸增；卻受時間精力等絕對客觀因素所限，不得不維繫一週一篇譯文的頻率，感覺多少有那麼點沮喪和無奈。
關於本文，其實在標題上猶豫了蠻久。這篇內容是新書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的目標市場有契合點。
對參與者給予適當的酬勞。
使用影音裝置記錄下測試過程。
作為測試的主持者，要保持客觀，在佈置任務和提問的過程中，避免引導性的問題。
測試結束後立刻記錄過程中發現的問題，及時分析測試結果，對原型進行迭代。