如何建立完善的設計驗收機制

2021-6-23    seo達人



在日常工作中,設計師經常會有這樣的煩惱:上線的產品和原先設計的不一樣,不是這個交互提示沒有顯示,就是那個圖標大小顯示錯了。更有甚者,產品功能的交互邏輯就有問題。用戶在使用過程中體驗大打折扣。導致這個問題的原因很可能是在產品開發(fā)鏈路中,設計師完成對設計稿的交付后就認為這個任務告一段落,開始著手下一個任務。而后續(xù)環(huán)節(jié)中的隊友對設計意圖、設計細節(jié)理解不足或產生誤解,將關注度僅集中在主要功能的提供上。解決這個問題,設計師們需要設立設計驗收環(huán)節(jié),進行設計輸出和產品實現(xiàn)的比對和檢測。

而在傳統(tǒng)的瀑布式開發(fā)流程中,由于產品實現(xiàn)周期較久,產品上線前設計師可以安排充足的時間進行驗收;但是在敏捷開發(fā)過程中,每個迭代的任務多、時間緊,設計驗收往往草草收場,以至于問題不斷累積,影響產品整體用戶體驗。本文將會結合酷家樂工具型產品-酷大師在敏捷開發(fā)過程中的實踐經驗說明如何搭建設計驗收體系,在設計師與隊友們的高效溝通的前提下,保障產品高品質在線。

 

搭建設計驗收框架

很多設計師反饋:產品上線前驗收過,有些小問題沒法立即解決;上線后會發(fā)現(xiàn)一些新問題;隨著產品功能的增加,問題越來越多,通常呈現(xiàn)分散式、零星式的特點,有些防不勝防的感覺。

實際上,這是因為大多數(shù)設計師認為設計驗收就是上線前的事情,結束了就完成了,沒有建立系統(tǒng)驗收框架,缺少全生命周期去跟進設計實現(xiàn)的概念。

由于酷大師項目是我從0到1一直跟進的項目,在啟動初期就做好了搭建設計驗收框架的準備,按照單一功能驗收、部分模塊功能驗收、全局功能驗收、階段性整體復查這樣的順序,網格狀、系統(tǒng)性、地毯式進行驗收。驗收階段貫穿上線前、上線后,形成點、線、面、體相結合的布局。

圖片

單一功能驗收階段——模塊驗收階段——全局驗收階段——周期性復查階段

 

一.單一功能驗收階段

大多數(shù)項目進行敏捷開發(fā)時,一個sprint結束后會上線該sprint研發(fā)的功能,此時可以進行該sprint中開發(fā)的功能的驗收。在酷大師敏捷開發(fā)過程中,一個sprint往往會完成1個復雜功能或多個獨立的簡單功能,我通常會給每個功能建立設計驗收文檔,逐個進行驗收。這個階段的驗收往往比較細致,會關注每個功能的設計輸出中涉及的所有細節(jié)點。

這樣一輪精細化驗收結束后,往往能夠發(fā)現(xiàn)產品實現(xiàn)中90%以上的問題。我稱這個階段為點狀驗收。

 

二.模塊驗收階段

有些功能比較復雜,會拆解為多個子功能,花費多個sprint進行研發(fā)。比如說酷大師中的渲染功能,先實現(xiàn)構圖外景等能力,再實現(xiàn)陽光調節(jié)能力。

所以會先進行構圖場景和陽光調節(jié)的單一功能驗收,當這些能力研發(fā)完成,渲染功能比較完整時,再進行整個模塊功能驗收。此時的驗收既是對單一功能的復查,也是對模塊功能的檢測。我稱這個階段為線狀驗收。

 

三.全局驗收階段

通常我會在一個相對具體的時間節(jié)點,比如半年、一年或者大版本更新迭代時,去查看整個產品功能迭代情況。這樣的時間節(jié)點就很適合進行一場全局性的功能驗收。

平日的驗收結束后陸續(xù)會進行優(yōu)化,但是由于優(yōu)化時間點不一定是即時的,也有很多情況下是問題優(yōu)先級較低,很久才修復。全局功能驗收就能從全局角度了解半年或一年進展情況,查漏補缺。

由于酷家樂體系下,半年會對產品做一次回顧,所以我會在1個季度結束后進行一輪全局驗收,檢查出的問題可以下一個季度進行優(yōu)化,保證每半年回顧時整體狀態(tài)可控。我稱這個階段為面狀驗收。

 

