本篇文章整理分享了編制問卷和分析數據的思路,一份合格的問卷都包含了哪些內容呢?

一份合格問卷的編制思路

作爲一枚社科類專業出身的互聯網狗,編制過用於學術研究的問卷,也在工作中使用過問卷去了解用戶,問卷編制不是憑感覺羅列問題的過程,更像一個設計過程,不斷權衡問題的去留、邏輯和形式。在此把編制問卷和分析數據的思路整理出來,共兩篇,交流討論。

問卷調研大部分是抽樣調研,且填答質量在很大程度上依賴填答者/執行者的認真程度,因此得結論時很容易被diss:“你問卷那麼長誰會來答、用戶都是故意瞎填的不可信、用戶根本沒思考都是用腳在答、答問卷的都是專家用戶不能代表全體”等等。

一份合格的問卷會盡量避免這些問題以得到客觀的結論。希望讀完本文可以找到一些答案。

問題編制會受制於問卷的投放渠道,所以我們先從問卷投放開聊。

一、問卷投放

1.1 確定調研目的和投放人羣

調研方法有很多,尤其是在互聯網環境下,收集數據的手段變多了,問卷調研的優勢在哪裏,什麼情況下應該使用問卷調研呢?問卷的優點是:可以在短時間內蒐集大量的數據,且人力成本較低。在互聯網領域,使用問卷調研的場景主要有以下幾種:

(1)驗證需求強度和場景以設計出更合理的功能

工作中通過其他方式發現了一些需求點,邏輯推導可行,繼而通過問卷做個定量調研,瞭解需求的場景輔助設計。

如:地圖上線騎行導航之前有很多用戶提建議要求上線騎行功能,但是哪些功能優先級更高?最核心用戶羣是誰是外送人員麼?用戶最關心什麼信息?這些光靠猜是不夠的,通過問卷可以得到更切實的結論。

如keep在18年5月份的時候提前調研用戶對於短視頻的態度,10月的時候上線了該功能,最近又在調研live打賞功能,調研結果如何就看之後會不會上線了。

一份合格問卷的編制思路

不過在功能上線之前做調研可能會涉及到保密問題,能否做調研還需要結合整體環境來判斷。

(2)主動收集使用者的感受,不依賴於反饋系統

1. 有些功能沒有明顯的反饋渠道,用戶有想法但不知道去哪裏反饋,當設計者想要了解用戶使用情況時會缺乏參考資料;

2. 產品有明顯反饋渠道,但用戶遇明顯的痛點纔來反饋,只有一丟丟不爽的時候,一般都懶得反饋,可設計者需要了解這些“小不爽”來打磨產品;

3. 有時候產品剛上線或經過幾輪迭代,設計者不僅需要看數據,也需要了解用戶對產品的主觀感受,感知到功能沒、用過沒、喜不喜歡。

如:華爲每次更新新系統後都會發送小調研收集問題,兩個題目,一個是滿意度,一個期望改進的建議,簡單直接快速。

一份合格問卷的編制思路

(3)通過問卷招募用戶

想做用戶調研(焦點小組、深訪等),如果不通過外包公司招募,就需要自己設計招募問卷,篩選符合要求的用戶。如之前高德地圖招募用戶,主要說明活動具體事宜和關鍵的篩選因素。

一份合格問卷的編制思路

(4)瞭解行爲和場景,在大數據無法體現或獲取數據的成本太高時用

設計者需要了解用戶是在什麼樣的環境下怎麼用產品,爲後續的設計提供依據,但有些信息很難在數據上體現;比如騎行導航剛上線時,設計者期望知道用戶是怎麼用地圖的,看屏幕爲主還是聽語音爲主。系統的息屏數據和靜音數據很難拿到,因此用問卷的方式來獲取。

(5)瞭解行業、市場的情況(這類調研通常與第三方公司合作進行,國內調研公司的官網上有很多實例報告,不詳述了)

調研目的確定後,調研羣體也就明確了,關鍵是如何觸達這些用戶呢?

1.2 找到觸達用戶的方法

生活中會在各種地方遇到問卷調研:體檢單上附帶着紙質的滿意度問卷;收到航空公司的電話回訪;逛商場有人拿着iPad請你回答品牌偏好問卷;買了冰箱到貨後上面貼着滿意度調研的二維碼;郵箱裏還會收到一些網站的調研。

