使用者研究報告實作經驗分享
哈囉各位UX四神湯的讀者們大家好，這次想跟各位分享的是在撰寫使用者研究報告時的一些經驗與小技巧。一直以來，筆者都很想分享這篇文章，無奈的是這個主題實在是很不好寫，也需要更多的沈澱與思考，所以之前一直都還在醞釀中。如今總算是有形成一些粗淺的想法，因此期望與各位分享，希望能為各位研究員帶來一些啟發。
在開始分享研究報告的經驗分享之前，筆者想先分享使用者研究員產出文件的種類，這幾項文件的撰寫也是筆者認為身為一位初級研究員所需具備的最基礎能力：
1. 研究計劃 Research plan
通常也會作為專案啟動 (kick-off) 的文件，該文件會清楚的說明專案背景、研究問題與目標、預計時程、研究方法的選擇、樣本篩選與預計產出的形式。如果是乙方公司的話通常還會有專案團隊的人員與能力簡介。
2. 訪談/座談會大綱 Discussion Guide
在訪談/焦點小組討論之前應該要準備好的文件，引領團隊中的研究員執行研究。
3. 研究報告 Research Report
研究執行結束後將研究結果總結而成的報告。
在上述的三類文件中，筆者認為最容易寫的是訪談/座談會大綱、接著是研究報告，最後才是研究計劃。研究計劃之所以難寫是因為在撰寫研究計劃時不僅需要對各種研究方法都非常熟練之外，還需要了解不同研究方法的產出形式與限制，並且基於這些研究方法的執行去預估專案時長與人力配置(也因此可以預估大致的專案成本)。因此，能夠寫出好的研究計劃，就代表一位研究員已經對研究專案有最基礎的全局觀了。
本文只針對上述三類文件中的第三類研究報告進行經驗分享噢~
*至於研究計劃的撰寫的話，筆者會專門寫一篇文章為各位講解*
- 內容架構
首先，研究報告的實作分享從研究報告的內容架構開始講起，以下為筆者自己撰寫報告時所採用的內容架構：
- 執行摘要 Executive Summary：
大約會控制在3–5頁slide內。大概就是用3–5頁slide把整篇研究報告的重點精華講完。筆者通常會用列點的方式呈現，並且在每一點/句中都會提到研究發現(使用者的行為或價值觀等)，原因(使用者有該行為或價值觀的原因)，以及該研究發現對團隊的影響(比如團隊因此可能需要改善/新增什麼功能等等)。
執行摘要是整篇報告中最難寫的部分(真的有寫過的人就會知道惹QQ)，筆者通常是等研究報告全部撰寫完畢以後才會開始寫這個部分。
另外，有一個小撇步介紹給大家，如果要檢視自己的執行摘要寫得好不好的話，可以試看看自己是不是在講完執行摘要以後，接下來在報整篇研究報告的時候都一直不斷地覺得“這我剛剛已經講過了”。如果是這樣的話，那麼恭喜你，你的執行摘要寫得很好噢！ - 研究目標與背景 Research objectives and background
把專案的背景講清楚，在什麼樣的情況下，哪個團隊遇到了什麼問題，因此而開案，研究的目標又是什麼，能怎麼幫到團隊，研究產出的價值在哪裡。特別注意的事情是，在甲方的世界中，應該有不少研究案是延續之前的研究再繼續往下做的，如果是這樣的話，也應該要在這個階段將之前的報告附上來。 - 產品介紹 Product Introduction (and UI)
由於完整版的研究報告應該要適用於任何人都能夠輕鬆閱讀，因此筆者通常會在完整版的研究報告中將產品的基礎介紹也都放進來，以利未來任何人(如新進員工等)閱讀。呈現的形式通常會跟設計報告有點類似，如下圖。如果有需要的話，也可能會單獨highlight產品中的功能/按鈕，並且附上詳細的解釋。
- 受試者 Participants
在受訪者這個階段的話，筆者習慣先闡述目標用戶，然後說明基於目標用戶去設定的採樣(sampling)條件與招募管道(recruiting channel)，以及最後受訪者的profile，筆者通常會用表格呈現，然後會解釋一下各個受訪者在受訪的時候的狀況。比方說如果研究的專案是IoT (Internet of things)的話可能就會提到說某些受訪者在科技公司上班，公司的狀況，因此他的意見可能比較前沿或是有一些偏見等等的。 - 研究主題/研究方法與研究素材 Research topics/methods, and materials
另外由於同一專案的執行可能會包含多個研究主題並且運用到多種研究方法，因此筆者也會在正式的報告中依據各個主題簡單說明研究方法與執行步驟，另外也會附上部分的研究素材的截圖在此階段。
至於研究素材詳細的內容的話筆者通常會附在附件appendix中，將每個階段所運用到的所有材料包含問卷設計的內容、訪談大綱、訪談大中所使用的材料等等的素材分門別類整理好。在附件中的內容是為了幫助未來公司內其他研究員要延續進行研究工作所做的整理，如果公司內有比較好的文件/知識管理系統的話，也建議各位研究員將這些文件備份在系統內並且在報告中附上連結，方便公司/你進行知識管理。
(就是說你離職的時候才有機會負責任、好好交接後再離職的意思，請不要離職後就黑掉啊各位。) - 研究限制 Research limitations
接著，很重要，但是卻經常被忽略的一環-研究限制。任何的研究都會有研究限制，不論是研究時程的限制、研究方法本身的限制或是採樣的限制，都會大大影響研究結果的判讀，真實的呈現研究限制是所有研究者的工作。筆者個人認為研究限制應該要在團隊成員開始閱讀研究結果之前就先行說明，一方面可以控制團隊成員對研究結果的期待，二方面也幫助各位成員在聆聽/閱讀報告之前就先了解研究限制，最後則是體現研究員的敬業、對研究結果負責任的態度。 - 研究結果Research Findings
研究報告的重頭戲，撰寫研究結果的小技巧會在以下篇幅說明。 - 討論/下一步 Discussion/Next Step
討論也是筆者認為非常重要的一環，如果研究員在研究的過程中有發現任何其他值得研究的議題，或是發現一些可能會涉及到產品策略方向改變的洞察時，筆者非常建議研究員在研究報告的最後帶領一場討論，將討論的議題寫下來，並且在討論結束後將討論結果記錄下來補回去報告當中。另外也建議各位研究員將後續行動項目(action items)逐一列點下來，並且如果可以的話也可以將負責人owner寫下來(hen重要！！！)幫助團隊進行接下來的工作事項。 - 附件 Appendix
2. 研究報告也會有版本控制(?!)
是不是！有多人協作的話就有版本控制！…不要以為下述的這些事情
“research report_v7_final”
“你改了什麼?把你改的那些地方用紅色的標起來”
“你坐我旁邊，我們一起merge檔案才不會出錯”
“啊! 這個東西沒改到…”
“你改的不是最新版…”
“你用ppt?!，不是說好的用keynote!”
“誰誰誰沒有keynote所以只能轉檔成ppt，格式全部跑掉了…”
就不會發生在研究員身上(抱頭淚奔)…
Anyways，版本控制又分為個人的版本控制與團隊的版本控制，還有場合(如向高層匯報、向團隊成員匯報)的版本控制。
先來談場合的版本控制
在筆者上述的內容結構中，基本上已經具備兩個版本的內容了，第一個版本是研究報告的完整版，另外一個版本是專門給高層主管的版本，也就是在完整報告中執行摘要Executive summary的部分。
通常研究報告完整版的話，通常筆者會控制分享的時間在2小時內，而如果是只需要分享執行摘要的話，分享的時間會控制在15分鐘左右。通常筆者不太會再製作第三個版本的報告了。如果有1到1.5小時的分享時長的話可能會跳過部分的內容(比如產品介紹等細節都快速帶過)。如果是在1小時以內的分享的話，筆者會以執行摘要作為基礎，再從完整版的報告中挑一些重要的slide輔以報告。
再來，來談個人和團隊的版本控制…
除了大家用相同的工具或是用可共編的工具之外，標好改動的地方，合理不重複的分配工作都是團隊在建立時就最好先規範好。
而從內容來說的話，筆者通常會把“匯報用”投影片和“閱讀用”投影片作為相同格式，然後先寫“閱讀用”投影片，寫完以後再把部分的內容刪掉後就直接變成“匯報用”投影片，並且將“匯報用”投影片放在“閱讀用”投影片的前面，這樣一來，只需要透過隱藏投影片就可以做到不同用途的版本控制。
舉兩個例子：
例子1：假設以下這張投影片為筆者想介紹在某一情況下共分有三種類別，筆者會先寫好以下這張投影片，作為“閱讀用”投影片。
然後再把文字刪掉，調整一下投影片內容的位置後，形成“匯報用”投影片，如下：
然後在報告中使用“匯報用”投影片，並把文字內容都用口述的講過後，再讓大家看“閱讀用”投影片，告訴大家說剛剛講過的內容都有寫在各項類別的下方，大家如果想讀的話可以再自己讀。
延續剛剛的投影片，來看例子2：
這是另外一種形式，當筆者介紹完三個分類以後，如果每個分類底下又有各自的細節內容的話(如圖中右下的分類1中的細節1)，筆者可能也會將本來的分類1的原文保留，並且放在左邊，將分類1中的細節1介紹清楚，形成“閱讀用”投影片。
然後再把重複的內容全部刪掉(比如圖上方的重點/結論跟左側的分類1的介紹刪掉以後)，就形成了分類1的細節1的“匯報用”投影片。
筆者透過這樣的方法做個人或是團隊的版本控制，效率算是滿高的。在撰寫的過程當中，不論是只有一位研究員，或是多位研究員都只需要專心撰寫“閱讀用”的投影片，等到最後要報告之前再把內容刪刪減減或是隱藏投影片就好惹XD。
3. 使用者研究報告的原子設計、報告架構
說到上述的例子，有些經驗的研究員應該已經發現上述圖中的“閱讀用”的投影片中有用到原子設計(atonomy design)的概念，也會發現在筆者所說的“閱讀用”的投影片的背後，其實是需要有研究報告架構(architect)來支撐的，要不然筆者所說的先把“閱讀用”的投影片寫完，然後刪刪減減就能變成“匯報用”投影片的美好合作模式是不太可能成立的。
3.1 使用者研究的原子設計：
如果是第一次聽到原子設計的小夥伴，可以參考UX四神湯另外一位作者Shandy所寫的文章：
和設計一樣的概念，在研究報告的撰寫當中，也有基本的元件(component)，比如在講使用者洞察的頁面中，基本必要的元素包含了
- 標題或分節
- 洞察敘述
- 佐證洞察的證據，如使用者的代表頭像(可以使用插圖/icon)、語錄(quotation)、使用者正在做該動作的照片或影片、照片/影片說明、統計圖表、統計圖表說明等等元件
而模板的話，在報告中會出現的基本模板(Template)比如：
- 受訪者列表的模板
- 產品介紹的模板
- 使用者旅程模板
- 分類模板
- 設計建議/機會
另外，標題的字體大小、使用者語錄的字體大小、圖片大小與排版、投影片扉頁的視覺設計等等的，都是可以被規範或模組化的。
透過原子設計的概念，研究員彼此可以加速研究報告的產出速度，也可以讓多位研究員在共同撰寫同一篇研究報告時利用不同的元件填入該專案中的洞察，減小初級研究員的負擔，並且最終合力撰寫出一份研究報告。
而研究案的研究負責人(Research Lead, research director, project director, senior)也應該要具備使用者研究的原子設計的概念，引導各位初級研究員或是實習生在研究執行的過程中收集相對應的資料，才不會在寫報告的時候才發現資料缺少的情況噢！(比如筆者以前就經常犯下在研究的當下沒有拍到使用者行為的照片，導致在撰寫報告的時候只能用口述的，十分扼腕QQ)
3.2 使用者研究的報告架構(architect)：
研究報告的架構就像設計介面時也一樣需要考慮資訊架構一樣，應該要及早考慮。事實上，資深的研究員在撰寫研究計劃或是訪談大綱/座談會大綱寫完後就應該對研究報告的框架有模糊的雛型了。
接下來筆者跟各位分享幾個筆者在架構研究報告的小撇步。
3.2.1 全局觀的架構
一般來說，筆者的會先從全局觀開始描述，而筆者架構全局觀的方法通常會使用MECE的思維方法，另外一種則是利用使用者旅程(user journey)來闡述全局。
先從MECE (Mutually Exclusive Collectively Exhaustive)開始說起，MECE是麥肯錫咨詢顧問Barbara Minto所提出的分類方法，可以解釋為一種思維模式。中文的意思是“相互獨立，完全窮盡”。 也就是對於一個議題做到不重疊、不遺漏的分類方法。
透過MECE的分類方法，可以很輕鬆的利用幾項分類架構出全局觀，並且在接下來的報告中逐一解釋各項分類，即可寫出一份“面面俱到、鉅細彌遺”的研究報告。
另外，也可以利用使用者旅程來闡述全局，使用者旅程這個方法背後隱含的是End-to-end的思維，從開始到結束，每一個步驟都不忽略的思維方式。不過，要用使用者旅程這個方法之前，筆者個人真心的建議先去找找看該企業或是該行業有沒有既定的end-to-end流程的架構，如果有的話，建議沿用行業標準，會省去很多名詞解釋的溝通時間。
另外，值得注意/小心的一點是，通常使用研究員自行建立的使用者旅程時，最容易遇到的問題就在於“步驟的顆粒度”。舉個例子，常見的狀況是同一個使用者旅程，有的研究員會分成五個步驟，而有的研究員可能會分成七個步驟，這就是筆者所說的步驟的顆粒度不同。而且對於各個步驟的定義方式也不盡相同，常見的區分步驟的方式是依據使用者的意圖(intent)，不過也有可能透過頁面切換、功能使用作為步驟區隔的依據。
最後一句題外話，筆者很真心的給各位研究員的求職者，不論是應甄實習生或是初級研究員，請不要再使用網路上或是課堂上給的使用者旅程的制式表格，並且用字體只有5或是8的投影片然後像用表格的方式填寫後形成一張超大表格，並且在面試時呈現這張超大表格，告訴面試官說：「我有做研究！」，說完後就沒有準備後續研究成果的present了…。強烈建議各位要把內容拆分出來，並且做成一張張“可讀”且有“洞察內容”和有“洞察證據”的投影片來闡述各位的研究報告啊…
3.2.2 Storytelling的練習方法
在架構好全局觀以後，開始可以逐步地一條條的闡述研究的細節內容，在開始闡述細節內容時，可能會開始遇到下面這個問題
“這件事情跟這件事情有關係，但跟另外一件事情也有關係。怎麼辦，要放在哪一個部分跟著哪件事情一起講比較順呢？”
通常遇到這樣的問題的時候，並不是一開始的全局觀架構的不好才造成事情和事情之間有部分重複的狀況，而是“世界上的大部分事情往往真的都是環環相扣的”而產生的，也因此，在諮詢界中，大多數人在遇到這個問題時，利用了“storytelling”的能力來解決這個問題。
那麼，怎麼在研究報告中呈現Storytelling呢？
首先，我們可以看回來剛剛筆者所提供的這張圖，在這張圖中，筆者有留一個區塊是“用一到三句話敘述整張投影片的重點/結論”，這裡就是各位研究員可以展現“故事力”的地方。
如果將非常多張的這個區塊結合在一起的話，一份研究報告應該就可以用200+句話講清楚，透過這個方式，各位研究員在撰寫研究報告時，就可以避免上一張和下一張講述的主題完全脫離的情況，並且用比較順暢的邏輯將整篇研究報告用一個故事說完。
這樣的方法也可以幫助各位研究員在撰寫每頁各種細節資料時，不會一鑽進去太深結果導致迷失的狀況。透過某一頁中簡短的結論，時時提醒自己要講的重點在哪裡，並且確認圖文相符，才能讓整篇報告中的內容層層分明、邏輯清晰且易讀。
因此，通常筆者在寫報告前，會將每一頁投影片要呈現的內容都用一句話寫出來，並且去排列這些話，藉以調整研究報告的架構，大致的狀況如下圖。
這張照片是筆者之前在撰寫某一份研究報告時的草稿紙，照片中的每一個方格都代表了一張投影片，透過這樣的方式筆者可以自己練習storytelling的能力，並且透過這個過程練習自己架構報告的能力。各位讀者也可以用便利貼來做這件事情，排列組合會變得更方便噢！
3.3.3 報告中的視覺引導
最後一個跟研究架構有關係的事情視覺引導，不知道各位UXer會不會遇到一種情況：
“聽眾在聽到一半的時候，有個mail突然進來只好閱讀，當聽眾再次專心回來時，已不知聽到哪裡”
或是
“報告讀著讀著，讀到一半去上廁所泡咖啡，然後回來以後完全不記得剛剛看到哪裡”
為了解決上述的狀況(畢竟要求所有stakeholder都專心致志地聽研究報告的分享是不太可能的事情)，筆者的報告中往往會出現一個很重要的特點：視覺引導，在報告中的呈現通常會如下圖：
通過視覺引導，閱讀的人或是聆聽的團隊成員會非常有節奏地跟隨著研究員的腳步慢慢往下聽，也可以透過這個方式讓各位收聽者跟閱讀者保持耐心的好好聽/讀完(?)
4. 幫忙跟後續的事情過橋，讓研究的影響力化為行動項目(Action items)
在筆者最一開始講內容架構時就已經有講到有下一步的這個部分了，然而要列出這個階段中的每一條action item，其實是要需要透過每一個研究洞察而衍生出的改善方案或是產品機會。
從改善方案說起，
其實，要不要在研究報告中由研究員提供改善方案一直都是一個備受爭議的話題，有的研究員會很堅持不要在研究報告的階段提供改善的設計方案，原因是因為這樣可能會限縮設計師發揮的空間，或是讓團隊一聽完結果以後就直接朝著由研究員提出的設計方案進行設計或開發，導致少了一層設計/產品全局的思考。
以下說明的是筆者個人針對該爭議的想法和做法：
如果是由受訪者提供的改善方案，如果技術可行且影響範圍不大，筆者通常會提供多位受訪者針對同一痛點/主題的多個點子，通常筆者會取名為“ideas from respondents”
筆者決定提供的原因有兩個：
1. 這些點子是受訪者的意見，如果引用參與式設計的概念，這些點子是有意義的，不僅可以幫助設計師更了解使用者的想像，也可以引導設計師的設計方向。
2. 某些痛點確實可以很直接的連結到某些解決方案，刻意的不講反而顯的太刻意了，只會引起負面觀感，而不會引發更深層的討論。
而筆者通常會在研究結果的基礎上，額外開一個pop-up window來呈現這些內容，比如：
這樣的好處是，不僅可以highlight改善的方法之外，研究員在寫完報告以後如果覺得不適合在該階段呈現這些資訊的話，也可以很快速地隱藏投影片就達到版本管理的效果。另外，競爭者分析的結果也可以利用上述的方式呈現，將ideas from respondents的標題改成competitors’ approach，並且附上競爭者的設計/服務的資料呈現即可。
另外，如果該研究結果導向的是產品/功能的新機會(opportunity)的話，研究員也應該在該洞察後補上新的產品機會相關的市場研究資料，並且將新一輪的市場研究/競品分析列為行動項目，再協助引導產品經理(product manager/owner)進行相關的研究與開發的時程安排，並且直到每一位團隊成員都開始對新的產品/功能的新機會有全盤的了解，並且順利進入開發流程後，研究員才算完成階段性任務，真正的產出了“具備影響力的研究結果”
以上，好長好長的一篇，真的4寫死我了…
也感謝持續收看落落長文章的湯粉們，感謝你們，成為我連假寫文章的動(壓)力XDDD
好吧，UX四神湯，我們下次再見囉~
