2016-9-1 濤濤
“以用戶為中心”的體驗設計理念已深入人心。但在實際工作中，作為用戶研究員，時常會碰到這樣的情況，“這個調研需求比較急，這周就要進入開發了，必須這周之前出結果”，或是這樣的反饋，“設計和用研好像結合得不夠緊密”。摸索下來，對用戶研究本身，我歸結到一個問題：設計用研還不夠敏捷。今天我們就來聊聊這個問題，以及嘗試的解決辦法。
為何提出敏捷設計用研？
這里所談的敏捷用研，主要是設計用研。什么是設計用研？設計用研是我根據用研工作與業務迭代周期的獨立關系，以及我的實際工作情況和經歷來粗略劃分歸類出來的。在此之前，先來說說目前互聯網企業普遍采用的敏捷開發流程。
敏捷（Agile）開發的理念源起于2001年，是一種以人為本、迭代、循序漸進的開發方法。敏捷開發流程包含了一系列小的迭代周期[1]。每個迭代周期3~4個星期，甚至更短。它改變了之前傳統的瀑布流開發相對僵化、低效的協作方式。從一般的流程上看，用研環節并不在既定的敏捷迭代業務流程中，并沒有預留固定的周期和時間給到用研。
而設計用研一般就是發生在業務迭代周期內的。通常是，在產品經理和設計師針對要做的產品需求和功能點進行需求分析和設計討論的過程中，會凸顯一些問題和爭議，還有一些拿捏不定的設計細節問題。例如，這個新功能在產品中的主入口該如何設計，功能流程上應該如何設計？設計用研即是需要在這個產品需求進入業務迭代的快速滾動之前，通過調研和分析，一起解決這些問題和爭議，因而與迭代周期密切相關。
相比，用戶研究工作的其他兩類對迭代周期的依賴性相對較弱。一類是基礎用研，是基于某些通用性的基礎問題進行的研究，或是針對某類產品的戰略和方向性研究，是在產品迭代之前的探索，重要而不緊急，本身就獨立于業務流程和產品周期之外。例如，現今時常被提及的90后人群研究，或是為某產品探索契合的生活服務行業研究。另一類是產品用研，是針對已上線的產品的實際使用和反饋層面進行調研，用研結果可能會作為評估產品的指標之一，同時也會探索產品后續的需求方向。通常也有時間和空間給到用研，可以跨越一定的迭代周期進行。例如，常見的滿意度調研。當然，用戶研究工作不只是以上三類，這里只是對設計用研做個簡單界定。
傳統的用研從立項規劃、招募用戶、執行調研、分析數據到撰寫報告，整個過程需要一段較長的時間，而敏捷開發流程則對縮短設計用研的時間長度提出了要求，因而看起來似乎存在一定的矛盾。洽洽因為這樣的矛盾，在實際合作中，設計用研的需求可能更少地被提出。設計用研的敏捷之道，就是基于上述問題而進行的嘗試和探索，目標是縮短用研的周期時長，而同時又能將用戶導向的需求和反饋有效融于產品設計，并按期落實在迭代流程中。
怎么實踐敏捷設計用研？
1.對工作模式的思考
縮短用研的周期時長，首先應該是盡早發現和提出產品設計中的問題。由于用研不在開發流程中，用研的工作模式，特別是新手用研，常常是乙方模式——產品經理或設計師提出用研需求，用研根據提出的需求進行規劃和調研。這種模式下，通常是產品經理和設計師經過幾輪討論，發現遇到的問題無法通過已有資料和現有經驗分析清楚，需要用研的參與和介入。用研需求提出的時間點可能已到產品設計中期，這樣在既定產品需求開發計劃下，用研時間就顯得很緊迫。用研中途參與，對需求背景的熟悉和了解，以及對需求本身的深入判斷，可能有一定的限制。
敏捷設計用研，需要用研化被動為主動，將乙方工作模式轉變為參與式工作模式。在心態上，需要轉變。對待產品的態度，并不是“我是支持這個產品的用研工作”，而是“這個產品是我做的產品”；工作的動力，并不是“為了完成用研項目”，而是“為了做出更好的產品”；角色定位，并不是“我只是用戶研究員”，而是“用戶研究和體驗設計工作”。
參與式模式一方面是用研全過程參與產品研發過程，與產品經理、設計師、開發等團隊成員進行密切的溝通協作。如此，用研可以從討論中主動發現產品和團隊所面臨的問題和困惑，而非被告知，因而可以盡早展開研究和分析。參與式模式另一方面是團隊成員也參與到設計用研中來，包括前期規劃、調研執行、數據分析和結果討論。用研需求來源于產品業務，用研結果落地于產品業務，用研過程該是開放式和參與式的，相關實踐經驗下文具體講。
參與式模式，說起來簡單，實踐起來卻需要花費大量的努力，還需要團隊的支持和配合。實踐敏捷設計用研，首先必須練就深厚的用研專業功力。為能夠參與到產品研發全過程，與產品經理、設計師、開發等不同角色進行較好的溝通協作，還需要掌握用研本專業之外的知識和能力，包括產品能力、設計能力，甚至開發能力，需要不斷補足和修行。
2.相應流程機制
敏捷設計用研必須形成有效的機制。設計用研主要是圍繞如何設計這個產品或功能而開展的，因此，核心是將想法和概念通過設計和原型呈現給用戶，得到快速反饋，檢驗與用戶行為模式、心智模型是否相匹配 ，再進行修正優化。對比敏捷開發流程，這其實是未付諸開發前的低成本的敏捷設計流程。在這樣一個流程中，用研是組織和牽頭的角色。
灰度放量常常是敏捷開發流程中的一環，灰度用戶調研也可以成為設計用研的一環。有些產品和功能，必須是結合線下使用場景和業務觸發的，前面的概念設計用研階段可能也難以發現一些實際使用情況下的問題。通過灰度發布和調研、灰度數據分析，可以了解用戶真實使用產品后的反饋和評價。
對于每個迭代都要進行的用研，如版本發布前的可用性測試，可以進行流程化建設，形成機制融入項目流程中，成為其中的一個固定環節。以版本發布前的可用性測試流程化建設為例，可以進行流程化的有：執行時間點和周期、可用性測試操作任務的制定、測試用戶招募、問題發現與記錄、問題跟進和解決等。這些一旦流程化，可以調動團隊一起來進行分工協作，而不單單只是用戶研究員的事。
3. 實踐經驗和思考
基于上述工作模式和流程機制，在實踐中，要實現敏捷，用戶研究員首先要具備過硬的專業能力和的執行力，才能在設計用研的每個環節快起來、游刃有余。
設計用研以定性用研為主。敏捷設計用研，我總結有3個準則：響應變化高于遵循計劃，有效溝通高于完美報告，以人驅動而非文檔驅動。接下來就用研的不同階段，說說我的一些敏捷用研經驗。
立項規劃參與式模式下的設計用研，由用研或團隊一起提出問題和用研需求，已然省去了反復溝通需求背景和目標的過程，從而縮短了立項規劃的時間。
“工欲善其事，必先利其器”，在規劃準備階段，還需有合適的工具。在上述設計用研流程機制中，原型工具是比較重要的一環。
就可交互的移動原型工具，如果是在較為前期的設計方案階段，主要用于呈現頁面結構和關系，以了解用戶對產品或功能設計的整體認知和反饋，目前我們常用的是 Prott。在 Prott 中，上傳產品頁面，設置頁面間的點擊熱區和連接，輔以設置頁面切換動畫，就可以得到快速原型。
如果是到設計中后期階段，主要用于呈現細節功能的操作和體驗，以了解用戶對實際設計方案的反饋，目前我們常用的是 Pixate。 Pixate 需要對不同細節模塊設定交互和動畫，使用上相比 Prott 要復雜一些、耗時一些，因此我們主要用于細節功能模塊的完整呈現。
招募用戶通常我們會邀請第三方中介來幫助我們招募，招募用戶時間會受到第三方中介對需求理解度、資源范圍等因素影響，因而時間上不完全受控。所以找到一家資質好、穩定的、可以長期合作的第三方很重要。
其他可行的替代辦法，一種是建立自己的產品用戶庫，有需求時可以直接從中篩選和抽取進行自主招募。也可以根據具體產品情況，在社交平臺上用產品官方名義進行調研招募。例如，一次針對在華外籍用戶的調研，我們在 Facebook 進行了自主招募，利用 Facebook Ad 發布招募信息，并從報名問卷中篩選出有效用戶，在短時間內就完成了用戶招募。對于一些簡單方案的測試，我們還可以采用就近用戶測試。所謂就近，就是在我們身邊的用戶，根據具體用研需求和情況，可以預調研周圍同事朋友，可以邀請公司內部用戶，可以攔訪工作園區的伙伴。
另外，在敏捷設計用研中，招募也可以成為調研的一環，既招募用戶，同時又先進行某些問題的摸底。招募時不明確給出要求，而是設計招募問卷以報名篩選的方式，在招募問卷中加入需要預先進行摸底了解的問題。招募先行，摸底后可調整調研。
研究執行在調研執行過程中，可以邀請團隊成員，包括產品經理、設計師、開發一同來訪問和觀察用戶。一場調研完畢就可以第一時間討論發現的問題和對策，甚至可以產生新想法、新方案，而微調后續調研計劃和方案。在敏捷設計用研執行階段，比較鼓勵及時有效溝通和響應動態變化，而非按最初計劃一成不變。
另外，在方法運用上，結合實際情況，有可能的話，可以多采用圖譜的方式，將研究過程可視化，便于團隊后續一起進行分析。
數據分析定量調研中，我們可以將常用的數據分析模塊進行公式化或編程代碼化，這樣下次統計分析可以繼續使用，減少分析時間。
針對定性調研，建議可以將用研記錄上墻分析（圖3）。通常詳細的用戶調研記錄是調研的中間環節，用戶研究員一般是自己分析，然后將分析結果在最后的報告中呈現，調研記錄最多作為郵件附件，但很少有人會去詳看它。將用研記錄貼上墻后，可邀請團隊多角色一起來進行分析。上墻后的調研記錄鋪陳總覽、橫縱對比，相應重點可以用彩筆進行標注，多角色討論分析的思路可以用便利貼記錄貼在一旁。這樣分析就打破了用研獨自分析的困境，而且快捷有效。
結果推動參與式模式下的設計用研，并不等到寫好完整報告再來和團隊進行匯報和溝通，再推動落地，而是在用研的每個階段都會和相關人員密切溝通和討論。敏捷設計用研過程是開放的，除了一起參與調研、一起討論分析，每日進度、結果溝通和快速輸出也必不可少。在用研中間階段就可以開始推動部分結論的落地。
在時間有限的情況下，有效的溝通遠比一份完美的報告來的更重要。報告可以有多個版本，根據時效性要求，分別輸出快速小結版報告及陳述研究分析和結果的完整版報告，用于匯報和演示時，可以調整成演示版報告。
為快速有效地溝通結果并推動落地，需要依靠的是人的驅動，而非文檔。在和團隊溝通研究結果的場所，基于之前的上墻分析，可以選在進行研究分析的房間里，通常我會選擇在體驗室內進行分析和溝通。這樣的好處在于，可以直接用快速小結版報告結合貼出來的記錄和分析進行溝通，縮短研究產出到匯報的時間，即使是之前沒有參與調研和分析的團隊成員，也能再次進入研究情境，回顧研究分析過程，更好地理解研究結果。正是這樣的緊密合作和溝通，在參與式工作模式下，用研結果也能更好地落實。
4. 注意點
設計用研的敏捷之道，不只是為了快而快，而是快速有效地解決產品需求和設計問題，打造好的體驗。在一味追求快的情況下，往往會發生疏漏、缺少全局思考。敏捷設計用研需要追本溯源、眾覽全局、向后鋪墊。
較多的設計用研需求提出是要去了解下這個新功能的概念設計反饋，此時用研應該跳出設計本身，回溯到考察用戶場景、行為模式和心智模型來去考量現有的產品設計。
不僅要關注當前設計的這個新功能，還要跳出這個新功能，思考新功能和已有功能之間的相互影響，如何聯動。如何吸引用戶來用這個新功能，功能的使用背后是否需要改變用戶固有的行為習慣，如何引導這種變化。除產品功能設計和體驗本身外，運營、市場、技術等其他方面還可以做些什么。這些都可以納入研究分析的框架中。
在功能設計階段，用研還需要進行數據埋點規劃和建設，作為迭代需求聯合產品經理一起提出，為功能上線后的數據分析和用研作鋪墊。
結語
設計用研的敏捷之道，是從用戶研究員的角色出發，針對項目迭代內的產品設計，為達成促進團隊內合作、增強用戶導向理念在產品中落實、提升產品用戶體驗這個目標而進行的實踐。換之，站在產品經理、設計師等其他不同角色的角度，如何踐行上述這個目標，也是值得進行探討和思考的話題。
參考資料
[1] https://en.wikipedia.org/wiki/Agile_software_development
[2] https://prottapp.com
[3] http://www.pixate.com/education/demos/news-digest
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
