本文主要說明交互設計師進行交互驗收的常規流程、交互驗收的內容，以及驗收注意事項。

做任何事情都應該有始有終，設計工作也是如此。

設計師前期參與需求討論、需求評審、輸出設計方案、組織設計評審、完成評審后的修改，以及交付給下游同事之后的協調溝通等，以上每一個步驟都需要投入較多的精力。

同時設計師仍然要做好善后工作，設計方案的交付只是項目推進過程中在設計節點的結束，想要保證項目后期上線的效果，認真對待“設計驗收”是非常重要的一個環節。

本文主要說明交互設計師進行交互驗收的常規流程、交互驗收的內容，以及驗收注意事項。

一、什么是交互驗收？

是指某個項目已經完成開發，測試人員已完成功能驗收，確保各個流程無異常和無阻斷之后，參與項目的交互設計師從交互層面對項目的實現效果進行驗收，發現交互問題并提交給開發跟進解決，之后再次復驗的過程。

二、交互驗收的常規流程

1. 測試完成功能驗收，將代碼打包提交給設計師驗收

交互設計師開始驗收的時間點，一般情況下是在測試人員完成1~2輪測試之后，這樣設計師驗收時主要的精力集中在設計相關的問題上。

這里有兩個需要注意的地方：

1. 個別緊急待上線的需求，交互設計師可能會在測試人員未完成功能驗收時介入，只是過早參與驗收，發現的問題可能會比較多，其中有些并非交互問題，會耗費設計師過多的精力與時間；
2. 實際工作過程中，交互設計師在某個時間段內可能會承擔多個項目，處于并行推進的狀態。需要合理安排時間，在給定時間范圍內完成驗收工作。

2. 匯總驗收問題

交互驗收時可以按照不同的維度記錄bug，比如按照需求的主流程與子流程經過的頁面驗收、按照交互稿中原型輸出的順序驗收。

對于一些復雜的需求，包含相對復雜的流程，需要在驗收過程中結合以上兩種方式。

無論如何驗收，最終需要將發現的交互設計問題匯總，建議以文檔的形式集中記錄（或者有些公司是提交bug清單任務），之后一起交付給開發。

這樣便于開發抽時間集中解決，最好不要在工作群內單個拋問題，這樣既不利于交互設計師后續復驗，也不利于開發查閱問題。

3. 將問題提交開發解決，跟進解決的進度和結果

告知對應的開發查看和解決匯總的驗收問題，最好能提前了解開發解決所需的大概時間，便于自己提前預留復驗時間。

開發在解決提交問題的過程中，對于已經解決的問題會通知你再次復驗，對于未能解決的問題會告知你原因，此時需要針對具體情況分析判斷：比如現有條件下是否有其他合理的替代方案？

如果是因為開發技術實現難度、開發實現周期等因素，可以與產品經理溝通，對此類問題進行歸類記錄、并且標明未能實現的原因，站在交互設計師的角度給出合理建議。

4. 上線后的驗收

即使是待上線的測試版，復驗沒有問題之后，也無法保證發布正式版一定準確無誤，當然這是小概率事件。所以交互設計師仍然需要在需求發布正式版之后，再次對線上進行驗收確保無誤。

三、交互驗收哪些內容？

1. 交互流程

頁面邏輯判斷中涉及到的關鍵任務路徑，是否符合交互稿中設定的流程？

交互設計師在輸出交互稿時，一般會對需求中涉及到的關鍵任務，尤其是判定條件相對較多的任務流，繪制任務流程圖。

這樣做的目的既有利于查看交互文檔的人員明確判定的流程，也有利于交互設計師驗收時快速調用、提升驗收的效率。

2. 交互邏輯

在各種預定的操作情境下，用戶每一次操作所觸發的頁面狀態、操作結果是否達到預期效果？尤其是特殊狀態下的頁面樣式、提示等。

這里也需要關注“逆向操作”，即順著正常路徑執行返回操作，頁面跳轉邏輯是否正常。

同時避免頁面跳轉邏輯陷入死循環。比如在移動端帳號登錄頁面有注冊入口，點擊注冊按鈕進入新用戶注冊頁面，此時有的應用會在注冊頁面繼續放置“登錄入口”，若在注冊頁面點擊登錄按鈕，則默認返回上一級登錄頁面，并非是繼續進入下一級頁面，不然極端情況下這種場景會陷入死循環，用戶反復點擊多次，就需要回退多次。

3. 頁面元素的交互細節

頁面元素的交互細節與交互稿中元素的交互說明是有對應關系的，主要包括：

1. 頁面元素位置、可點觸區域、默認狀態、觸摸/懸浮狀態、點擊后的結果等是否符合預期；
2. 元素的限定極限值（最小或最大值）、交互動作（點擊/滑動/長按等）、頁面切換方式（其中PC端判定新窗口打開還是當前窗口刷新，移動端涉及到頁面滑入滑出方式）；
3. 頁面元素不同場景下的不同狀態：比如電商詳情頁“立即搶購”按鈕，當商品的庫存不足時，該按鈕置灰不可點，并在頁面給出相應的提示說明）。

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協議。