第1頁挑選最次要的視圖界面
最近一陣有些難以抑止的腦癢手癢，閱讀和碼字的愿望也漸增;卻受工夫精神等絕對客觀要素所限，不得不維系一周一篇譯文的頻次，覺得幾有那么點懊喪和無法。
關于本文，真實在標題上猶疑了蠻久。這篇形式是舊書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的話，也可以運用它們提供的網頁線框模板。
第2頁高保真原型
我團體比擬喜愛那些提供了低保真草圖作風的軟件，這種作風的線框圖可以顯得愈加原始和天然，防止摻雜過多的視覺丑化方面的要素。下圖左側為手繪草圖，右側為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名測試用戶可以帶來最好的測試成效。” 不敢斷譯，求各位觀眾的協助和指正。)
/*——————–更新 2011-12-04 17:26——————–*/
關于繁雜的使用，
由于每位用戶在測試中都可以有她共同的發覺，那么隨著用戶數手段添加，這種共同性會升高，反復的發覺會添加，這樣我們花的工夫，金錢和精神就用在開掘反復的issue上了，這不是幻想的成效，經過研討5團體的數目恰好。
來自yingying同窗的指正，thanx!
/*——————–/更新 2011-12-04 17:26——————–*/
方案準備
挑選測試義務
我們一定可以測試到app的方方面面，在工夫和各種資源條件無限的狀況下，可以盡量挑選最次要的、運用最屢次的功用，來設想測試義務。
好的義務描繪文案讀起來該當更像劇情腳本，而不是繁雜的指導闡明;比照下面兩種作風：
“查找一種沙爹醬的替換品”——不是十分給力。
“今晚，有位冤家會來你家用餐，他對堅果過敏。看看有什么辦法可以相應的調整一下食譜？”——很好，具有很真實的情形感和帶入感。
記得本人先把這些義務過一遍，確保在正式開端測試之前，原型本身不會出現分明的過失和題目。
制定考量規范
測試后果一般會反映出少量可用性方面的題目;量化的規范可以幫我們很直觀的比擬出每輪測試之后產品在設想和功用方面的迭代效果。有以下幾方面的考量規范需求特地留意：
義務完成度：用戶勝利的完成義務了沒？
完成義務的時長：用戶花了多長工夫來完成義務？
所需的方法：用戶在完成義務的進程里，需求拜訪幾頁面，會發作幾次觸摸或點擊？
用戶在完成義務的進程中犯了幾過失，嚴峻水平如何？
用戶滿意度如何？(5分制)
挑選用戶
必需挑選“有價值”的用戶停止測試。關于烹飪類的使用來說，找那些一周少數工夫里以冷批薩為主食的用戶來參與測試，將是一件即無厘頭又坑爹的事。
可以基于晚期的用戶人格與市場方面的調研來描繪你希冀尋覓的手段用戶。尋覓的范疇和方式大致包括：
親朋好友以及業界相關的聯絡人
經過你的網站或博客公布招募消-息
在社交媒體中尋覓與以后產品范疇相關的用戶
運用公-告板、郵件列表等
酬報回饋
假如你覺得很難找到測試對象，那么除了思索招募道路方式以外，也可以思索為參與測試的用戶提供一些酬報回饋。大致的方式包括：
產品推出之后優先或收費運用的特權
酬金
代金券(網購優惠券或實體票券等)
吃吃喝喝
挑選測試工具
有很多現成的工具效勞可以對用戶測試任務起到推進和輔佐作用。
Feedback Army會隨機約請一些用戶來回答你的測試義務題目，并以文本的方式停止回饋。假如你的產品受眾面很大，那么這種方式還不壞，否則你將很難失掉你所需求的方向性很強的回饋。
UserTesting則愈加高端些，他們會幫你挑選適宜的用戶群，并經過視頻記載下用戶完成測試義務的進程，然后將后果發送給你，而且本錢還算低價。一個弊端是，他們對用戶的挑選是基于統計數據的，所以假如你希冀參與測試的用戶該當是那些每周至多5天會在家做飯的人，那么你能依托的就只需用戶的老實了。另外，你也無法在測試進程中針對次要的交互環節向用戶提出詳細題目。
假如你需求與用戶停止近程交換互動，那么屏幕錄制和分享等功用是必不可少的。Adobe ConnectNow和Skype在這方面都很給力，iShowU(Mac)和Camtasia Studio(Windows)也是不錯的挑選。
當然，最好的測試方式，還是在面對面的互動中對用戶奇妙的反響停止察看和剖析。最好攝像頭和麥克風來記載下整個會話進程，并在測試完畢后運用Silverback(Mac)或Morae(Windows)這類工具回放，停止剖析。
指導測試停止
在測試確當天，做好一切預備，對測試所需的軟硬件停止最初的測試。歡送參與者的到來，對他們花工夫參與測試表示感激。
盡量讓用戶覺得緊張安閑，以保證測試可以天然的停止。事后將酬勞領取給他們，防止他們會擔憂“只需準確的完成測試才干拿到報酬”。向參與者注釋分明測試的手段，要讓他們清楚真正的測試對象是app產品，而不是他們本身。通-知他們對接上去的義務不遺余力就好，完整不必顧忌能否會出錯。
最壞事前簽署一份繁雜的受權協議，告知用戶接上去的測試進程會被影音記載，并用于今后的內部剖析。要確保用戶的隱私失掉充沛的維護，影音材料不會被在內部公然。
最次要的一點，要鼓舞參與者大膽的思索及表述，不要擔憂什么;不過同時要讓他們曉得，你不會回答任何關于怎樣運用app完成義務方面的題目。你要盡量營建出一種參與者正在獨自運用產品完成義務的情形。
作為測試的掌管者，你的義務是堅持客觀，仔細聆聽。一開端可以設置一些繁雜的義務，讓參與者可以比擬沉著的進入角色。切記，在安排義務和發問的進程中，要防止指導出你希冀失掉的回答。多對參與者停止鼓舞，索取一些非許諾性的回饋;假如他們在操縱進程中犯了過失，首先給出必定的工夫讓他們本人思索和改正，只需在的確無法停止上去的時分再停止必要的干涉。
向用戶發問的時分，不要參加“選項”的要素。下面幾種問法比擬妥當：
“你可以描繪一下你正在做什么嗎？”
“你正在思索什么？”
“這和你的預期分歧嗎？”
測試之后
測試完畢之后，記得要再次向參與者表示感激;他們很有可以成為產品的第一批口碑傳達者，特地是當他們正好屬于產品的手段用戶群的話。在測試義務局部完畢后，可以讓他們對產品滿意度停止繁雜的打分。
測試完畢后，立即記載你在測試進程中洞察到的各種細節題目，越詳細越好。即便其中一些想法是沒什么價值的，也可以在接上去的剖析進程中剔除掉。
和你的團隊一同回憶整個測試進程，對發覺的題目停止歸結和總結，理清優先級，并盡快在下一輪的產品原型迭代中做出相應的改良和調整。
總結
最初，我們來歸結一下本文中關于Web使用原型設想及相關測試的形式要點：
列出原型所需的視覺元素，依照功用優先級排序分組。
運用紙和筆繁雜的勾勒低保真原型。
對使用的關鍵界面視圖，運用輔佐工具設想制造線框圖和高保真原型。
在約請用戶停止原型測試之前首先停止內部測試評審。
在用戶測試前，充沛制定好考量規范。
運用情形腳本作風的測試指導。
參與測試的用戶該當與app的手段市場有符合點。
對參與者索取恰當的酬勞。
運用影音裝備記載下測試進程。
作為測試的掌管者，要堅持客觀，在安排義務和發問的進程中，防止指導性的題目。
測試完畢后立即記載進程中發覺的題目，及時剖析測試后果，對原型停止迭代。
(本文根源：天極網 )
網頁設計
