起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何定期審查用戶體驗？
審查清單的結構可以自行刪補，最重要的是，要有審查的意識和動手記錄的習慣，這是長線工程，可以堅持定期輸出。那么，如何定期高效、有方向地審查用戶體驗？
寫在前面
交互設計師除了日常需求對接、原型設計、測試走查工作，在日常使用和體驗App中可以記錄并積累用戶體驗的相關問題并給出對應的解決方案，定期輸出審查報告，和產品對接溝通，納入排期優化。
經過自身的嘗試，我梳理了一份審查結構，每次審查可以從這份結構入手，將對應的問題及方案進行歸納，形成一份完整的審查報告。
審查清單的結構可以自行刪補，最重要的是，要有審查的意識和動手記錄的習慣，這是長線工程，可以堅持定期輸出。
那么，如何定期高效、有方向地審查用戶體驗？你可以借鑒下面的審查結構。
審查結構
我將審查結構分成了4部分，其核心圍繞「優化交互體驗」，在平時你還可能會碰到功能缺陷、界面呈現相關的問題，也有可能你的靈感突然大爆發，想到可以提高用戶數據的一些好的點子，不要受限于你的崗位本身，認為界面呈現是視覺的事，功能缺陷和優化數據是產品的工作。
主動一些，隨手把這些問題和方案都記錄下來，讓產品變得更加“有用、易用”是大家共同的目標。
（ps：有些公司并不設立交互崗位，那么這件事就可作為產品的例行工作了；或者，也可以把視覺童鞋加入進來，分工合作共同輸出審查報告）。
隨著審查結構的維護更新，后期會重新調整結構進行刪補。
目前版本采用的結構如下：
1. 解決功能缺陷
如果依據KANO模型，產品需求可以分類為：魅力型、期待型、必備型、無差異型、反向型。
解決功能缺陷可以是：
- 滿足用戶的必備型需求，針對該需求出交互設計方案；
- 若存在無差異型和反向型功能，可以指出來建議去除。
審查示例：
2. 優化交互體驗
此部分目前包含了13項原則，每項原則都有相應的準則，根據這些準則，總會發現App中某些流程、某些頁面、某些交互設計或某些操作反饋等不符合設計原則的。
若存在，將問題羅列出來并給出優化方案。
（1）易學性
用戶不用花費時間或者花費較少時間就可以了解產品如何使用。
案例：界面內容或操作讓用戶產生疑惑，比如一個置灰按鈕沒有任何提示，用戶不了解置灰的原因，從而導致后續的操作無法進行。優化方案是置灰狀態下給出提示文案，告知用戶置灰原因。
（2）便捷性
產品導航清晰，要易于操作、步驟簡單。
案例：沒有為用戶提供清晰的功能入口，比如：界面提示用戶碰到某某問題可以聯系在線客服，但是未給出客服的入口，這種情況下不知道客服入口在哪的用戶仍然無法解決問題，而知道客服入口的用戶還要自行切換跳轉頁面找客服入口，步驟繁瑣。優化方案可以給在線客服加上文字鏈或加上一個客服入口，點擊后直接跳轉到客服咨詢窗口。
（3）易懂性
系統用戶要貼合用戶環境，使用用戶理解的語言，避免系統術語。
案例：App在文案擬定上若往專業術語上靠，即違背了易懂性原則，文案要人性化表達，讓小白用戶也能夠讀懂，避免使用“頁面404”、“撤銷沖正”類似的詞匯。
（4）可尋性
在界面上應該呈現用戶想要的信息。
案例：界面展示的內容通常是由產品和交互規劃的，設計時要站在用戶角度思考，展示用戶想看到的內容。比如：用戶轉賬確認，用戶可尋的內容至少應該包含：金額、轉賬賬戶、收款賬戶這3個要素。
（5）完備性
是否嚴密考慮到App所有用戶狀態（用戶登錄或未登錄）或內容狀態（有數據狀態和無數據狀態、特殊狀態和異常狀態）的完備性。
案例：功能入口區分或不區分用戶狀態，根據實際情況而定，比如用戶的評論列表在未登錄狀態下即可瀏覽，若要發表評論則需要用戶登錄；而某工具型App的幫助文檔則不管用戶是否登錄都可查閱。
（6）可讀性
信息內容可讀性強，內容不要給用戶壓迫感。
對于重要信息和非重要信息，優先展示重要信息，若重要信息較多，則考慮合并分類。
案例：一些任務流程需要用戶閱讀并同意xx協議，協議的份數可能很多，將所有協議名稱一股腦平鋪展示出來即違背了可讀性原則。優化方案可以是對協議進行合并歸類，用戶要閱讀的話跳轉到協議列表或一個整合的協議正文。
（7）合理性
無論是設計還是用戶的操作、系統的反饋都是合理且符合常識的。
細化審查可以是：
- 用戶操作結果反饋是否達到用戶預想目標；
- 控件組件的使用是否合理并正確；
- 動效是否使用合理且貼合現實世界；
- 等等。
案例：錯誤地將提示對話框誤用為確認對話框。
（8）及時性
對于狀態的切換和操作的反饋要及時告知。
案例：用戶收藏成功后收藏圖標的狀態沒有及時切換也沒有toast提醒。
（9）防錯性
要么從設計上防止用戶出錯，要么在用戶采取行動或提交最終數據前進行提醒。
細化審查可以是：
- 是否可以通過設計組件的不可用狀態防止出錯；
- 誤操作和危險操作是否進行警告或二次確認；
- 表單信息是否進行校驗并提示；
- 等等。
案例：用戶做重要操作或刪除重要內容時沒有進行二次確認，比如刪除照片點擊刪除按鈕后即完成刪除同時也找不到照片回收箱。
（10）容錯性
允許用戶出錯，并告知用戶出錯的原因和解決方案。
細化審查可以是：
- 容易發生的誤操作是否支持用戶撤銷；
- 是否幫助用戶診斷并從錯誤狀態中恢復；
- 等等。
案例：沒有及時從錯誤狀態恢復，比如用戶從弱網環境到網絡信號好的環境后，原加載失敗的文章沒有恢復到正常狀態。
（11）指引性
用戶不能一看就會的操作或功能，給出貼心的指引。
案例：在用戶迷茫會需要幫助的地方沒有給用戶提供貼心的提示或幫助文檔。比如某App的虛擬幣提現，未給用戶提供規則說明，用戶對提現的條件無從得知。
（12）易取性
減輕用戶的記憶負擔，用戶不必要記住頁面信息。
細化審查可以是：
- 高頻搜索為用戶保留搜索記錄；
- 長操作流最終頁面提供信息以供確認；
- 等等。
案例：外賣最終支付頁面未提供訂單詳情。
（13）高效性
讓用戶能夠快速高效地完成流程、任務或執行完操作。
案例：用戶常用到的操作，沒有為其提供快捷入口。比如商品詳情頁面滑到頁面底部要回頁面頂部只能往回滑。優化方案可以是向下滑到一定的高度后出現“回到頂部”的標識，點擊后快速回到頁面頂部。
相關閱讀：《理解尼爾森十大可用性原則》
審查示例：
以上根據各原則審查出的問題若需數據支撐，可在問題描述時將實際數據貼上，增加說服力。
3. 規范界面呈現
此部分關鍵目標就是“嚴格遵循一致性原則”，同時對于主流設備要進行適配，不要讓用戶有體驗多個不同App的感覺。
根據設計規范，不難發現與界面呈現相關的問題，同樣問題羅列后需要給出優化方案。
（1）組件呈現
組件呈現的一致性主要體現在以下方面：
- 組件符合用戶認知，比如：同種按鈕置灰狀態和提交狀態能夠一眼看出（有碰到過置灰狀態的按鈕看起來還是可點擊的案例）；
- 同種組件樣式保持一致，比如：同樣都是確認對話框，在一個App里面不要出現多個樣式不同的對話框；
- 同種組件交互保持一致，比如：同一個App里頭的頁簽頁面都可以通過手勢左右滑動來進行切換，不要某些頁面可以，某些頁面又不可以；
- 符合平臺設計規范，比如：蘋果系統參照人機交互設計指南設計規范，安卓系統參照Material Design設計規范，或者直接參照自己團隊的的設計規范。
（2）數據呈現
對于App的數值，需要先設定特定格式，保證前端的展示統一，比如：
- 金額：保留2位小數，有千分位符號；
- 小數：通常保留1位小數；
- 密碼：默認暗文顯示，有按鈕進行明暗文切換；
- 時間：xxxx-xx-xx xx:xx，例如：2020-04-04 13:23；
- 日期：日期：xxxx-xx-xx，例如：2020-04-04；
- 日期范圍：xxxx.xx.xx-xxx.xx.xx，例如：2020.04.04-2021.04.04。
（3）文案呈現
文案需要保證句式和用詞都統一。
1）句式保持一致
- 頁面標題之間的句式結構保持一致；案例：對于表單編輯的頁面，頁面標題統一為“動詞+對象”的句式。比如：輸入手機號、輸入驗證碼、設置密碼等。
- 文案之間的句式結構保持一致；案例：所有長流程的成功結果頁，主提示語統一為“賓語+動詞+成功”的句式，賓語可以選擇性省略。比如：支付成功、額度激活成功等。
2）用詞保持一致
操作、稱謂的用詞，在準確不引起歧義的基礎上盡可能精簡。
- 操作：比如表單提交統一用“提交”；涉及新建的操作都為“新建”，而不混用“添加”、“創建”等。
- 稱謂：比如稱謂統一用“您”或“你”。
（4）設計風格
從視覺角度而言，設計風格一致性是至關重要的，主要包含以下幾個方面：
- 插畫風格保持一致
- 圖標風格設計保持一致
- 遵循文字（大小和字體）使用規范
- 遵循顏色使用規范
- 遵循系統間距規范
（5）設備相關
主要審查以下3個方面：
- 橫豎屏：若橫豎屏需要分別適配的話，需要審查橫豎屏下的功能和顯示效果是否完善。
- 高低分辨率：在不同設備下，前端顯示要進行適配以確保各分辨率下設備的顯示效果良好。
- 操作系統：IOS和安卓系統，操作的結果要保持一致。
審查示例：
4. 提高轉化留存、刺激用戶活躍
此部分的重點不是審查問題，而是思考能夠“提高轉化留存、刺激用戶活躍”的方案，大部分App的優化數據的核心圍繞下面的前2點。
- 提高用戶轉化
- 刺激用戶活躍
- 提高購買轉化
- 提高支付轉化
- 等等
若該App已有模塊實現業務營收比如自有商城，則可以展開到諸如“提高購買轉化”、“提高支付轉化”等提出優化方案。
不管優化的方式是：
- 流程設計優化，比如：將原來注冊流程的4步優化成3步
- 頁面交互重構，比如：根據內容的重要程度重新規劃頁面結構
- 新增亮點功能，比如：在商城頁面增加購買返利專區
- 等等
其目標圍繞提高用戶數據不變。
相關閱讀：《設計師應該了解的數據指標》
審查示例：
寫在后面
有些同學會覺得平時處理迭代需求的時間都不夠，還要定期輸出審查報告，實在是“分身乏術”。你可以將審查分散于你體驗App的任何時刻，將審查的時間碎片化處理，在完成日常需求的過程中發現問題即記錄下來，隨著時間推移，自然會積累到一定量，到時候再統一整理并輸出審查報告。
下期的審查可以對上期的審查進行復盤，針對「提高轉化留存、刺激用戶活躍」方案收集優化后的數據，讓你的審查項目更具有權威性和說服力。
注意「提高轉化留存、刺激用戶活躍」部分不要過于天馬行空，要契合產品的方向和目標。
以上審查結構排定優先級的順序可以遵循：「解決功能缺陷」>「提高轉化留存、刺激用戶活躍」>「優化交互體驗」>「規范頁面呈現」。
根據經驗，方案的通過率順序一般是：「解決功能缺陷」>「優化交互體驗」+「規范頁面呈現」>「提高轉化留存、刺激用戶活躍」。
隨著功能的迭代，永遠會有新的問題暴露，如若不解決，會堆積越來越多，因此定期審查用戶體驗存在其合理性和必要性。
你平時會主動審查用戶體驗嗎？你的審查思路和結構又是怎樣的？
歡迎一起溝通交流。
作者：辛小仲；一名正在成長的交互設計師，公眾號：辛小仲。
本文由 @辛小仲 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Pexels，基于CC0協議
小仲您好，您平時都會看一些什么書呢，最近比較迷茫，不知道該看些什么，麻煩您給推薦1、2本（太多看不完），謝謝了~
比如《設計心理學》、《簡約至上：交互式設計四策略》