何為使用者體驗？
“提升產品的使用者體驗”、“打造極致的使用者體驗”這樣的說法大家一定經常聽到，很多企業也把這作為提升產品質量的目標。使用者體驗的定義有很多，通俗來講，使用者體驗是指使用者在使用產品時的直觀感受，包括介面是否友好，操作是否流暢，功能是否滿足需要等等。
蜂巢模型
在蜂巢模型中，使用者體驗包含七個模組：
Useful（有用性）：是否有真實的使用者需求Usable（可用性）：是否可以滿足使用者需求Desirable（滿意度）：是否能讓使用者滿意Findable（可找到）：設計的元素和元件是否易於發現Accessible（可獲得）：使用者是否能夠方便地完成操作、達到目的。Credible（可信賴）：是否能讓使用者產生信賴Valuable（有價值）：位於模型的中心，意味著使用者體驗的核心在於產品是否真正帶來價值。蜂巢模型
五層模型戰略層：設計產品時首先要回答的問題是“我們透過這個產品要獲得什麼？”和“使用者透過我們的產品能獲得什麼？”，要滿足的使用者需求和公司的商業目標。範圍層：產品的功能範圍，也就是產品要提供的功能和服務是什麼。結構層：結構層確定各個將要呈現給使用者的選項的模式和順序，將範圍層定義好的零散的需求，進行結構化的歸納組合。框架層：基於結構層梳理出來的功能資訊，進行視覺化的框架設計，定義頁面的佈局和元件之間的關係和位置。表現層：即最後呈現出來的視覺效果，關注的是，介面的呈現是否為使用者提供有效的選擇和引導，並且提供了一條流暢的視覺路徑。
五層模型
使用者體驗金字塔
使用者體驗金字塔
尼爾森十大可用性原則狀態可見原則環境貼切原則撤銷重做原則一致性原則防錯原則易取原則靈活高效原則易掃原則容錯原則人性化幫助原則注重使用者體驗的好處
使用者體驗的好處
使用者體驗測試方法調查問卷（傳統媒體、新媒體、論壇）使用者訪談功能反饋使用者測試（眾測）App灰度釋出、內測A/B Testing原型測試（Prototype Test）眼動儀、腦動儀
這些方法都是透過使用者體驗反饋（主動或被動）來評估產品體驗好壞的。
A/B測試
AB測試是借鑑了實驗的思維，目標是為了歸因。通俗來說，就是我們想把條件分開，明確地知道，哪種條件下，使用者會買賬。這就需要三個條件：有對照組，隨機分配使用者，且使用者量足夠。
最早的AB測試本身是起源於醫學。當一個藥劑被研發後，醫學工作人員需要評估藥劑的效果。一般就會選擇兩組使用者（隨機篩選的使用者），構建實驗組和對照組。用這兩組使用者來“試藥”。也就是實驗組使用者給真的藥劑，對照組使用者給安慰劑，但是使用者本身不知道自己是什麼組，只有醫生指導。之後，在後期的觀察中，透過一些統計方法，驗證效果的差異性是否顯著，從而去校驗藥劑是否達到我們的預期效果。
這個就是最早期的醫學“雙盲實驗”。網際網路行業其實也差不多是這麼用。我們需要確認的是，當前改版，是否有效果，也就是說，我們需要驗證效果的“藥劑”變成了一個“改版”。
業務把將web或者app介面或者流程，拆分為多個版本。然後將流量分層（或者分流），不同的人群使用的某個功能或者觸發的策略不同。但是這裡的人群一定要滿足同質化的特性。所以無論分層還是分流，我們都需要將使用者隨機分配，且同一使用者不能處在兩個組內。
通俗來說，AB測試是一種網際網路人口紅利減少的背景下，為了提高使用者滿意度，留下使用者而使用的一種利用數學原理來精細化運營的評估方法。
AB實驗
實驗的基本流程為：
選擇指標建立假設選取實驗單位計算樣本量流量分割實驗週期計算線上驗證資料檢驗使用者體驗測試設計
前面我們講到的都是基於使用者實際反饋做的相關體驗測試，那麼作為測試人員在平時測試的時候怎麼開展使用者體驗測試？
站在使用者的角度理解功能的設計，業務的邏輯多看多用多想邀請更多人參與，產品、研發、市場、營銷等重視原型測試配合產品設計好A/B測試方案有條件的可以在正式投放市場前開展內測最重要的就是重視，可以根據一些模型來設計一些針對性的檢查項或者測試用例基於尼爾森可用性原則設計的測試檢查點
|
可用性原則 |
原則描述 |
檢查項概述 |
|
狀態可見原則 |
系統應該讓使用者知道發生了什麼，在適當的時間內做出適當的反饋。使用者在網頁上的任何操作，不論是單擊、滾動還是按下鍵盤，頁面應即時給出反饋。【即時】是指頁面響應時間小於使用者能忍受的等待時間。 | 系統應反饋使用者當前操作的行為、進度、狀態、結果，反饋資訊清晰準確，避免無關或無效資訊。 |
|
當用戶完成了（一系列）操作，是否有反饋告知使用者接下來的一系列操作，或功能可用了？ | ||
|
是否使用者每一步操作都有明確反饋 | ||
|
如果系統的響應時間較長，有明顯的滯後（超過xx秒），在這段時間內，是否一直向用戶顯示系統的執行程序（例如進度條）？ | ||
|
環境貼切原則 |
系統應該用使用者的語言，用詞，短語和使用者熟悉的概念，而不是系統術語。遵循現實世界的慣例，讓資訊符合自然思考邏輯。 |
圖示、符號、標誌、圖表和其它視覺資訊的設計容易辨別和理解嗎？ |
|
字型和背景顏色的使用是否符合常規 | ||
|
介面中的語言是否簡潔、清晰、準確（不含歧義和語法錯誤），是否與當前任務語境一致，易於使用者理解？ | ||
介面中的術語是否是使用者使用的術語，而不是計算機術語 | ||
|
撤銷重做原則 |
為了避免使用者的誤用和誤擊，系統應提供撤銷和重做功能。使用者要能對當前的情況很好地瞭解和掌控，足夠自由。 | |
|
是否支援“撤銷”操作 | ||
|
取消操作是否輕而易舉 | ||
|
使用者是否方便返回上一級選單 | ||
|
一致性原則 |
互動行為、視覺效果、介面用語、翻譯保持一致。使用者需要在同一個產品中接受同一套規範或者邏輯。 |
產品開發與規範是否一致 |
|
術語和命名全系統是否一致 | ||
|
UCD規範在各服務、各頁面是否保持一致。 | ||
防錯原則 |
透過系統的設計、重組或特別安排，防止使用者出錯。要儘量用足夠的提醒和設計，讓使用者不要混淆、犯錯和發呆。比出現錯誤資訊提示更好的是更用心的設計防止這類問題發生。在使用者選擇動作發生之前，就要防止使用者容易混淆或者錯誤的選擇。 |
發生錯誤實時校驗。 |
|
提示資訊的語言是否簡潔無歧義，是否使用使用者日常語言，容易理解？ | ||
|
出錯資訊中是否指明使用者應該如何糾正錯誤 | ||
|
不可用操作或功能需隱藏或者灰化。區域內服務列表不支援服務灰化並顯示不支援圖示 | ||
|
易取原則 |
儘量減少使用者對操作目標的記憶負荷，動作和選項都應該是可見的。使用者不必記住一個頁面到另一個頁面的資訊。系統的使用說明應該是可見的或者是容易獲取的。 |
介面是否呈現了使用者需要的所有必需資訊。 |
介面內容呈現整齊有序，不同型別的資訊應能清楚地區分，使用者易獲取所需必要資訊，無需記憶。 | ||
|
介面上的文字資訊應簡潔且表達準確。 | ||
|
靈活高效原則 |
中級使用者的數量遠高於初級和高階使用者數。為大多數使用者設計，不要低估，也不可輕視，保持靈活高效。 |
快捷鍵可用【TAB SHIFT ENTER】。 |
|
操作步驟是否冗餘 | ||
|
要有預設值，預設值應該合理。 | ||
|
需要持續開啟的窗體數量應保持最少，完成任務的步驟數量應保持最少。 | ||
|
為新手和專家設計定製化的操作方式 | ||
|
為不同使用者群提供不同入口和操作方式（如不同語言、文化、殘障人士等） | ||
|
易掃原則 | 審美和簡約的設計，對話中不應該包含無關緊要的資訊。介面足夠簡單、內容易讀。網際網路使用者瀏覽網頁的動作不是讀，不是看，而是掃。易掃，意味著突出重點，弱化和剔除無關資訊。 |
同一資訊在當前頁面是否重複多次顯示？ |
|
當前頁面是否顯示了無關的資訊？ | ||
|
頁面是否包含不必要的操作？ | ||
|
容錯原則 |
幫助使用者識別，診斷，並從錯誤中恢復。錯誤資訊應該用語言表達（不要用程式碼），較準確地反應問題所在，並且提出一個建設性的解決方案。 |
應提供與操作上下文相關的幫助。 |
|
當用戶有些錯誤發生時，及時反饋錯誤並提供糾錯幫助，出錯資訊應當對使用者解決問題提供建設性幫助 | ||
|
允許使用者犯錯，並使操作者能撤銷以前的指令 | ||
|
能幫助使用者在發生錯誤後迅速回到正確狀態 | ||
讓使用者單次只執行唯一操作 | ||
|
減少不必要的操作步驟 | ||
|
人性化幫助原則 |
在任何時候，考慮到使用者需要得到幫助的情況並予以提示。幫助性提示最好的方式是：1、無需提示；2、一次性提示；3、常駐提示；4、幫助文件。 |
幫助入口容易獲取，專用術語解釋簡潔易懂。 |
|
線上幫助的選項在介面中是否容易被發現 | ||
|
線上幫助、FAQ等內容完整、正確、簡潔 |