談談B端用戶反饋體系的搭建－葉士銘的優質推薦評比

導讀：在實際的產品使用體驗中，用戶和系統時刻通過界面的交互操作和視覺呈現在保持交流。而作為系統背后的產品設計者，如何和用戶保持有效的雙向反饋，以及如何對用戶的反饋做一個體系化的回應。本文將從六個方面，對此進行深入分析，希望對你有幫助。

這是關于B端產品設計體系化設計的第二篇文章

全文同樣約9000字，閱讀大約需要20分鐘

閱讀前須知：

1. 文章有點偏學術性的設計課題研究范疇，所以可能讀起來可能會有一點晦澀。

2. 關于這個設計課題（B端產品的用戶反饋體系搭建），文章內容主要源于企業內部一次項目級別的用戶調研相關設計課題研究，嘗試將相關分散的設計點進行體系化和結構化。

3. 宏觀意義上反饋體系也是一個很大的設計命題，畢竟當用戶在產品中進行一些業務性操作時，時刻在和系統進行雙向的反饋以此形成一個溝通閉環，同樣此文的核心論點“B端用戶反饋體系”進行了必要的約束和取舍，側重在雙方明確產生反饋的機制上。

4. 文章中涉及的一些點單拎出來可能就可以寫獨立的文章，所以有一些點可能涉及并不深，看后期有沒有機會再補充深入。

5. B端用戶反饋體系的用戶研究部分，本身關于專業的用戶研究技術，水很深，作為設計師其實并不用追求極致的專業性，能夠將廣義上的用戶研究思維整合到產品設計過程中即可，當然有些點單拎出來還是能寫獨立的文章。

6. 不同于上一篇文章，B端用戶幫助體系的搭建，對于B端用戶反饋體系而言，其采用的設計手段會和C端差異性較大，以及最終反饋的信息維度相比C端會少一些，但背后的設計模式大致形似。

7. 文章肯定存在不足和沒有考慮到的地方，很歡迎指正出來，同時有興趣的小伙伴可以一起討論這個設計課題。

8. 最后希望對有緣看到這篇文章的盆友了解這方面的產品設計知識有一定啟發和幫助意義。

9.如果你有興趣進行轉載，請直接添加作者WeChat

對于B端產品，閉門造車是比較可怕的事情，直接拍腦袋和屁股決定腦袋的做法在競品都大同小異的B端市場中都會讓產品難以生存下來。

在實際的產品使用體驗中，用戶和系統時刻通過界面的交互操作和視覺呈現在保持交流，而作為系統背后的產品設計者，如何和用戶保持有效的雙向反饋，以及如何對用戶的反饋做一個體系化的回應，是這篇文章想要討論的重點。

01 文章結構

文章結構按照以下結構【收集用戶反饋的方式 -B端用戶&平臺反饋體系 -平臺內用戶反饋機制 -反饋用戶的設計形式 -平臺外用戶反饋機制】詳細說明。

先明確一下：

反饋的前提是溝通，而溝通是一個雙向的過程，為了通過溝通拿到有效的反饋，產品設計者的核心發力點需要在兩個方面，如何收集用戶反饋，以及如何對用戶的反饋做出及時回應，如何通過有效的設計手段讓使用者-設計者形成一個機制閉環，并且有動力讓這個機制持續運行下去，文章立足這幾點，從產品設計的角度出發，探討如何體系化搭建出一個B端產品的用戶（和設計者的）互相反饋的機制，間接解決如何有效衡量設計改動帶來的產品和用戶影響這一問題。

如果你作為設計師，自詡要對用戶在產品使用上的體驗負責，收集用戶對于產品體驗的反饋且主動去優化體驗是設計師有責任去做的事情。

面向用戶的產品并不是一個自嗨的系統，只有用戶投入參與到其中并將使用體驗反饋給產品設計者，同時產品設計者依靠用戶的反饋不斷完善產品，才能體現出產品設計的價值。

用戶反饋體系的搭建可以理解為運用利益相關者共同參與的共建模式，尋求用戶以及一切和產品相關人員的參與度，讓產品在批評聲和表揚聲中健康成長。

現在越來越講究設計的量化標準，不管是過程導向還是結果導向，設計方案的復盤落在商業層面其實就是一些可具體量化的用戶行為數據指標的跟蹤，B端用戶反饋體系搭建的目的也是嘗試通過較為完整的閉環來衡量整個產品的可用性和易用性。

