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