當用戶與服務有觸點時,可以抓緊這些觸點邀請用戶參與調研,此外還可以通過用戶留下的聯繫方式邀請用戶,對於互聯網產品也不例外。

(1)在APP/網站內投放問卷(最普遍)

1. APP內有運營位,可以在這些位置上投放傳統的問卷邀請(純文本的、banner+文本的都可以)

優點:回收量大;用戶對本APP的印象鮮活;可以通過後臺篩選投放的用戶羣體,比如通過人口學信息/設備信息圈定人羣,或通過行爲經驗圈定人羣(如:最近三個月使用過騎行導航的用戶)

缺點:低活躍羣體的觸達率特別低。

2. 還有一種短小快速的調研方式,在某個行爲之後觸發調研模塊,很適合收集特定場景的信息。不過該方法需要在包裏添加代碼,實現成本高。如搜狗地圖導航結束頁,keep中途退出課程,都會彈出調研模塊

一份合格問卷的編制思路

(2)通過聯繫方式投放,短信、郵件發送邀請鏈接;qq、微信羣、論壇發起問卷調研

1. 大量的短信投放有一定的費用成本,而且對用戶有打擾,在投放前可以先“預投放一輪”,估計一下回收量。

2. 郵件投放可能會被屏蔽爲“垃圾郵件”,因此投放出去之後要觀察一段時間,確保有回收率,如果回收率非常低,則需要考慮其他渠道。

3. 在產品的qq羣、論壇投放,來填答問卷的很可能是產品的深度用戶,該類用戶與普通用戶對產品的熟悉程度有差異,需考慮到樣本偏差。

(3)購買/置換三方渠道:

僅通過產品自身的渠道,很難接觸到沉默和競品用戶,購買第三方的渠道是常規方式,市調公司、問卷公司都有自己的問卷廣場和用戶社區,大部分都有該類服務。

此外還可以擴展多樣的渠道合作(和投放廣告是一個道理,找準目標羣體),比如想了解足球用戶的特點喜好,可以在足球類的視頻網站上掛問卷;比如招募學生羣體可以去高校的BBS上發帖;如某奢侈品APP想了解大衆對各奢侈品牌的印象,找FT網合作投放了問卷。

一份合格問卷的編制思路

1.3 確定投放時間和樣本量

(1)投放時間

投放多久主要是看渠道的回收量,等收回量夠了就可以停止了,通過聯繫方式投放等待的時間比較長,(在做調研規劃的時候要考慮到時間成本)。

如果是APP內投放,儘量選APP日活高的時候投回收更快,比如抖音明顯在節假日期間使用量更高,投放問卷就可以選週末,兩天回收量就夠了。如果問卷複雜,可以選在半夜上線問卷,在後臺監控收上來的問卷數據有無漏洞,因爲半夜使用APP的人少,即使有問題還有補救的機會。

還需要注意的一點,有些APP的使用人羣與時間強相關,就要考慮到投放時長。比如在地圖內投問卷,有很多是凌晨半夜填答的,一開始我就納悶什麼用戶大半夜的跑來答問卷啊,後來分析了數據發現兩類用戶:國外用戶、夜車司機。所以在地圖內投放的問卷,如果晚上發出去,早晨一看數據量夠了就暫停了,那樣本一定是偏的。

(2)樣本量

如果只是定性收集信息,問卷量沒有標準多多益善,如果涉及定量調研需要考慮到樣本量。

1. 只是通過問卷看大概的趨勢和分佈,只做描述性的統計,200份一般就可以分析了。比如想了解:大部分騎行用戶對於天橋、地下通道這些設施的態度,做小樣本的調研結果就比較明朗了。

2. 如果要研究細分羣體的情況(如:對於設施的態度與騎行工具有關,所以要分別瞭解騎自行車和騎電動車的用戶羣),那麼要保證細分羣體樣本量大於100,這樣做差異檢驗的條件都滿足。

3. 如果要根據樣本推斷總體就更復雜些。最直觀的感覺是:樣本量越大,誤差就越小,但樣本越大成本越高,所以在保證誤差範圍和可信度的情況下,我們可以根據公式計算出最小樣本量。