四.周期性復查階段

前面三個環(huán)節(jié)結束后其實會沉淀下數(shù)量客觀的驗收問題,一部分在上線前會解決掉,一部分上線前不容易解決的會在上線后短期內解決,還有一部分問題可能涉及資源、產品方向等短期難以解決的問題,會留檔,等待合適的時機進行解決。

為了防止短期內沒有解決的問題被時間所遺忘,我會安排周期性復查,比如在半年的節(jié)點上,復查這半年的驗收文檔,對問題進行跟蹤整理,適合近期進行優(yōu)化的推進優(yōu)化解決,短期內還是沒法解決的再進行備注說明。

這樣體系化的全生命周期的驗收,就可以保證產品穩(wěn)定的質量呈現(xiàn)。

 

明確基礎驗收流程

圖片

建立驗收文檔——驗收問題錄入——同步&溝通驗收問題【確定問題優(yōu)先級&跟進機制】——過程中跟進調整情況———上線前復查

 

一.建立驗收文檔

有些團隊內部協(xié)作習慣于直接口頭溝通,面對簡單且量少的問題時比較快速,但是也存在信息遺漏、溝通誤差等問題。所以建議每次設計驗收時先建立驗收文檔。

如果團隊共同使用線上協(xié)同工具,那么驗收記錄留檔和信息同步都能及時有效進行;如果沒有團隊協(xié)作工具,可以自己使用在線或本地文檔工具,比如石墨、語雀、Pages等。建立文檔時也需要按照一定規(guī)則,方便后續(xù)查找,比如命名按照功能、模塊、時間順序等。

隨著文檔的增加,為了方便進行管理,可以建立一張驗收文檔管理表,記錄單個文檔的基礎情況。有些團隊分工較細,交互設計師和視覺設計師會分別建立驗收文檔,在我們的團隊協(xié)作中發(fā)現(xiàn)共同維護一份文檔比較高效,只需要在問題類型中進行交互、視覺的分類即可。

 

二.驗收問題錄入

設計師在對最初的設計輸出和設計實現(xiàn)進行比對時,往往會發(fā)現(xiàn)與最初設計意圖有出入的地方,建議將差異點都作為驗收問題進行錄入,在后續(xù)溝通跟進弄清緣由的情況下,再去判斷是否列入驗收問題。

驗收問題錄入的過程,實際也是對功能的二次思考,在這過程中真切驗證原先規(guī)劃的操作路徑是否真的易用。有時也會在錄入過程中,發(fā)現(xiàn)需要增加延展的能力,那么也是可以錄入并備注,為未來的體驗優(yōu)化積累突破點。

驗收文檔的撰寫標準將在后文具體說明。

 

三.同步&溝通驗收問題

驗收問題常常會涉及多個崗位團隊成員,比如前端、后端、運營等,如果是團隊使用在線協(xié)作工具,在問題錄入的同時設計師可以先做好原因預判,立即@相關隊友,在正式進行溝通之前,能夠給相關隊友預留一些排查原因的時間。

在一次設計驗收完成后,可以依據(jù)整個驗收文檔,與相關隊友共同溝通驗收問題。可以召集相關幾位隊友直接溝通,或者召開會議。在溝通的過程中,通常需要復現(xiàn)問題,判斷原因,以及確定跟進優(yōu)化的負責人。

同時會根據(jù)問題的影響程度、調整難易程度、資源配比程度,綜合判斷各個問題的優(yōu)先級,再根據(jù)優(yōu)先級進行排期調整。設計師在排定優(yōu)先級時需要遵循體驗原則,盡量保證新功能上線時以較好的效果呈現(xiàn)。這樣用戶初次接觸功能時,在首因效應影響下,會對該功能體驗抱有好感,對產品整體體驗也會給到好評。

 

四.調整跟進

驗收問題調整的過程中,對于復雜問題往往需要進行頻繁的溝通,工程師需要在過程中與設計師確認方向正確性,防止偏差導致的再次誤差。

此時設計師應給予充足的支持,比如詳細解釋設計意圖,比如幫助工程師尋找類似場景的實現(xiàn)效果,比如相關組件資源等。既是團隊協(xié)作共同解決難題,同時也在解決問題的過程中了解底層原因,為預防后續(xù)遇到類似問題積累經驗。

 

五.上線前復查