按照分類的第一個維度，B端產品的用戶反饋體系可以分成實時反饋和非實時反饋兩種。

實時反饋一般涉及到用戶幫助體系中的客服支持系統，采用一問一答的形式（對話式）來獲取和幫助解決用戶遇到的問題，通常此類溝通形式大部分時間會花在處理用戶的瑣碎性需求層面，難以沉淀出可落地到產品功能層的用戶需求。

非實時反饋一般會存在明顯的時間差，通常在產品層面體現出來的設計形式是作為橋梁連接的作用，以接收用戶側的反饋為主，產品設計者側的反饋通常會在信息過濾和優先級排序后給到用戶側，此類反饋模式對于系統性收集用戶側需求并提煉出更優解決方案的參考意義更大，非實時反饋的設計模式也是此篇文章討論的重點。

02 收集用戶反饋的方式

對于B端產品而言，收集用戶反饋的方式一般分成兩種：

平臺內用戶反饋機制，包括用戶主動和平臺主動
平臺外用戶反饋機制，包括社交平臺反饋收集（如知乎、微博、公眾號、貼吧、論壇等收集用戶評論和用戶吐槽類信息）、第三方數據監測（現在比較主流的比如友盟、神策等，或者是內部自研的數據監測工具）、用戶調研手段（常規也是最有效的如用戶訪談、可用性測試、用戶觀察等）

這兩種形式是B端用戶溝通體系的核心組成部分，前者廣泛收集現象，后者針對性尋找原因，從現象（How）到原因（Why）相輔相成。

03 B端用戶&平臺反饋體系

用戶通過平臺內的用戶反饋機制將感受和建議傳遞給平臺，同時平臺及時做好偽反饋機制，經由平臺收集后經過產品設計者的處理，再通過平臺將處理結果傳遞給用戶（真反饋機制），為進行深度用戶反饋的收集，產品設計者通過平臺外的用戶反饋機制進行用戶研究，經過整理分析后，將處理結果通過平臺或第三方工具傳達給用戶。

對于設計師而言，針對用戶反饋體系的搭建，經過驗證比較理想的設計研究過程如下：

第一步，首先需要確定想要收集的反饋，即研究目標是什么，是需要通過用戶反饋驗證設計方案的合理性、定期的用戶滿意度調查、彌補性的問題解決調研，還是前瞻性的問題挖掘等。

第二步，搭建一個合適的用戶反饋機制，即研究手段是什么，是采用平臺內用戶反饋機制，平臺外用戶反饋機制，還是兩者結合使用。需要注意的是，在整個設計研究過程中，用戶反饋機制并不是一成不變的，可以隨著整個研究的進行做適應化調整。

第三步，進行反饋收集階段，即研究執行。

第四步，有了用戶反饋的數據后，對數據進行整理分類和過濾分析，篩選出對產品功能的體驗改進有參考意義的信息。

第五步，將已有的反饋范圍和最初研究目標所定的范圍做對比，考慮是否補充新的溝通形式來對已有用戶的反饋進行深入，直到拿到自己想要甚至超出原定預期的調查結果。

04 平臺內用戶反饋機制

平臺內用戶主動觸發的反饋機制：

用戶主動觸發的反饋機制會在用戶使用產品的整體過程中持續存在，通常表現為一個不會干擾用戶當前業務流程的常駐性小入口。通常此類機制需要搭配一套比較成熟的用戶激勵機制去實現，不然很難驅動用戶進行自發的反饋。

平臺內系統主動啟動的反饋機制：

平臺主動啟動的反饋機制通常會帶著產品設計者的目標去主動接近用戶，在用戶功能生命周期的各個階段去獲取用戶的及時反饋，一般背后會有一個比較完善的前期設計研究策略（細分用戶群體及用戶行為）作為支持，這類反饋機制由平臺依據已設定的后臺判斷來啟動，一旦啟動后，用戶的行為流程會有被打斷的風險，因此反應在前端的設計形式應該包括忽略、刪除的可選項。

用戶對產品的瞬時態度是轉瞬即逝的，平臺主動啟動的反饋機制的適度應用（包括合適的場景、合適的時機、合適的設計形式）能夠很好的表達出平臺想要解決用戶問題的態度，同時通過用戶反饋 – 發現問題 – 排查問題 – 解決問題 – 平臺反饋的良性閉環來達成用戶和產品設計者之間的有效溝通。

