▲點擊"三分設"關注，回復"社群"加入我們
歡迎來到專業(yè)設計師學習交流社區(qū)
三分設｜連接知識，幫助全球 1 億設計師成長
阿里巴巴設計官方認證 MCN 機構(gòu)
SUXA 深圳體驗設計協(xié)會華東分會
全球服務設計共創(chuàng)節(jié)城市站發(fā)起者
·
轉(zhuǎn)自：酷家樂用戶體驗設計
編輯：劉麗
共 4638 字，預計閱讀 12 分鐘
在日常工作中，設計師經(jīng)常會有這樣的煩惱：上線的產(chǎn)品和原先設計的不一樣，不是這個交互提示沒有顯示，就是那個圖標大小顯示錯了。更有甚者，產(chǎn)品功能的交互邏輯就有問題。用戶在使用過程中體驗大打折扣。
導致這個問題的原因很可能是在產(chǎn)品開發(fā)鏈路中，設計師完成對設計稿的交付后就認為這個任務告一段落，開始著手下一個任務。而后續(xù)環(huán)節(jié)中的隊友對設計意圖、設計細節(jié)理解不足或產(chǎn)生誤解，將關注度僅集中在主要功能的提供上。解決這個問題，設計師們需要設立設計驗收環(huán)節(jié)，進行設計輸出和產(chǎn)品實現(xiàn)的比對和檢測。
而在傳統(tǒng)的瀑布式開發(fā)流程中，由于產(chǎn)品實現(xiàn)周期較久，產(chǎn)品上線前設計師可以安排充足的時間進行驗收；但是在敏捷開發(fā)過程中，每個迭代的任務多、時間緊，設計驗收往往草草收場，以至于問題不斷累積，影響產(chǎn)品整體用戶體驗。
本文將會結(jié)合酷家樂工具型產(chǎn)品 - 酷大師在敏捷開發(fā)過程中的實踐經(jīng)驗說明如何搭建設計驗收體系，在設計師與隊友們的高效溝通的前提下，保障產(chǎn)品高品質(zhì)在線。
搭建設計驗收框架
很多設計師反饋：產(chǎn)品上線前驗收過，有些小問題沒法立即解決；上線后會發(fā)現(xiàn)一些新問題；隨著產(chǎn)品功能的增加，問題越來越多，通常呈現(xiàn)分散式、零星式的特點，有些防不慎防的感覺。
實際上，這是 因為大多數(shù)設計師認為設計驗收就是上線前的事情，結(jié)束了就完成了，沒有建立系統(tǒng)驗收框架，缺少全生命周期去跟進設計實現(xiàn)的概念。
由于酷大師項目是我從 0 到 1 一直跟進的項目，在啟動初期就做好了搭建設計驗收框架的準備，按照單一功能驗收、部分模塊功能驗收、全局功能驗收、階段性整體復查這樣的順序，網(wǎng)格狀、系統(tǒng)性、地毯式進行驗收。驗收階段貫穿上線前、上線后，形成點、線、面、體相結(jié)合的布局。
單一功能驗收階段——模塊驗收階段——全局驗收階段——周期性復查階段【配圖】一.單一功能驗收階段
大多數(shù)項目進行敏捷開發(fā)時，一個 sprint 結(jié)束后會上線該 sprint 研發(fā)的功能，此時可以進行該 sprint 中開發(fā)的功能的驗收。在酷大師敏捷開發(fā)過程中，一個 sprint 往往會完成 1 個復雜功能或多個獨立的簡單功能，我通常會給每個功能建立設計驗收文檔，逐個進行驗收。這個階段的驗收往往比較細致，會關注每個功能的設計輸出中涉及的所有細節(jié)點。這樣一輪精細化驗收結(jié)束后，往往能夠發(fā)現(xiàn)產(chǎn)品實現(xiàn)中 90% 以上的問題。我稱這個階段為點狀驗收。二.模塊驗收階段
有些功能比較復雜，會拆解為多個子功能，花費多個 sprint 進行研發(fā)。比如說酷大師中的渲染功能，先實現(xiàn)構(gòu)圖外景等能力，再實現(xiàn)陽光調(diào)節(jié)能力。所以會先進行構(gòu)圖場景和陽光調(diào)節(jié)的單一功能驗收，當這些能力研發(fā)完成，渲染功能比較完整時，再進行整個模塊功能驗收。此時的驗收既是對單一功能的復查，也是對模塊功能的檢測。我稱這個階段為線狀驗收。三.全局驗收階段
通常我會在一個相對具體的時間節(jié)點，比如半年、一年或者大版本更新迭代時，去查看整個產(chǎn)品功能迭代情況。這樣的時間節(jié)點就很適合進行一場全局性的功能驗收。平日的驗收結(jié)束后陸續(xù)會進行優(yōu)化，但是由于優(yōu)化時間點不一定是即時的，也有很多情況下是問題優(yōu)先級較低，很久才修復。全局功能驗收就能從全局角度了解半年或一年進展情況，查漏補缺。由于酷家樂體系下，半年會對產(chǎn)品做一次回顧，所以我會在 1 個季度結(jié)束后進行一輪全局驗收，檢查出的問題可以下一個季度進行優(yōu)化，保證每半年回顧時整體狀態(tài)可控。我稱這個階段為面狀驗收。四.周期性復查階段
前面三個環(huán)節(jié)結(jié)束后其實會沉淀下數(shù)量客觀的驗收問題，一部分在上線前會解決掉，一部分上線前不容易解決的會在上線后短期內(nèi)解決，還有一部分問題可能涉及資源、產(chǎn)品方向等短期難以解決的問題，會留檔，等待合適的時機進行解決。為了防止短期內(nèi)沒有解決的問題被時間所遺忘，我會安排周期性復查，比如在半年的節(jié)點上，復查這半年的驗收文檔，對問題進行跟蹤整理，適合近期進行優(yōu)化的推進優(yōu)化解決，短期內(nèi)還是沒法解決的再進行備注說明。這樣體系化的全生命周期的驗收，就可以保證產(chǎn)品穩(wěn)定的質(zhì)量呈現(xiàn)。明確基礎驗收流程
建立驗收文檔 —— 驗收問題錄入 —— 同步 & 溝通驗收問題 【確定問題優(yōu)先級&跟進機制】 —— 過程中跟進調(diào)整情況 ——— 上線前復查 【配圖】一.建立驗收文檔
有些團隊內(nèi)部協(xié)作習慣于直接口頭溝通，面對簡單且量少的問題時比較快速，但是也存在信息遺漏、溝通誤差等問題。所以建議每次設計驗收時先建立驗收文檔。如果團隊共同使用線上協(xié)同工具，那么驗收記錄留檔和信息同步都能及時有效進行；如果沒有團隊協(xié)作工具，可以自己使用在線或本地文檔工具，比如石墨、語雀、 Pages 等。建立文檔時也需要按照一定規(guī)則，方便后續(xù)查找，比如命名按照功能、模塊、時間順序等。隨著文檔的增加，為了方便進行管理，可以建立一張驗收文檔管理表，記錄單個文檔的基礎情況。有些團隊分工較細，交互設計師和視覺設計師會分別建立驗收文檔，在我們的團隊協(xié)作中發(fā)現(xiàn)共同維護一份文檔比較高效，只需要在問題類型中進行交互、視覺的分類即可。二.驗收問題錄入
設計師在對最初的設計輸出和設計實現(xiàn)進行比對時，往往會發(fā)現(xiàn)與最初設計意圖有出入的地方，建議將差異點都作為驗收問題進行錄入，在后續(xù)溝通跟進弄清緣由的情況下，再去判斷是否列入驗收問題。驗收問題錄入的過程，實際也是對功能的二次思考，在這過程中真切驗證原先規(guī)劃的操作路徑是否真的易用。有時也會在錄入過程中，發(fā)現(xiàn)需要增加延展的能力，那么也是可以錄入并備注，為未來的體驗優(yōu)化積累突破點。三.同步 & 溝通驗收問題
驗收問題常常會涉及多個崗位團隊成員，比如前端、后端、運營等，如果是團隊使用在線協(xié)作工具，在問題錄入的同時設計師可以先做好原因預判，立即 @ 相關隊友，在正式進行溝通之前，能夠給相關隊友預留一些排查原因的時間。在一次設計驗收完成后，可以依據(jù)整個驗收文檔，與相關隊友共同溝通驗收問題?？梢哉偌嚓P幾位隊友直接溝通，或者召開會議。在溝通的過程中，通常需要復現(xiàn)問題，判斷原因，以及確定跟進優(yōu)化的負責人。同時會根據(jù)問題的影響程度、調(diào)整難易程度、資源配比程度，綜合判斷各個問題的優(yōu)先級，再根據(jù)優(yōu)先級進行排期調(diào)整。設計師在排定優(yōu)先級時需要遵循體驗原則，盡量保證新功能上線時以較好的效果呈現(xiàn)。這樣用戶初次接觸功能時，在首因效應影響下，會對該功能體驗抱有好感，對產(chǎn)品整體體驗也會給到好評。四.調(diào)整跟進
驗收問題調(diào)整的過程中，對于復雜問題往往需要進行頻繁的溝通，工程師需要在過程中與設計師確認方向正確性，防止偏差導致的再次誤差。此時設計師應給予充足的支持，比如詳細解釋設計意圖，比如幫助工程師尋找類似場景的實現(xiàn)效果，比如相關組件資源等。既是團隊協(xié)作共同解決難題，同時也在解決問題的過程中了解底層原因，為預防后續(xù)遇到類似問題積累經(jīng)驗。體驗問題調(diào)整結(jié)束，依據(jù)體驗文檔，再次驗證修復情況。在這個時期，如果還遇到其他問題，也是可以進行問題錄入和優(yōu)化。制訂驗收文檔標準
標明序號 —— 定位問題范圍 —— 定位問題分類 —— 問題清晰說明 —— 差異截圖對比 —— 原因與解決方案 —— 定位負責人 —— 記錄優(yōu)先級 ——— 跟進記錄 【配圖】一.標明序號
驗收文檔支持以多種形式呈現(xiàn)，比如 word、excel、ppt 等，嘗試過多種形式后，選擇使用 excel 表格。對問題屬性、范圍、負責人等進行說明時可以單獨呈現(xiàn)，很容易最終進行分類整理。比如復查時，可以拉取一段時間的驗收文檔，整理后可以知道視覺問題占比 10% ，那么視覺還原程度還是不錯的。比如渲染模塊問題占比 20% ，那么說明這個模塊下還需要集中進行優(yōu)化調(diào)整。確定呈現(xiàn)形式后，可以在文檔中標明序號，方便后期整理。二.定位問題范圍
驗收問題影響范圍往往并不相同，比如影響當前功能、多個功能、當前模塊，也有些問題涉及產(chǎn)品全局，甚至還有些問題會涉及公司其他產(chǎn)品線，此時需要說明清楚。工程師在修改問題時就可以針對該范圍進行問題解決，防止解決問題覆蓋面太小，產(chǎn)生遺漏。而涉及到公司跨業(yè)務線的問題時，可以 @對應負責人，進行溝通解決。三.定位問題分類
在酷大師驗收過程中，通常遇到的問題分類為：交互類問題、視覺類問題、運營類問題、技術類問題、產(chǎn)品方向類問題 等。相關人員通常會直接關注對應問題，幫助高效處理。四.問題清晰說明
清晰描述問題，盡量具體，避免類似于 “不符合” 、 “不好看” 、 “與設計稿不一致” 等主觀籠統(tǒng)的概括；提出問題的同時盡量說明解決方案，當然有些方案設計師能夠直接給予，而有些涉及其他崗位時就可以 @ 隊友進行解決方案的描述。五.差異截圖對比
將設計稿與開發(fā)界面進行截圖對比，標注出差異問題點，幫助相關隊友快速直觀理解問題。有些情況下截圖不能說明清楚操作過程中的問題，也可以采取錄制 gif 的方式，演示操作行為。六.原因與解決方案
通常問題涉及的相關人員會在這個區(qū)域進行跟進說明，比如造成當前問題的原因、解決方案、排期等。七.定位負責人
八.記錄優(yōu)先級
優(yōu)先級的評定可以有多種維度。通?？梢灾苯幼雠袛嗟木S度有兩個，易于調(diào)整的問題優(yōu)先級較高，對完成功能影響大的問題優(yōu)先級高。其他維度可以根據(jù)具體產(chǎn)品，與團隊共同進行分析，總結(jié)其中的規(guī)律。九.跟進狀態(tài)記錄
主要集中于對問題解決情況的跟進，通常分為已解決、跟進中。其他思考
為了實現(xiàn)產(chǎn)品高品質(zhì)在線，除了在研發(fā)實現(xiàn)后落地系統(tǒng)的驗收機制以外，設計師可以在很多環(huán)節(jié)發(fā)揮作用：1.設計稿本身的高標準輸出，考慮清楚開發(fā)成本和可實現(xiàn)性；2.交互評審環(huán)節(jié)盡量解釋詳盡，與相關工程師達到理解上的一致；3.開發(fā)過程中參與溝通，幫助工程師先做一波問題的排除；4.出現(xiàn)問題幫助促成解決，包括跨團隊資源的收集、組件支持之類；5.明確產(chǎn)品設計還原度對于用戶體驗的重要性；6.以多種方式邀請合作伙伴參與到驗收環(huán)節(jié)中，比如 bugbush 、專家走查、可用性測試。
歡迎大家關注三分設，每天分享優(yōu)質(zhì)設計、創(chuàng)意靈感、新知新識，定期大咖老師直播分享，零距離連麥，答疑解惑。
