起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識交互驗收的4項常規流程和8個具體內容
本文主要說明交互設計師進行交互驗收的常規流程、交互驗收的內容，以及驗收注意事項。
做任何事情都應該有始有終，設計工作也是如此。
設計師前期參與需求討論、需求評審、輸出設計方案、組織設計評審、完成評審后的修改，以及交付給下游同事之后的協調溝通等，以上每一個步驟都需要投入較多的精力。
同時設計師仍然要做好善后工作，設計方案的交付只是項目推進過程中在設計節點的結束，想要保證項目后期上線的效果，認真對待“設計驗收”是非常重要的一個環節。
本文主要說明交互設計師進行交互驗收的常規流程、交互驗收的內容，以及驗收注意事項。
一、什么是交互驗收？
是指某個項目已經完成開發，測試人員已完成功能驗收，確保各個流程無異常和無阻斷之后，參與項目的交互設計師從交互層面對項目的實現效果進行驗收，發現交互問題并提交給開發跟進解決，之后再次復驗的過程。
二、交互驗收的常規流程
1. 測試完成功能驗收，將代碼打包提交給設計師驗收
交互設計師開始驗收的時間點，一般情況下是在測試人員完成1~2輪測試之后，這樣設計師驗收時主要的精力集中在設計相關的問題上。
這里有兩個需要注意的地方：
- 個別緊急待上線的需求，交互設計師可能會在測試人員未完成功能驗收時介入，只是過早參與驗收，發現的問題可能會比較多，其中有些并非交互問題，會耗費設計師過多的精力與時間；
- 實際工作過程中，交互設計師在某個時間段內可能會承擔多個項目，處于并行推進的狀態。需要合理安排時間，在給定時間范圍內完成驗收工作。
2. 匯總驗收問題
交互驗收時可以按照不同的維度記錄bug，比如按照需求的主流程與子流程經過的頁面驗收、按照交互稿中原型輸出的順序驗收。
對于一些復雜的需求，包含相對復雜的流程，需要在驗收過程中結合以上兩種方式。
無論如何驗收，最終需要將發現的交互設計問題匯總，建議以文檔的形式集中記錄（或者有些公司是提交bug清單任務），之后一起交付給開發。
這樣便于開發抽時間集中解決，最好不要在工作群內單個拋問題，這樣既不利于交互設計師后續復驗，也不利于開發查閱問題。
3. 將問題提交開發解決，跟進解決的進度和結果
告知對應的開發查看和解決匯總的驗收問題，最好能提前了解開發解決所需的大概時間，便于自己提前預留復驗時間。
開發在解決提交問題的過程中，對于已經解決的問題會通知你再次復驗，對于未能解決的問題會告知你原因，此時需要針對具體情況分析判斷：比如現有條件下是否有其他合理的替代方案？
如果是因為開發技術實現難度、開發實現周期等因素，可以與產品經理溝通，對此類問題進行歸類記錄、并且標明未能實現的原因，站在交互設計師的角度給出合理建議。
4. 上線后的驗收
即使是待上線的測試版，復驗沒有問題之后，也無法保證發布正式版一定準確無誤，當然這是小概率事件。所以交互設計師仍然需要在需求發布正式版之后，再次對線上進行驗收確保無誤。
三、交互驗收哪些內容？
1. 交互流程
頁面邏輯判斷中涉及到的關鍵任務路徑，是否符合交互稿中設定的流程？
交互設計師在輸出交互稿時，一般會對需求中涉及到的關鍵任務，尤其是判定條件相對較多的任務流，繪制任務流程圖。
這樣做的目的既有利于查看交互文檔的人員明確判定的流程，也有利于交互設計師驗收時快速調用、提升驗收的效率。
2. 交互邏輯
在各種預定的操作情境下，用戶每一次操作所觸發的頁面狀態、操作結果是否達到預期效果？尤其是特殊狀態下的頁面樣式、提示等。
這里也需要關注“逆向操作”，即順著正常路徑執行返回操作，頁面跳轉邏輯是否正常。
同時避免頁面跳轉邏輯陷入死循環。比如在移動端帳號登錄頁面有注冊入口，點擊注冊按鈕進入新用戶注冊頁面，此時有的應用會在注冊頁面繼續放置“登錄入口”，若在注冊頁面點擊登錄按鈕，則默認返回上一級登錄頁面，并非是繼續進入下一級頁面，不然極端情況下這種場景會陷入死循環，用戶反復點擊多次，就需要回退多次。
3. 頁面元素的交互細節
頁面元素的交互細節與交互稿中元素的交互說明是有對應關系的，主要包括：
- 頁面元素位置、可點觸區域、默認狀態、觸摸/懸浮狀態、點擊后的結果等是否符合預期；
- 元素的限定極限值（最小或最大值）、交互動作（點擊/滑動/長按等）、頁面切換方式（其中PC端判定新窗口打開還是當前窗口刷新，移動端涉及到頁面滑入滑出方式）；
- 頁面元素不同場景下的不同狀態：比如電商詳情頁“立即搶購”按鈕，當商品的庫存不足時，該按鈕置灰不可點，并在頁面給出相應的提示說明）。
4. 交互動效
如果交互設計師在輸出交互稿時，有相應的動效設計或文字說明（一般簡單的微動效可以通過文字表述，復雜一些的動效需要通過專業軟件輸出動效demo），驗收時同樣需要查看動效的還原度。
5. 不同屏幕尺寸的適配問題
PC端網頁設計中，通常會依據網頁重要性對頁面進行不同屏幕寬度的自適應，比較常見的是大部分網站首頁會依據不同寬度節點進行自適應。因此在交互設計階段就需要考慮到自適應布局，驗收時自然也不能忘了。
移動端界面設計，由于近年來大屏手機的出現，其中最典型的是iPhone的劉海屏，盡管我們輸出交互稿目前仍然是以iPhone 6的一半尺寸為標準，但是由于各種類型大屏手機的出現，導致我們不得不在設計初期、以及驗收階段考慮大屏手機的適配問題。
舉例：比如iPhone X去掉實體Home鍵之后，將返回主頁/調起多任務窗口的操作按鈕至于屏幕底部，并且為了避免交互手勢沖突，蘋果官方標明了針對此類機型進行界面設計的安全區。
所以在設計底部導航欄時，就需要將底部導航欄放置于安全區的底部，而不是屏幕的底部，不然會引發手勢沖突。
6. 操作的易用性與使用體驗
實際工作過程中，經常會遇到一種情況：原本按照交互稿的方案，可以確保頁面操作的易用性，但實際開發過程中基于開發技術實現的復雜度、開發時間有限等因素，可能無法實現交互稿的方案。
此時綜合各種影響因素，給出合理的替代方案，那么驗收時也需要特別注意替代方案的易用性與使用體驗。
7. 驗收到非本次需求的其他問題
此時需要評估問題的復雜程度，必要時與部門同事溝通商量。
一般根據問題的復雜程度決定：能解決的有關用戶體驗的小問題可隨即提出解決；若問題牽扯較多、調整相對復雜耗時，可以先記錄后續改進。
8. 移動端項目分別驗收iOS與Android端
iOS系統與Android系統有不同的交互設計規范，界面相關元素的排版布局與交互方式存在差異，也對應著不同終端的開發。
特別注意：輸出交互稿時最好考慮到兩端的差異，給出明確的差異說明或圖例示意，這樣便于開發明確，同時降低了交互設計師后期的溝通成本。因此驗收時需要針對兩端分別走查。
四、交互驗收注意事項
1. 對項目驗收復盤思考
驗收過程中有沒有遇到什么問題，如果有，是否有更好的解決辦法？溝通過程中是否有不順暢的地方，是不是自己對基礎技術不夠了解？哪些問題是自己應該堅持不妥協的，哪些問題沒有必要耗費過多精力爭執等等。
每一次復盤都是為了之后項目的驗收更加順暢高效。
2. 對驗收匯總未能解決的問題，分類記錄
目的是避免記錄的問題過于零散，不利于上下游查看的同事分析。分類記錄便于明確定位屬于哪里的問題、問題的多少、問題的性質，也有利于團隊后續的復盤。
總結
目前有大量的專業書籍和文章詳細介紹如何輸出高質量的交互稿，對于交互設計師而言，這只是承接需求的一部分，不僅要重視前期定義需求、產出交互文檔，更要做好收尾工作，認真對待需求的交互設計驗收。
作者：Viksea，微信公眾號：Viksea的設計思考（ID：viksea-ux）
本文由 @Viksea 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
厲害啊 ??
??