當然這兩者有效運行的核心也需要產品設計者提供引導和鼓勵用戶進行反饋的設計模式。

平臺內系統主動啟動的反饋機制：

和C端產品有差異，B端產品引入平臺內的系統自發啟動的用戶反饋機制是可以直接獲取到終端用戶實時態度和情感的唯一途徑。

大部分B端產品都是管理性質的平臺型系統，而管理恰恰就是反自然和反人性的，如何直接獲取到用戶使用產品時的“情緒快照”就是B端設計師需要始終關注的了，通過常規用研手段中的如用戶訪談、用戶調查的手段實際上并不能很好奏效。

平臺內反饋收集的場景實際上伴隨著整個用戶功能生命周期，也就是說大概率都是當用戶處在一些有著明確用戶目標的工作流程中時，平臺會要求用戶提供一些反饋，過程被打斷或多或少產生負面情緒是不可避免的，如何讓用戶保持相對積極的產品體驗并且提供一些符合事實的反饋也是產品體驗設計師需要思考的事情。

平臺內反饋機制的使用場景可以針對特定功能、特定流程、特定用戶或整體產品評價，如針對新功能的初次體驗反饋、已有功能的整體使用體驗反饋等，又如針對首次使用此功能的用戶，針對已經使用此產品三個月的用戶等，具體場景的應用可以結合前期的研究目標，具體想要獲取的用戶數據范圍是如何的。

平臺內反饋機制的具體設計形式：

針對平臺內反饋機制的搭建，設計形式具體表現為UI層面各種用戶反饋類組件的單獨或者組合使用。

常見的形式有：選擇型：二元選擇式、等級量表式（評分），多選問題式，輸入型：富文本式、多信息載體式，授權型：同意說明式。

選擇型反饋：

說明：選擇型反饋形式由系統實現安排若干選項供用戶選擇，通常出現在一個功能使用或操作流程的最后節點或者使用結束之后

二元選擇式：

是最簡單的定性用戶評價形式，提供二元化的選擇（通常為積極情緒和消極情緒兩種對立的選項），就像投票一樣，贊同或反對可以直接表達出用戶在當時場景中的體驗情緒。

等級量表式：

一般采用星級評分的展示形式，或者為了突出產品和用戶之間的情感化聯系，可以采用更加圖形化的展示形式，比如emoji的引入或者結合IP形象的展示形式。或者采用簡單粗暴且更具數字靈活性的純數字評級形式。

這里需要注意的一點是，反饋機制中的等級量表評分形式和NPS（凈推薦值）有差別，前者一般從非零的數字開始，而NPS則會包括0這個選項。

當你需要獲知用戶在產品使用體驗上關于滿意度、易用性、好感度、流暢性、幫助性等可以衡量產品性能的指標，可以采用等級量表這種設計形式。

多選問題式：

系統預先提供了一套可供用戶自由選擇的問題列表，用戶根據實際遇到的問題來進行選擇，問題需要立足用戶的當前用戶流程和功能操作，同時不要提供太多的選項。

輸入型反饋：

說明：輸入型反饋形式需要由用戶主動去輸入信息，通常出現一個功能流程明確結束之后

富文本式：

因為需要用戶主動去輸入一些當前情境下遇到問題的詳細信息，所以這種反饋形式對于用戶來說會具有一定挑戰性，當然可以嘗試結合一些視覺層面用戶激勵的形式。（如引導性的視覺化表現型形式）

多信息載體式：

也可以成為視覺化的反饋形式，通過截圖、視頻等更直觀的多媒體形式來反映用戶在產品使用體驗中遇到的問題，通常此類反饋對于bug類、系統類錯誤的改進以及界面布局的優化有很大幫助。

授權型反饋：

說明：授權型反饋形式通常會涉及到用戶數據和用戶隱私相關的信息展示，通常會出現在用戶首次進入特定的功能界面或者常駐在系統配置中。

同意說明式：

授權同意說明式需要將涉及到系統和用戶之間的數據交互及權責說明進行詳細的解釋，讓用戶自己選擇是否參與到系統體驗改進計劃中，讓用戶清楚自己的反饋（自己主動反饋的以及系統主動收集的）會被用來做什么。

平臺內反饋機制的通用設計模式：

結合具體使用場景，從組件拓展到設計模式，下面講講幾種具體設計模式的應用。

針對性反饋：

希望針對性的對特定功能或特定流程收集用戶反饋，通常可以采用模塊內嵌形式。

