本文介紹了產品的易學性對那些日常被使用的界面設計是多麼重要，以及如何進行產品的易學性的測試。
易學性是產品易用性的五大衡量維度之一（其餘維度包括產品的使用效率、記憶難度、容錯性和滿意度）。對於需要用戶頻繁使用的相對複雜的產品或系統而言，測試界面的學習難度顯得尤為重要。當然，對於相對簡單的系統而言，了解用戶能多快地適應界面也是有價值的。
產品的易學性描述了用戶首次完成界面操作的難度，以及熟練掌握該操作所花費的重複次數。
通常進行易學性測試時，我們將繪製一張能夠揭示用戶行為量化後縱向變化的折線圖。通過觀測數據的縱向變化，我們可以知道用戶在多久後到達了學習飽和，之後的平臺期意味著此時此刻用戶已儘可能地學會了如何使用當前界面的功能。
假設我們要重新設計一個供企業IT網管日常使用的文件備份系統，同時知道他會在日常工作中循序漸進地學會系統的操作流程。
對於這樣一個系統，用戶能夠儘快完成工作是很非常重要的。
在這樣的預設條件下，易學性衡量的就是IT網管要高效熟練地操作這套系統所需要的時間。
首先我們會邀請一些有代表性的潛在用戶參與這項實驗，然後記錄他們首次操作備份任務所需要的時間。之後我們將再次邀請他們回來重複操作這個備份任務，並同樣記錄下時間。我們會反覆進行數次同樣測試，繪製出在一系列實驗中完成任務的時間，形成一條學習曲線。
圖一 該學習曲線展示了備份任務測試的序列和每次測試的耗時的關係假說。可見操作耗時在第一次測試時最長，由此遞減至第四次測試時，耗時趨於穩定。儘管具體情況（例如需要重複多少次）會因情況而異，，但這樣的學習曲線也能夠較為直觀的展示人類學習行為和接受過程。
易學性可以分解為三個維度，每個維度都對用戶非常重要。
用戶在第一次使用時操作好多容易？第一印象對那些用完就走的用戶特別重要，他們不在乎學習曲線，不在乎產品長什麼樣，如果第一次操作不夠簡單，那麼這些用戶大概率已經流失了。
用戶能夠多快地在重複使用中表現地更好？學習速率對於那些即使不會過度但需要重複使用該產品的用戶特別重要，如果用戶逐漸發現自己對這款產品使用的得心應手，會有一定的成就感有一直用下去。（反之，如果用戶發現這款產品越用越難，不論他們付出了多大的成本，都會開始找更好的解決方案。）
當用戶熟練使用這款產品時，他能提升工作效率的天花板在哪？效率飽和點對於那些要長期、高頻使用這款產品的用戶而言顯得重要，例如需要每天使用的重要工具。
理想化的情況是你的產品在這三方面表現都不錯。但是在現實場景下，產品設計的過程總會有需要取捨之處，設計師應該設計出符合最具商業價值用戶學習曲線的產品。易學性三個維度的重要性也和用戶的生命周期有著必然關係。新用戶想要儘快學會操作這個產品並儘快達到最優表現，而專家用戶希望這款產品的學習飽和狀態儘可能滴（即最優的任務完成儘可能短）。
有時候易學性的這些不同屬性可能導致產品設計走向不同的方向。
例如，一個簡單易學的系統不一定是高效的。回到之前的例子，我們假設備份任務是採用步驟分離的wizard流程進行的，操作過程中的每一步會有說明和解釋。這個系統比較容易學習和上手，用戶第一次使用就能較快地完成所有操作。
但是這就造成了學習曲線變得極為平緩，用戶再次進行操作時，依然要經過同樣的界面回答同樣的問題，無法大幅提升操作速度。
如果用戶對界面及操作已經非常熟悉，這種設計便顯得格外累贅，在重複使用時效率低下。（因此，考慮到專家用戶的操作便捷，我們推薦加入「加速器」交互，例如快捷鍵、跳過進程等操作）設計師必須仔細權衡易學性和操作效率，找到合適的平衡點。
圖二
該學習曲線展示了採用步驟分離的wizard流程設計的備份任務測試的序列和每次測試的關係假說。圖表顯示不論是第幾次進行的操作，耗時都在16分鐘左右，可見這是一個簡單易學但不夠高效的系統。
易學性與易用性息息相關。高易學性能夠帶來快速的系統引導流程和較低的訓練成本。此外，高易學性的產品能夠讓用戶感到自信，並因此提高用戶滿意度。
如果你的系統及相關操作比較複雜，用戶使用頻次較高，那麼對該產品進行一次易學性測試是個不錯的選擇。易學性測試對時間和預算的要求較高，所以在和老闆建議測試之前一定要做好充分的準備。對於那些使用頻次不高，或者用完就走的產品而言，易學性測試的商業價值就比較有限，這些產品被重複使用時依然會被用戶當作新產品來對待。因此對這些產品而言，一次標準的易用性測試會比易學性測試性價比高得多。
易學性測試的核心是收集度量指標，所以我們要使用定量研究法。這種測試要求有焦點任務和受控實驗，所以定量可用性測試是實施易學性測試的最佳方法。
進行這項測試的目的是衡量學會某一界面操作對用戶的難易程度。所以我們尋找的實驗對象必須對該系統沒有任何使用經驗或極少的使用經驗。
對於易學性測試，我們往往要考慮到實驗對象對類似系統的使用經驗。類似系統的使用經驗可能讓他們更快速的上手（例如他們早已熟悉類似的約定域），也可能讓他們卡在某個步驟（比如和之前類似作業系統的交互完全不一樣）。即便如此，測試結果數據依然很有價值，特別要發布的產品需要從現有市場的其他同類產品中獲取用戶時。在實施測試時，可以分別招募無經驗和有類似產品使用經驗的實驗對象，再將兩組實驗對象的數據進行對比和分析。
對於任何定量研究，我們都建議你招募較多實驗對象（通常最少30-40）。具體人數需要根據系統的複雜程度而定，產品越複雜，所需要的實驗對象人數越多以解決內在的數據變化程度，反之則越少。
任務耗時是易學性測試最常見的衡量維度。學習冪定律(The power law of learning)指出，任務耗時與任務重複次數成正比。文章後續會默認任務耗時為衡量的主要維度。
考慮到產品的不同類型，任務耗時在某些系統的相關性可能不高，你可以選擇一個不同的衡量維度，比如錯誤操作所出現的次數。
接著要考慮多久搜集一次數據，也就是確定實驗次數和頻率。
記住，我們試圖繪製隨時間變化的曲線，所以我們需要邀請同一批實驗對象來完成同樣的實驗任務。我們建議你不斷重複這些實驗，直到達到效率飽和點，也就是學習曲線達到平緩為止。
在設計實驗時，你可能會問這樣兩個問題：要進行多少次實驗？每次實驗間隔多久？這兩個問題的答案取決於實際情況。
要預測用戶達到效率飽和點的次數，首先要考慮系統的複雜程度。你可以先計劃做5-10次實驗，根據兩個原因適當地增加實驗次數：（1）您要確保參與者已達到學習飽和點;（2）一旦到達了學習飽和點便取消可用性測試環節。
至於時間間隔的問題，可以參考用戶實際使用頻率，並儘量讓實驗間隔接近用戶使用頻率。對於用戶日常或一周內多次使用的產品，可以將時間間隔設為一天；對於每月使用一次的產品，可以將使用間隔設為四周。
記住一定要保證實驗對象是同一批人，並且確保他們每次都能完整的完成操作。（這與通常的情況不同，在正常情況下，您希望不同的測試用戶研究設計的不同迭代。）你可能在實施易學性測試時對不同的功能任務進行測試， 這種情況下你需要保證測試的隨機性以避免影響實驗結果的準確度。過去的研究表明，用戶往往習慣將已完成的任務經驗應用在未來的任務測試中，所以隨機性可以減輕這種影響。
對於每個任務，記錄在每次實驗中所得出的指標均值，並將其繪製在折線圖中，我們會得到最終的學習曲線。
與任何定量研究一樣，你要分析數據的統計學意義。換句話說，確保實驗結果是真實可靠的，分析並確認學習曲線的趨勢不是數據噪音。通常我們會用統計學方法——單因素方差分析法來進行驗證。
一旦你完成分析並確認了數據顯著性之後，可以開始思考：學習曲線結果的斜率是怎樣的？易學性較低的用戶界面通常會有較為平緩的曲線，需要進行大量實驗才最終達到效率飽和點。相對應易學性較高的用戶界面的學習曲線斜率很陡，任務耗時在數次重複實驗後便快速下降並達到飽和值。
回到文件備份任務的例子，假設用戶在4次實驗後即達到效率飽和點，那這個界面設計相對高效，能夠滿足商業場景。如果用戶在30次實驗後才達到效率飽和點，這個界面設計的易學性就太低了。
另外，要考慮最終的效率：用戶將花費10分鐘的時間學會操作，這是否達到我們的預期？答案可能取決於競爭對手產品的耗時，如果競品的數據無法獲取，可以從成本，投資回報率等角度去思考。如果IT管理員每天花10分鐘以最優的方式完成備份任務，一年下來的總共耗時3650分鐘，約60個小時。每小時花費100美元，這意味著該公司將花費6000美元來完成備份。這個結果是否可以接受，產品設計是否需要改進，就要取決於每個產品自身的情況了。
產品易學性告訴我們用戶要多久才能熟悉一個產品。衡量產品的易學性對那些日常被使用的界面設計格外重要。一次易學性測試需要同一批實驗對象進行反覆實驗，實驗結果通過學習曲線反映用戶熟悉一個產品所需要的重複實驗次數。
即使你不真正實踐易學性測試，在工作的過程中將這些概念納入到產品設計的思考，也會有助於你權衡功能和交互的優先級，幫助你更好的服務用戶。
Tom Tullis, Bill Albert (2013)Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics. Morgan Kaufmann.
Allen Newell, Paul Rosenbloom (1980).Mechanisms of skill acquisition and the law of practice.Technical Report. School of Computer Science, Carnegie Mellon University.
作者：Alita Joyce
原文連結：https://www.nngroup.com/articles/measure-learnability/
翻譯：Jonan Zhang；審核：Wenhy；翻譯小組公眾號：交譯所
本文由 @交譯所 翻譯發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議