體驗問題調整結束,依據(jù)體驗文檔,再次驗證修復情況。在這個時期,如果還遇到其他問題,也是可以進行問題錄入和優(yōu)化。

 

制訂驗收文檔標準

圖片

標明序號——定位問題范圍——定位問題分類——問題清晰說明——差異截圖對比——原因與解決方案——定位負責人——記錄優(yōu)先級———跟進記錄

 

一.標明序號

驗收文檔支持以多種形式呈現(xiàn),比如word、excel、ppt等,嘗試過多種形式后,選擇使用excel表格。對問題屬性、范圍、負責人等進行說明時可以單獨呈現(xiàn),很容易最終進行分類整理。

比如復查時,可以拉取一段時間的驗收文檔,整理后可以知道視覺問題占比10%,那么視覺還原程度還是不錯的。比如渲染模塊問題占比20%,那么說明這個模塊下還需要集中進行優(yōu)化調整。

確定呈現(xiàn)形式后,可以在文檔中標明序號,方便后期整理。

 

二.定位問題范圍

驗收問題影響范圍往往并不相同,比如影響當前功能、多個功能、當前模塊,也有些問題涉及產品全局,甚至還有些問題會涉及公司其他產品線,此時需要說明清楚。

工程師在修改問題時就可以針對該范圍進行問題解決,防止解決問題覆蓋面太小,產生遺漏。而涉及到公司跨業(yè)務線的問題時,可以@對應負責人,進行溝通解決。

 

三.定位問題分類

在酷大師驗收過程中,通常遇到的問題分類為:交互類問題、視覺類問題、運營類問題、技術類問題、產品方向類問題等。相關人員通常會直接關注對應問題,幫助高效處理。

 

四.問題清晰說明

清晰描述問題,盡量具體,避免類似于“不符合”、“不好看”、“與設計稿不一致”等主觀籠統(tǒng)的概括;提出問題的同時盡量說明解決方案,當然有些方案設計師能夠直接給予,而有些涉及其他崗位時就可以@隊友進行解決方案的描述。

 

五.差異截圖對比

將設計稿與開發(fā)界面進行截圖對比,標注出差異問題點,幫助相關隊友快速直觀理解問題。有些情況下截圖不能說明清楚操作過程中的問題,也可以采取錄制gif的方式,演示操作行為。

 

六.原因與解決方案

通常問題涉及的相關人員會在這個區(qū)域進行跟進說明,比如造成當前問題的原因、解決方案、排期等。

 

七.定位負責人

記錄當前跟進的跟進入。

 

八.記錄優(yōu)先級

優(yōu)先級的評定可以有多種維度。通??梢灾苯幼雠袛嗟木S度有兩個,易于調整的問題優(yōu)先級較高,對完成功能影響大的問題優(yōu)先級高。其他維度可以根據(jù)具體產品,與團隊共同進行分析,總結其中的規(guī)律。

 

九.跟進狀態(tài)記錄

主要集中于對問題解決情況的跟進,通常分為已解決、跟進中。

 

其他思考

為了實現(xiàn)產品高品質在線,除了在研發(fā)實現(xiàn)后落地系統(tǒng)的驗收機制以外,設計師可以在很多環(huán)節(jié)發(fā)揮作用:

1.設計稿本身的高標準輸出,考慮清楚開發(fā)成本和可實現(xiàn)性;

2.交互評審環(huán)節(jié)盡量解釋詳盡,與相關工程師達到理解上的一致;

3.開發(fā)過程中參與溝通,幫助工程師先做一波問題的排除;

4.出現(xiàn)問題幫助促成解決,包括跨團隊資源的收集、組件支持之類;

5.明確產品設計還原度對于用戶體驗的重要性;

6.以多種方式邀請合作伙伴參與到驗收環(huán)節(jié)中,比如bugbush、專家走查、可用性測試。

 

原文鏈接:酷家樂用戶體驗設計(公眾號)

作者:懷瑾

轉載請注明:學UI網》如何建立完善的設計驗收機制


藍藍設計建立了UI設計分享群,每天會分享國內外的一些優(yōu)秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯(lián)系。

截屏2021-05-13 上午11.41.03.png



分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯(lián)系,我們立即更正或刪除。

藍藍設計www.bouu.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務

 


分享本文至:

日歷

鏈接

個人資料

藍藍設計的小編 http://www.bouu.cn

存檔