其主要目的是為了獲取用戶和某一特定功能發生交互后的瞬時態度，此類用戶反饋的設計模式需要出現此功能模塊的相臨近區域（同時布局通常采用卡片式模塊布局形式），比較常見的是調查目前頁面提供的信息是否對用戶在此區域的行為目標有幫助，一旦用戶已經完成了平臺希望采集到的用戶反饋，可以立馬關閉當前反饋機制，平臺也應該及時傳遞出感謝用戶的消息。

整體性反饋：

希望對產品某一整體功能或流程的體驗收集用戶反饋，通常可以采用三種形式：側邊面板形式、全局彈窗形式、新建頁面形式。

其主要目的是為了獲取用戶關于已完結功能流程的整體態度和感受，提供一個可供用戶自由表達意見的入口，此類用戶反饋的設計模式會出現在流程完結后的當前頁面中，一般會提供比較詳細的關于用戶體驗的問題列表，同時一旦用戶完成了反饋，可以立即關閉此反饋機制，平臺也及時傳達出感謝用戶或激勵用戶的消息。

綜合性反饋：

希望從用戶側收集到關于他們對產品的綜合性評價（如NPS），其設計模式同樣可以采用：側邊面板形式、全局彈窗形式、新建頁面形式

其目的是為了獲取用戶對平臺提供服務的綜合性態度，通常會是一個綜合的問題評分表，同時會通過視覺化的設計形式將用戶的注意力吸引過來，所以需要注意的是，此類設計模式通常需要出現在明確完結的流程之后，確保用戶已經離開了上一個任務流程。需要用戶反饋的內容詳細程度決定于設計者想要獲取的信息顆粒度。

當然以上三種模式由于都是平臺端啟動的用戶反饋機制，對用戶的正常使用流程必定會存在一定的干擾性，所以要針對一些具有高設計研究價值（高重要性和高影響性）的功能/模塊/流程進行安置，同時要選擇合適的時機，通常為用戶完成一項任務后或最后的任務節點，或預測再次開啟此流程的起點。

如何搭建一個有效的平臺內用戶反饋機制？

從設計目標出發，選擇合適的用戶反饋組件，用合適的設計模式進行展示，同時具體的反饋內容需要背后需要有一套考慮周全的設計策略作為支撐。比如用戶群體的劃分策略、內容撰寫的策略、收集周期的策略等。（因此處定義的設計策略實際上已經涉及到具體的細節設計方面，先按下不表）

05 反饋用戶的設計形式

平臺內收集到用戶反饋后，通過整理、歸類、過濾等一系列操作，通常得到的是一些偏評價式的現象描述，這個時候就需要通過平臺外的用戶反饋機制來挖掘現象背后的原因了。

同時對于部分可以直接定性的結論，通過一些溝通途徑向用戶側反向反饋，平臺內反饋用戶或者平臺外反饋用戶，其目的就是為了增加用戶的產品參與感，同時鼓勵用戶再次反饋，打造一個健康可持續的用戶 – 平臺溝通閉環。

平臺內反饋用戶：

平臺內反饋用戶，在用戶使用產品的時候告知感謝用戶的參與和反饋。

通常的形式，可以采用比如內置的郵件系統、消息通知系統等，作為用戶溝通體系的分支系統 – 平臺內消息通知系統的搭建為達到較好的體驗效果，通常需要配備一個比較完善的設計策略，即反饋強度和提醒分級的合理設置。（具體會在另外的系列文章說明）。

同時涉及到偽反饋機制和真反饋機制的設置，前者會通過通用性的設計模式及時通知到用戶，感謝用戶的反饋，后者一般存在時間差，會結合具體的反饋對用戶表示反饋及傳遞給用戶其產品后續行為。

平臺外反饋用戶：

平臺外反饋用戶，通過溝通渠道對用戶表示感謝，比如通過郵件形式、短信通知形式、電話訪問形式等

當然如果產品是對外的SaaS化平臺，為了表示產品設計團隊對用戶反饋的重視，甚至可以在產品內或官網上開辟一個專門的用戶反饋板塊，讓用戶更強烈的感知到自己在共建產品層面的參與感。

通過平臺內的用戶反饋，可以收集到用戶對當前產品現象的態度和情感類反饋，但這些數據會是比較粗顆粒度的，如果需要更深層次的挖掘這些現象背后的原因，B端用戶溝通體系中的大頭，搭建出一個平臺外的用戶調研機制并確保有效運行就起到非常關鍵的作用了。

