本文主要說明交互設計師進行交互驗收的常規流程、交互驗收的內容,以及驗收注意事項。
做任何事情都應該有始有終,設計工作也是如此。
設計師前期參與需求討論、需求評審、輸出設計方案、組織設計評審、完成評審后的修改,以及交付給下游同事之后的協調溝通等,以上每一個步驟都需要投入較多的精力。
同時設計師仍然要做好善后工作,設計方案的交付只是項目推進過程中在設計節點的結束,想要保證項目后期上線的效果,認真對待“設計驗收”是非常重要的一個環節。
本文主要說明交互設計師進行交互驗收的常規流程、交互驗收的內容,以及驗收注意事項。
一、什么是交互驗收?
是指某個項目已經完成開發,測試人員已完成功能驗收,確保各個流程無異常和無阻斷之后,參與項目的交互設計師從交互層面對項目的實現效果進行驗收,發現交互問題并提交給開發跟進解決,之后再次復驗的過程。
二、交互驗收的常規流程
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協議。