筆者在學校期間主修交互設計和用戶體驗方向，做過調研，發過論文，也做過設計，基本上把交互設計師在整個設計流程中的各種職責和任務都體驗了一遍，實際看來，學校所得和工作實踐的內容基本上是銜接的，這在初期的實習過程中也得到了驗證。但是隨著項目流程的不斷深入，筆者發現，在學校中少學習了一項重要的工作。
交互驗收。
為什么學校學習中缺失了這樣一環呢?原因很簡單，因為學校的項目基本停留在立項——調研——提需求——設計——原型——Demo階段，也就是說到達Demo階段后就截止了，這也是各大用戶體驗大賽的參賽作品遞交的終稿。可是實際工作并非如此。能夠對著設計稿逐個校對進行驗收，是一個普通交互設計師的職責，但是交互驗收的過程不只是針對交互流程和邏輯，也包括用戶體驗的方方面面，以及各種可能意想不到的問題。回復驗收郵件，表明在交互層面這個產品是通過的，對應的交互設計師也要承擔對應的上線問題的責任。因此，交互設驗收也是一個設計師成長的必經進階之路。
1.什么是交互驗收
個人理解，交互驗收是指在產品初步提測到正式上線前的一段時間內交互設計師對產品效果、流程、體驗進行走查驗收，提出bug并推動解決的過程。簡單理解，交互驗收就是走查產品在交互和體驗方面的bug。
2.交互驗收都驗收哪些問題
(1)交互邏輯
交互邏輯是否正確是交互驗收主要的一項任務。在筆者的驗收經驗中，交互邏輯驗收主要包含正向邏輯和反向邏輯兩部分。
正向邏輯是指在各種預定的操作情境下，用戶的每一次操作所觸發的對應的頁面狀態、用戶操作是否都實現且滿足用戶預期，尤其是特殊狀態下的頁面樣式、提示等。這個過程，主要是需要每個狀態與原交互文檔的頁面流程保持一致;
反向邏輯，主要是指返回邏輯。在用戶實現某一個功能或完成一個任務返回原頁面后，原頁面是否需要刷新還是保持原緩存狀態。反向邏輯一般都較小，比較隱匿不易發掘，而且在交互文檔中很容易遺漏，因此在驗收過程需要重點關注，這與實際的用戶體驗息息相關。
(2)動效時間
只要包括動效的顯示時間、持續時間和消失時間的驗收。一般的動效主要是指toast提示、小氣泡或者其他特殊的手勢動效。
Toast提示從出現到消失的提示時間一般控制在3s，500ms出現和消失，剩下2s用戶持續顯示，達到既能讓用戶接受到反饋信息，又不會干擾操作和瀏覽的體驗。這時如果持續時間短，用戶無法有效捕捉到信息，持續時間長，對于一些高頻操作就會出現toast提示疊加現顯示的情況，都不是好的體驗。
氣泡提示一般都是即時出現的，用戶更關注持續的時間。氣泡除了要樣式顯著，讓用戶實時感知到以外，出現的時間也十分重要，因為有些氣泡上也會承載部分信息，這點與toast提示相似。3s對于輕量化的氣泡提示是比較合適的，2s則會給人感覺跳動，但是對于更重要的氣泡提示，可以選擇常駐不隱藏消失的策略。
其他的特殊手勢操作需要根據實際情況處理。一些細致的交互設計師在交互文檔中會標出預期的動效時間，但是依舊需要在測試驗收階段重點關注，判斷顯示時長在當前用戶場景下是否合理，實時、恰當調整動效時間。
(3)點擊區域設置或切換
按鈕或者表單中內容的點擊區域，是交互驗收中需要關注的一個比較重要的影響用戶體驗的“隱性”要點。按照“所見即所得”的原則，一個顯著的按鈕、圖標、頭像或者一條表單內容，用戶都會習慣性默認為可點擊的狀態，但是在實際的設計當中，點擊區域往往設計得更大一些，這樣可增強操作的容錯性，讓用戶較容易通過無論是拇指還是食指都能實現的點擊效果，這是涉及操作流暢性一個關鍵環節。
另一方面，同一固定區域中有多個可操作按鈕或區域時，對于實際點擊區域的設定尤為關鍵，例如下圖所示。該表單中每條內容均可點擊變為選中態，再次點擊可取消選中狀態。這本是一個比較常見的交互操作，但是在選中態中新增了一個可操作按鈕，按鈕的實際點擊區域一般都是按鈕icon的尺寸大小，但是在這個案例中，由于表單內容本身有點擊從操作，用戶很容易誤觸而改變表單內容的選中狀態，對用戶造成困擾和疑惑。因此，實際的點擊區域是這個表單內容中按鈕所在的整個區域，這樣使得用戶的誤操作幾率大大降低。
(4)觸發位移
主要包括手勢操作的滑動距離以及頁面切換時的位移效果，一般需要考慮到手機尺寸、用戶的操作舒適區、以及滿足操作場景的問題。
(5)小屏手機的兼容
一般不考慮iphone5以下的尺寸，因為那樣安卓系統的各種尺寸就無窮無盡了，更別提為每一種尺寸去做適配。但是也不能只以1080作為標準尺寸設計。尤其是對于操作、信息內容較多的頁面需要重點關注，在驗收時可切換不同機型的手機來驗收實際的顯示和操作效果確定文案是否折行、按鈕排布是否適合點擊。
3.如何協調推動解決
公司對于交互設計師一個重要的考量標準就是對項目的推動解決的能力，發現驗收的bug如何去解決便是其中之一。在一個較為完善的驗收流程中，由測試人員發起驗收流程，隨后交互設計師驗收并提交驗收結果，對應的bug轉給各自開發人員解決，解決后的程序需要重新提交打包后，由交互設計師驗證通過。這一過程一般會往復多次迭代，直至App封版前夕。交互設計師推動解決驗收問題，一般可以通過以下方式進行。
提交驗收報告：
一般僅需以郵件形式回復驗收結果，內容較多時可附上對應的附件文檔。提交后測試人員會重新審核后提出對應的bug給開發人員。在這個流程中，交互設計師與開發、測試人員的溝通相對較為滯澀，三者之間的溝通存在壁壘。導致效率較低，同時不利于后期的改動追蹤和改動效果的驗收。
在管理系統中提交bug：
直接針對平臺、版本、功能模塊提出對應的bug，便于交互設計師管理、跟蹤自己bug的解決情況，同時也便于開發人員認領屬于各自的bug。在這個流程中，測試人員提供對應的輔助工作，交互設計師與開發可直接溝通，對于驗收進度的提升和產品功能的優化都有很好的推動作用。
直接線下找對應開發GG溝通解決：
是最快、最直接的一種問題解決方案，但是不適宜在提測初期使用，原因有幾點：首先是尋找到對飲的開發有時比較難，尤其是面對一個較大的開發團隊時，一個功能可能涉及多方開發人員的共同實現;其次是針對較復雜問題，溝通時容易遺漏;還有就是人力問題，當面溝通效果好，但是對人力成本的小號相對較大，無論是精力還是體力。面對面溝通解決適合在產品驗收后期功能微調和頁面的小改動，可與開發人員當面快去溝通后協調解決。
4.驗收報告(郵件)怎么寫
首先要明確驗收報告上的幾點問題：
1).實事求是，不夸張事實。驗收是提出問題、解決問題的過程，不需要對現象的夸張描述，對于問題的描述力求簡潔、明了，同時為了保持PM、交互設計師、開發人員認知的一致性，盡量使用公司內容一致的描述方式，以及附上對應問題頁面截圖作為補充。
2).給出問題解決方案或預期效果;bug也分很多種，有些是yes or no的問題，只需指出問題點即可，如：
“在用戶未登錄狀態下，用戶頭像上不顯示登錄角標。”
但是有一些涉及體驗問題的bug，不是yes or no的問題，而是good or better的問題，因此需要給出相應的解決方案或預期效果，如：
“問題描述：在未登錄狀態下點擊播放列表時，頁面僅提示都需要登錄狀態;預期效果：在未登錄狀態下點擊播放列表時，頁面出現登錄狀態文案提示，同時露出登錄按鈕，點擊可直接跳轉至登錄頁面。”
3).標注優先級：優先級描述能夠告知相關人員問題的嚴重程度，便于開發人員合理安排自己的工作進度，這是一項利人利己的事情。
關于驗收報告的格式，可以參考一下樣式：
下面僅提供一下word版本驗收報告樣式以供參考。
工作中才發現，交互設計師的職責，不僅是在前期的產出物交付完成即可，更多的任務是在后期的交互驗收和優化推動截斷。以前覺著給出交互文檔比較重要，工作量大，但是后來才發現，每一個版本的驗收工作才是更加費心費力的，畢竟需要交互設計師主動去推動一個bug的優化，而不是收到需求后僅僅是輸出文檔就ok了。