以樣本推測總體有兩種情況,一種是根據樣本值估計總體值(如:通過問卷調研,得到自行車用戶平均騎行距離是3km,通過總體推測整體的距離),這種在問卷調研中使用的非常少;另外一種是根據樣本比例估計總體比例(如:問卷中10%的騎行用戶是起摩托車,以此推論整體摩托車用戶的佔比),這種推斷使用的較多,最小樣本量計算公式如下(重複抽樣和非重複抽樣的公式不同,當總體N很大時,差異很小,這裏寫的是重複抽樣的公式,裏面各字母代表的信息隨便找本統計書都有):

實際情況中,調研又不是發表論文,不需要給出精確的樣本量和置信區間,通常都會多收集一些;大概的樣本量和置信度對比如下,做參考即可:

需要了解的一點是 ,推斷公式是基於隨機抽樣(包括隨機重複抽樣、隨機不重複抽樣)得到的,要使用該公式計算最小樣本量,前提是問卷採用隨機抽樣的方式發放,既:研究總體中每個個體都有相同的機會回答問卷。

如果不是隨機抽樣,即使達到最小樣本量也不可以進行推斷統計,在朋友圈裏或論壇裏發的調研不是隨機抽樣不能做推斷統計,在APP內發放問卷從嚴格意義上來講也不是隨機抽樣,理論上講,用戶看到問卷的概率是相同的,但在填答意願上有差異,之前的經驗發現某些人羣特質的用戶確實更愛答問卷。所以使用推斷統計要慎重,儘量分析那些與填答意願無關的內容。

(2)樣本代表性

我們要研究的問題很可能與某些因素強相關,因此在做調研時希望樣本與總體儘量接近,以避免樣本偏差導致結論偏差。如果我們已知某些因素與研究的問題有關,也可以通過一些手段去調整。

分桶發放

如果已知總體的分佈,並完全按照整體分佈抽取樣本,就是分層抽樣。比如調研用戶對全國旅遊景點的滿意度,按照旅遊景區的等級、類型等比例隨機抽樣即可。

但是互聯網環境下,很難做到隨機抽樣,叫分桶投放更合理。比如研究用戶在騎行過程中,對天橋、地下通道的態度,性別會有影響,那麼在投放前就可以區分性別投放。如果後臺不支持,則可以在問卷中增加該問題,方便後續分析。

實際調研中影響因素可能會有很多個,不能一窩蜂的都考慮,分桶成本太高,僅考慮強相關的影響因素,1~2個即可。

統計方法調整

前期無法按照比例投放,分析數據的時候可以做加權校正(後續再聊)。

二、問卷編制

2.2 設計問卷整體結構

(1)編制問卷首先得了解問卷可以問什麼,總結起來如下幾類:

  1. 定性收集使用信息,如使用產品遇到的問題、對產品的建議、期望改進點、使用場景等。
  2. 定量了解使用情況,如知曉度、使用頻率、熟悉度、使用深度、使用習慣、操作路徑。
  3. 定量解用戶內心的想法,如滿意度、功能期望、方案偏好、價格接受度、行爲原因等。
  4. 定量蒐集人口信息,常見:年齡、性別、地域、消費水平、教育程度等,不做詳述。
  5. 定量收集使用環境信息,如硬件設備,天氣信息、使用環境等。

(2)在設計問卷之前先做前期研究

如果是做定量研究,各內容之間可能有相關或因果關係,比如使用頻率和滿意度,性別和方案偏好等等,所以,在設計問卷之前先看數據、看外部相關調研、做快速的定性調研收集資料,以此提出一些假設,根據這些假設去設計問卷框架,這樣後續得到的結論更豐富,也避免遺漏掉重要的現象和關係。

如較早之前做過一次調研,整體來看用戶對於某方案的偏好差異不大,但交叉分析後發現越年輕越偏愛A方案,能看到很明顯的趨勢。考慮到年級大用戶在整體用戶中的佔比較小,所以後續做決策的時候主要考慮了年輕用戶的選擇(後來進一步研究發現是因爲年輕用戶和年老用戶的關注點不同導致的,也很有意思)。

此外投放的羣體並不一定是目標用戶,所以需要通過問卷題目來篩選,並喚起用戶的回憶。我的郵箱裏曾收到過百度統計的調研,我自己對於百度統計只是註冊過,沒用過印象非常淺。但是該問卷上來就問用戶對百度統計的感受,缺少了篩選項,導致填答者優點懵,也可能會受到不合格的問卷。

