起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識設計驗證：有效增強設計方案說服力！
沒有經過用戶研究環節的設計方案，容易在投入實用后暴露出各種隱性問題，增加產品上線的風險。而使用體系化的設計驗證方法，可以幫助我們交互設計師在前期發掘問題，改進設計。
相信各位設計師在項目實踐中，多少都有過根據需求文檔做好了設計，卻在面臨評審時難以有效說服來自各方（開發、測試、需求方等等）聲音的經驗。尤其在許多敏捷式研發的團隊中做交互設計，沒有完整的“用戶研究-需求梳理-交互設計”流程，產品上線的功能是否能滿足用戶預期成為了一個很大的疑問。
那么作為交互，如何從自己的角度進行設計方案的驗證測試呢？
What & Why
在有條件接觸到用戶的情況下有明確目標的去做用戶測試，在通常意義上是一種“后置型”的用研方法。用戶測試幫助我們在設計實踐中秉承以用戶為中心的理念，主要是通過觀察和詢問用戶的行為想法，記錄產品的真實使用情況，從而驗證設計方案，界定出可用性問題。
圖1-1?穿插產品生命周期的用研方法
縱覽一個產品的生命周期中，可采用的用戶研究和測試方法有很多，在不同的時間節點方法不盡相同，常見的包括了問卷調研、訪談、焦點小組、眼動儀測試、可用性測試等（本文主要聚焦于設計完成后的方案選擇和效果評估階段所涉及到的驗證方法）。
除了時間階段因素外，測試方法的選擇還會受到不同類型設計方案、不同研究目的等方面的影響。
因此，作者通過結合項目經驗，從交互設計師的角度出發嘗試設計了一套快速驗證的體系，一定程度的提升了自身的工作效率。其中包含了幾類最為常見的場景所適用的驗證方法，可結合實際情況有計劃的、定期性的去建立這套用戶測試體系。
這個體系一方面能對設計方案中的問題及時的查漏補缺，推動方案找到最優解；另一方面也能幫助我們獲取一手的產品用戶使用現狀，從而在更加深入理解功能目標的基礎上進行需求分析，更好的體現出交互設計師的價值。
How to Do
圖2-1 快速驗證體系方法
1. Five Seconds Test
五秒測試適合于對于簡單信息呈現類的設計稿進行設計驗證，它的流程為：先把網頁總覽圖展示給被測試者5秒鐘，然后拿開圖像，向被測試者被提問記得剛剛在網頁上看到的什么。
可首先從以下三方面進行引導：
- 在這個頁面中您看到了什么內容？
- 您認為它提供什么功能或者服務？
- 在使用這個產品的時候，您認為解決了什么問題？
圖2-2?旅行類服務平臺官網測試
以旅行類服務平臺為例，經過測試后發現，用戶在打開booking.com官網時無法在第一時間內做出操作判斷，因為信息環境噪音較大減弱了本應強調的搜索服務。
而同樣是提供住宿預訂服務的agoda.com在第一屏所傳達的意圖相對清晰，其對產品的使用場景傳達相對明確，因此能夠更好的滿足消費者的訴求，解決關鍵痛點。
此方法主要被用于驗證頁面中的信息內容的優先級和文案傳達等是否符合用戶認知，內容是否區分出了功能的主次、布局是否存在問題，以及評估用戶的預期與相符度、產品戰略方向的準確性。若用戶能夠一眼準確得到這三個問題的答案，說明信息傳達的有效性已經達到，反之則不然。
然后，再通過體系化的提問層層遞進的挖掘產品功能和信息中從大到小的設計問題。另外，這個方法還可以結合A/B test來進行方案驗證，最終選出最優方案。
2. Brief Usability Test
相比精準定量性質的測試，簡易性可用性測試的門檻低、成本小，它無須收集精確的用戶數據，是一種更偏向定性性質的測試方法，其主要目的是收集用戶使用產品的反饋及改善建議。對于一些流程性較強的功能，采用這類方法測試更能發現其中的邏輯性體驗問題。
另外，將復雜的專業可用性測試分解成多次簡易型測試的方法，可更好的滿足敏捷迭代的需求。
測試的主要流程為：
- 首先為參與用戶介紹產品背景，設定場景和操作任務；
- 接著執行測試，在過程中觀察用戶使用產品的主要流程，驗證其否與設計邏輯的初衷相符；
- 最后，從用戶的實際使用情況（如考慮產品邊緣性操作的兼容性）倒推現有設計存在的問題，將列出的清單進行總結歸類找出這些問題的優先級。
簡易性可用性測試只需要召集2~3個用戶參與，也無須引入繁復的量表評分機制。
圖2-3?測試方法對比
在選取參與人員時，可以通過分層（多類型用戶產品）的方式抽取產品的目標用戶。與此同時還可將用戶分成多組多次測試，對第一次測試中發現的85%的問題進行優化后，再對該方案進行再次測試找齊剩下的所有問題，這種方式可以讓用戶對產品架構、任務流程提出多方面的建議。
3. Bugbush
Bug Bush通常可以在項目開發各階段的末期，如：公測版發布前，劃出專門的時間段邀約所有參與項目的人員，一起來搜尋產品存在的缺陷。
建議可以在流程較為復雜的重要版本或功能上線時，采用此驗證方法，并確保線上沒有重大bug影響試用以及服務穩定的狀態下進行。
其主要流程為：材料準備（場地、網絡環境、權限、產品狀態）>說明規則和流程>使用協同類工具記錄發現的問題（jira）>統計issue數、有效bug數、需求數等，并給予相應獎勵>落實問題并同步到需求池。
Bugbush是一種集眾人智慧的團隊活動，由于參與人數、設備類型、環境情況等影響因素較多，能夠更好的覆蓋到多種場景以及邊緣情況產生時出現的問題。同時，定期的組織能夠起到調動成員的積極性的作用，幫助打破項目組成員僅聚焦于自己部分卻對產品全貌不甚了解的隔離狀態，加強成員對于產品的責任意識，能從項目主人的角度思考如何完善和推動產品的發展。
另外，邀請目標用戶一同參與bugbush以獲取一手資料也是種不錯的方法。
圖2-4 Bugbush步驟
在測試中，我們還需要注意以下的事項：
- 方式類似于測試但不限職位，建議邀請項目組所有成員參與，能夠更有效、覆蓋面更廣；
- 可以為測試設立專門的目標主旨，如易用性、趣味性等并圍繞其展開策劃；
- 可以適當引入游戲化和獎勵機制來調動積極性，增強趣味性。
小結
沒有經過用戶研究環節的設計方案，容易在投入實用后暴露出各種隱性問題，增加產品上線的風險。而使用體系化的設計驗證方法，可以幫助我們交互設計師在前期發掘問題，改進設計。
當然，個人也可以根據自身經驗、產品數據、用戶情況制定一套個性化的快速驗證體系，并將其應用到新的功能設計、產品的迭代流程更新等內容上，幫助自身加深對上下游的滲透，也能從多維度增強設計方案的說服力。
作者：馮韻，網易UEDC部門TB組交互設計師，相信設計的本質就是創造優美的事物，讓生活更美好，熱愛設計就是熱愛生活。
本文來源于人人都是產品經理合作媒體@網易UEDC，作者@ 馮韻。
題圖來自 Unsplash，基于 CC0 協議
我想問簡單可用性測試有什么弊端，適合什么場景？
確定是Bug Bush不是Bug Bash么？？