06 平臺外用戶反饋機制

下面重點講講平臺外的用戶反饋，即常規意義上B端的用戶調研手段，這些用戶調研手段就像是深度的用戶反饋機制，對于B端產品而言，調研通常是帶著明確的目的，產品體驗存在問題想改進，產品體驗還可以想挖掘新的機會點，諸如此類。尤其是對于中大型的B端復雜業務系統，分功能模塊和分支流程的調研很常見。

和C端豐富的調研手段相比，在實際企業環境中，最適合B端產品的設計調研手段實際上重點在幾種定性研究手段上：用戶訪談和可用性測試，情境調查（情境式觀察和交流），當然不局限，你也可以通過一些輔助的定量用戶研究手段來進行一些結果驗證性的調查。

設計師發起的用戶調研：

由設計師發起的用戶調研和產品發起的用戶調研雖然存在一定的差異，但核心點都是為了指導產品設計的過程，設計師和用戶的直接交流，可以得到更豐富的一手數據，而不是一些被加工過的二手甚至三手數據。

對于B端設計師來說，用戶研究的流程和傳統非敏捷向的設計流程是比較類似的：

B端用戶研究的流程可以概括成如下：

研究目的 → 選擇合適的用研手段 → 執行研究 → 信息匯總尋找解決方案 → 報告輸出 → 陳述結果 → 選擇方案并落地

B端產品設計（設計師側）的流程同樣可以概括成如下：

設計目標 → 選擇合適的設計手段 → 設計表現執行 → 多方案比較尋找最優解 → 設計輸出 → 方案展示及評審 → 優化方案并落地

如何做B端用戶調研：

總結成四點：聽TA說了什么，TA是怎么想的，看TA做了什么，TA的感受如何。

TA是怎么想和TA的感受如何，這兩點可以通過平臺內用戶反饋機制來重點收集，用戶對產品的轉瞬即逝的情緒和情感是最有價值的，直接感受比事后回憶更具參考價值。

以之前一次比較完整的B端用戶調研的實踐（企業項目級別）為例說明整個流程：

提綱設計 – 訪談規劃 -預訪談 – 提綱確定 – 訪談執行 – 補充訪談 – 問卷補充驗證 – 輸出報告 – 信息同步 – 落地執行 – 跟蹤反饋。

反饋收集：

通過前面這么一套用戶調研流程的推動，依據實際執行的經驗，一般可以發現兩類問題：第一類為老問題（VoC），另一類為新問題。

補充說明一下VoC的概念（Voice of Customer即客戶之聲），VoC在推動B端產品的小步快速迭代優化方面起著非常重要的作用，有些SaaS產品會配置專門的客服服務部門來跟蹤用戶對產品的實時體驗反饋以及解決客戶問題。

對于B端用戶來說，其行動動機通常會由兩部分組成：

第一部分為所在組織的運作目標，關系到整個組織的構架、業務部門的具體運作形式（通俗的講所處業務部門是如何獲取商業利益的）、組織中各個角色和個體是如何進行和配合協同辦公的、以及組織的業務目標和拆分到個人上的目標等。第二部分為角色的工作心理模型（指在被管理環境下角色的心理模型），關系到角色的工作目標、具體工作流程、日常工作模塊，以及背負的KPI等。

而從產品設計者的角度出發，需要將多角色的業務流程抽象化再組織，考慮角色在系統中的信息流轉是怎樣的，業務反映在產品界面上的關鍵決策點應該在哪里，為了達成用戶目標，系統應該給用戶提供哪些有效且關鍵的信息？

以上都可以作為B端用戶交流體系中確定想要收集的用戶反饋階段的基礎內容框架。

ps：關于用戶調研的詳細介紹會是一個比較的設計命題，由于此篇文章的重點還是關于B端用戶溝通體系的搭建，先不涉及更詳細的用戶調研技術的說明，當然由于用研落地實踐的方法論其實大同小異，有興趣的小伙伴可以自行查閱相關資料。對于平臺外用戶反饋機制的運行，實操比理論重要的多，甚至并不具備一些用戶的專業知識去直接進行調研得到的結果也不會太差，邁開腿去行動是第一步也是最重要的。

反饋分析：

通過各種用研技術拿到了用戶的一手反饋數據后，通過各種數據整理歸類、過濾處理之后，通常數據處理的標準是依據反饋的合理性進行優先級排序，合理性可以由以下幾個方面來評估：