一張圖總結如何撰寫用研報告
這篇文章轉自我的公眾號【用戶研究社】
這幾個月因為公司HC的緣故,一直由實習生承擔 助理用研 的工作,主要協助 資深/高級用研 的工作執行,也會負責一些小型的研究項目。
我們實習生的可愛之處是理論知識豐富,你說的那些方法他們都知道,並且說的能比你還頭頭是道;抓狂之處是不會用,比如訪談時原形畢露、數據分析時不結合業務、寫報告時欠缺章法。
實習生髮表過的兩篇文章《用戶研究實習生,第一周做了什麼?》和《社交電商,得從社會網路說起》,如果你有興趣的話可以看一看,是否如我說的可愛。
這篇文章,就用一張圖,總結如何撰寫研究報告。
這裡說的研究報告主要指定性的研究報告,因為定量研究的報告相對來說沒有這麼複雜,只要圍繞著通過數據發現問題——通過數據找到原因——結合業務提出建議的思路即可,有需要的話可以以後再寫。
上面這張金字塔,從下往上,是報告撰寫的順序,也就是歸納的過程;從上往下,是進行彙報的順序,也就是讓聽者帶著What、Why、How的疑問往下聽往下看。
金子塔的底部——從內容到事實的可視化梳理
首先,定性研究執行完成後,往往會有原始文字記錄、照片記錄、錄音記錄、影像記錄等一手材料,用研的洞察便是從這些原始材料開始。
但值得注意的是,這些材料並不是真的原始,往往在我們設計研究框架與訪談提綱時就已經確定了報告的主幹結構,從而我們在研究執行的過程中也是按這種既定的結構來獲取內容。
舉個栗子:
一款互金軟體在公司進行內部測試後,我們邀請了參加內測的同事作為新手用戶進行了訪談。那麼首先需要確定的即要獲取的內容結構:內測整體情況、競品經歷、選擇/創建一款跟投產品的考慮因素、選擇/創建一個組合/人進行跟投時的操作習慣、上線後推薦意願、主觀建議。
在訪談執行時,也是按照結構框架進行記錄,一般使用excel記錄,左側為結構與問題,右側空白處為某用戶的內容。
最後,在整理記錄的內容時,就按照各結構模塊依次整理。如共訪談10位用戶,則先這將10位用戶在「整體情況」上的內容進行梳理。
將梳理某一模塊上的內容編碼為「事實」的過程,就是提煉的方式。
提煉用的最多的方式就是計數,將反覆出現的相同現象作為事實1,並記為N次,將其他現象作為事實2、事實3等等,同樣計次。尋找相同的現象也是一種聚類的過程,在這個過程中,具有相同屬性的資料被歸入同一類別,並以相應的概念命名。
舉個栗子:
在某款產品的上手表現模塊,將8位用戶的內容進行歸納與計數:
事實1:無法找到維度排行、對比分析——2位
事實2:跟單及退跟規則不明晰——2位
事實3:N缺少詳細規則說明——2位
事實4:缺少資產組成——2位
金子塔的主幹部——建立在事實基礎上的論點
基於上述同一模塊上的幾個事實進行總結,即為這一模塊的論點,也是整份報告主要結論的支持論點。這個論點,可以是對幾個事實共同性的歸納,可以是對幾個事實間差異性的比較,也可以是直接綜合這些事實提出觀點。
這裡需要注意,如果是提出觀點,那麼當你在闡述觀點時,一定要明確自己所表述的內容,與客觀「事實」的邏輯關係,可以是因果關係、可以是平行關係、可以是從屬關係、也可以是推論關係。總之,不管是桌面研究,還是實地調研、在線調研,最重要的都是「事實」,我們要做的,是在「事實」的基礎上輸出自己的總結或建議。
為什麼特意說上述問題需要注意,因為回顧這兩年在指導新人寫報告時,幾乎每個新人都有提出過站在自我視點上的「假事實」結論,也就是其實並無支撐其論點的「事實」。往往每次我詢問:這個結論或建議你是如何得出的?就會出現兩種回答:
一是新人在下方所寫的「事實」,根本不適合得出這樣的結論,所以導致作為讀者的我無法得知眼前的事實和他所提出論點的關聯,這是因為閱讀時自上而下的順序是很容易檢查出邏輯漏洞(這種情況往往是新人對行業與公司業務的認知不足);
二是新人並沒有呈現支持性「事實」,而是直接跳過事實描述闡述了論點或建議(那麼這種建議是毫無價值的)。
以上是單個結構模塊在梳理時的注意問題,那麼各個結構模塊之間的劃分方式,或者說是呈現順序,也可以分為兩種方式,即論證式和組合式。聰明如你,應該已經了解各個結構模塊的劃分方式一般在最先制定研究框架和訪談提綱時已經確定了,雖然可能後面也做些調整,但是這不影響既定的思路。
我們先說論證式,它是一種演繹推理的順序。即支持論點1→支持論點2→支持論點3→支持論點4→支持論點5,每個論點之間都是環環相扣,即依託於前一論點,也支持到後一論點,往往最後的論點也是最重要的結論。
舉個栗子:某一功能使用率非常低,通過不使用這個功能的用戶來了解原因與改進方向。
支持論點1:功能認知——用戶是否知道有這個功能,他們覺得這是一個什麼樣的功能,能夠幫助解決什麼問題;
支持論點2:原因分析——既然知道這個功能能幫助解決xxx問題,不去用的原因是什麼(沒這個需求/有其他方式解決這個需求);
支持論點3:尋找機會點—— 相比於我們這個功能,用戶目前的解決方法有什麼優缺點;
支持論點4:改進方向——如何改進這個功能可以取代用戶目前的解決方法,從而提高使用率。
這種演繹推理的陳述方式,優點是步步推理,讀者接受程度高;缺點是需要大量記憶前幾個分論點,才能理解最後一個論點,如果對前面的論點產生質疑,變會影響到後面論點的可信度。
再來說說組合式,它是一種歸納推理,每一個支持論點都可作為一個單獨的建議或結論。
舉個栗子:某一電商產品的用戶流失率非常高,通過研究不同生命階段的用戶流失的原因來提出促留存方法。
支持論點1:註冊後30日未激活的用戶,可通過推薦新手專享的高補貼產品促進新手下單;
支持論點2:在首單體驗後30日內未復購的用戶,可通過優先發貨、極速退款等方式提高首單體驗;
支持論點3:一定活躍期後沉默的用戶,可通過針對目標用戶的促銷活動來提高活躍度。
這種歸納推理的支持論點,優點是可以有重點、或有選擇性的實施,每一條建議實施與否,不會對其他建議的實施產生影響;當然,就算某個論點被質疑,也不會影響到其他論點。缺點是,這些論點與其說是推理,其實更像是並列,論點之間並無較強的邏輯關聯。
金子塔的頂部——將所有分論點進行提煉
最後重新進行總結,不要照搬支持論點的內容,而是更加精鍊的提出「3個要點」,也就是三個建議(解決方法)。
為什麼說最後的主要結論要有「3個」,這是因為從心理學上來說,2個給人的感覺太少,4個則太多,所以3個數量剛剛好。那麼如果的確是一個研究體系比較複雜的報告,那麼請控制好不要超過5個。
一句核心結論——致忙碌的大BOSS
麥肯錫有個3分鐘電梯演講,大家可能都知道,說的就是要把大量的報告內容,在和需求方共乘電梯的3分鐘內介紹清楚。
而中國大多建築限高,我們一般也就30秒,萬一在電梯里碰到了大BOSS呢?
哈哈,開個玩笑,其實我在電梯遇到大BOSS時被問到是手裡的干挑面好不好吃。
其實就是一句話,在向務實又忙碌的大BOSS介紹你的研究結果時,建議先用一句話把你的核心結論推出去。
大BOSS往往最關心的是,做了這個研究,你想幹嘛?
所以,諸如「針對XXX,我想開展XXX業務/我想尋求XXX支持」等,他只要一句話這樣的結論就可以了。相信我,有興趣的話他會繼續追問的,到時再拋出你的3個主要結論。
一篇研究報告的核心結論一定要能用一句話概況,可以不寫在報告里,但一定要說的出來。
最後,不會「銷售」自己報告的用研不是好用研,如何就你的研究結果進行彙報也是一門有價值的學問。畢竟研究做的再好,報告無法獲得高層或是業務方的認同,等於無法落地,最終只能白忙一場。設計師稱這類無疾而終的設計稿為飛機稿,對我們來說其實同樣也是。
So, 需要注意的臨場問題非常多:
- 如何邀請高層、業務方來參加?
- 如何組織一場彙報?是用研來做主持人嗎?
- 遇到各種臨場問題時如何應對?(高層或業務方不按你的套路聽/開始玩手機或處理其他事情/質疑結果的真實性,比如:我發現一個用戶不是這樣的/中途有事情離場......)
- 彙報後如何調動大家討論的積極性?
- 如何獲取高層、業務方對每條建議真實的採納態度?
- 事後又如何跟進?
- 如何建立彙報的正確心態(怕出錯推給同伴去彙報/一定要展露頭角以後才能晉陞/被問到答不上來的問題該怎麼辦......)
等等,篇幅關係就不啰嗦了,有需要的話以後再寫。
關注公眾號,第一時間看新文章
http://weixin.qq.com/r/vTskPPjEP6VArbxf926v (二維碼自動識別)
https://u.wechat.com/EFY-mUFdmTpQqCkeM6EqgN0 (二維碼自動識別)
推薦閱讀:
※如何進行基於「滿足需求」的用戶研究
※用戶洞察在營銷實踐中的運用(上)
※[譯文] Dropbox Photos 可用性測試
※LOFTER、知乎、簡書web端「寫文章」功能差異交互分析
※「翻譯」Persona 指南
TAG:用户研究 |