一份合格問卷的編制思路

總結起來,我自己設計問卷結構的思路

  1. 確定問卷調研的核心點,一般控制在1—3個,了使用情況、想法態度、人口信息、環境信息等。
  2. 設置篩選題目,適合回答核心題目的用戶,全體用戶、使用過某功能的用戶(用戶篩選也可以通過後臺配置)
  3. 設置衍生題目,通過前期研究或經驗發現,那些可能會影響核心題目的因素,方便更多的分析和探索

2.2 題目編制與設計

有了框架才真正開始編問卷,大部分問卷平臺都提供多種題型,還有樣本模板,很好用。以下是我自己的總結的一些點:

(1)題目篩選。問卷要儘量保持短小,按照問卷結構把想問的問題都錄入後,就開始刪題目。

檢查每個問題,問自己還有其他方式獲得該類數據嗎,如果有就刪掉問題。

檢查每個問題,是否容易回答,在看完題乾和選項之後,是否能在3秒內給出答案,如果不能就刪掉吧

檢查開放題目(填空、問答)是不是太多了,一方面問答題給用戶更大的心裏壓力,導致完成率低;另一方面問答題的答案不好分析,大部分需要人工編碼,耗時。

(2)題目樣式。題目樣式就是要儘可能清楚的表達出要問題的內容。在用語上且無誘導,無隱私、無態度。此外在編制問題的時候,有時候還會用到以下技巧:

①文本不容易描述的時候,考慮用圖片,圖片上要標準清晰視覺焦點。

②有些概念不容易描述的時候,可以先構建一個場景或例子,避開概念,幫助用戶理解/帶入我們說的事情。

如想要找到那些上報過路況的用戶,但是很多用戶分不清上報路況(事故、封路之類的)和反饋錯誤(新增地點,道路等),所以不要直接問用戶有沒有上報過路況,可以先問用戶向地圖反饋過哪些類型的問題,然後針對那些選擇了路況類型的用戶提問。

③有些問題形式較新穎,比如排序題,滑動條等。可以設計一些輔助題目幫助用戶熟悉填答方式。

④如果有較長的題幹,通過顏色突出重點詞,引導用戶的視覺焦點並防止閱讀疲勞。

一份合格問卷的編制思路

2.3 自檢&審覈

問卷編寫既考驗邏輯思維又考驗文學功底,實在是很多細節要打磨。所以問卷設計好之後,自己要一遍遍的調整,並請其他同事幫忙審覈。我在自檢或審覈問卷時,主要會注意以下細節:

1. 檢查有無遺漏題目(比如設置了抽獎,記着留下用戶的聯繫方式或賬號,有無設置測謊題目等)

2. 檢查邏輯跳轉,該隱藏的題目是否隱藏了(防止沒體驗過的用戶遇到無法回答的問題)

3. 需要用戶回憶的,選項是否需要“記不清了”(避免用戶忘記了瞎選)

4. 沒有窮舉的選項是否設置了“其他”(避免沒有用戶的選項,只能瞎選)

5. 應該互斥的選項是否設置了互斥(比如“以上均無”選項與其他項互斥)

6. 設置的選項之間是是否有交叉(防止選項交叉,導致用戶沒法選)

7. 填空題目是否設置了驗證(如手機號、填數字要明確單位,如果有必要使用例子說明)

8. 檢查用詞是否太“術語”,對用戶而言有沒有歧義(避免用戶理解歧義)

9. 檢查單選題目是否有單一答案,區分”最主要“和”主要“的差異(前者是單選、後者是多選)

10. 慎用“排序”等高級題目(因爲用戶的認知成本太高,可能導致髒數據)

11. 檢查選項是否需要隨機(避免順序效應)

此外還有錯別字、語氣詞、標點符號等等……

2.4 預投放

當問卷通過了自檢和審覈就可以投放了,如果有方式,最好做一輪預投放,看一下回收率和完成率,在真實用戶那裏檢驗一遍是否還有漏洞。

問卷是成熟的調研方式,應用在各行各業,問卷調研的編制是非常大的命題,我僅整理了手機app的調研思路,且以to C 的產品爲主,冰山一角。

本文由 @喬北一 原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

相关文章