前四點是做好一個B端幫助體系必須要做到的，第五點相對進階，可以視具體情況完善。

內容的組織上，核心是要想辦法講清楚，把復雜信息轉化為易于理解的信息，減輕用戶的認知負擔。

應該遵循以下原則：

• 可視化：通過概念圖、流程圖、表格形式，把抽象難理解的邏輯/概念可視化呈現；
• 場景化：結合業務場景進行闡述，讓用戶更易理解；
• 價值導向化：從功能價值和用戶利益出發，優于直白的功能描述，也有利于提高用戶的滿意度。

四、幫助體系搭建實踐

1.?第一步：搭建組件庫

我們可以基于產品界面的幫助指引分出三種形式：主動式幫助、被動式幫助、自動式幫助?；谶@三種幫助形式設計相應合適的交互形式與內容組織形式，進而形成標準化的組件庫。

4.1.1.? 主動式幫助

主動式幫助是主動向用戶提供幫助，讓用戶盡快熟悉系統界面。

核心使用場景有兩個：

1. 對新用戶進行幫助教學
2. 新功能上線后，對老用戶進行提示

針對主動式幫助是否對當前的用戶目標有直接關系，是否依托于某個具體用戶使用情境或者脫離于具體使用場景直接展示，又可以將其分成兩種類型：推動性幫助和相關性幫助。

4.1.1.1. 推動性幫助：

推動性幫助一般不和用戶目標直接相關，缺少使用情境的支持，一般會被用戶選擇性忽略，因為在一定程度上它影響了用戶的正常操作流。當然如果運用場合合適，對于處于接觸系統階段和嘗試使用某一功能階段生命周期的用戶，是可以讓其了解到產品的初步框架和推動其嘗試完成一個核心業務流程。

交互形式有以下幾種：

4.1.1.1.1. 引導頁：

用戶首次進入產品或者產品中某個獨立功能的時候，將產品最核心的功能描述加入一些插畫或者視頻吸引用戶；文字部分不要長篇大論，提煉最核心的內容傳達給用戶，如果帶有一定的操作流程，可以以流程圖的形式描述功能使用流程。

4.1.1.1.2. 模態彈窗：

用戶第一次打開某個特定頁面時出現，讓用戶聚焦當前內容，常用于版本更新提示、新功能介紹、常規通告等應用場景。

缺點是用戶容易忽略或者無視，直接關掉，引導的效果差一點，所以彈窗教程建議保留二次進入的入口，當用戶需要的時候可以順利找到。內容上可以在文本的基礎上加入圖片、插畫、視頻講解等。

4.1.1.1.3 向導引導：

用戶首次進入相關頁面，且無操作時出現。有明確的指向性，提前告知用戶具體功能的使用場景，不僅會指向界面中的某些特定區域，同時會隨著操作的位置發生變化，讓用戶實際感知到功能的整個運轉邏輯和流程。

具體使用過程中有三種交互方式，隨著提示強度由強到弱依次是：分步式引導、氣泡提示、閃點提示。不過閃點提示屬于相關性幫助，后文將會提到。

4.1.1.1.3.1. 分步式引導：常用于頁面多個功能升級的引導組。頁面有多個升級點，直接平鋪會讓頁面臃腫不聚焦，通過「下一步」操作，逐步喚出剩余引導。建議最多不超過5步。

4.1.1.1.3.2. 氣泡提示：相對輕量的引導，有足夠的提示性但不影響其他功能操作，不過不適合展示過于豐富的內容，這會導致頁面太花。

4.1.1.1.4. 模板示例：

在B端產品一般表現為提前給用戶提供一條具備相對完整性的示例，比如示例文檔、示例數據等。通過讓用戶直接感受到最終呈現效果來反向推動用戶進行類似的功能操作。當然模板示例需要支持編輯和刪除。

4.1.1.2. 相關性幫助：

相關性幫助會和用戶任務有直接和間接的關系，一般會出現在和用戶當前任務相關的情境中，通過情境內的提示來告知用戶相關的幫助性內容。隨用戶實際使用情境出現的，及時給用戶提供了必要且相關的信息，直接解答了當前任務中可能存在的疑惑。交互形式有以下幾種：

4.1.1.2.1. 文字提示：

作為最直觀的信息展示，一般會采用直接平鋪的展示方式，針對一些功能較多邏輯較為復雜的頁面，將對用戶有幫助的信息直接放在頁面上從而指導用戶的行為

具體的設計實踐一般有：頁面標題、頁面功能輔助說明、占位提示等。

4.1.1.2.2. 工具提示：

比文字直接展示要更簡潔降噪，沒有直接進行展示，而是在用戶需要的時候通過懸浮或者點擊元素以氣泡的形式喚出。在設計形式上有短暫性、匹配性、簡明性的特點。

• 短暫性指工具提示出現和消失的時機需要恰當和短暫
• 匹配性指工具提示需要出現在與之關聯的元素附近
• 簡明性則是對工具提示承載的文本內容提出了要求，要盡可能具備簡短性和描述性

4.1.1.2.3. 向導引導（閃點提示）：

微輔助型提示，常與氣泡引導配合使用。在需要關注的地方閃爍，點擊閃點后喚出關聯氣泡提示。不對用戶造成視覺干擾，又能引起一定的關注。并且相比直接氣泡提示，閃點提示喚出的氣泡可以承載更豐富的內容，如圖文。

4.1.1.2.4. 鏈接入口：

當文字提示/工具提示無法承載過多的幫助性信息時，設置一個鏈接入口，讓用戶自行跳轉去相關頁面或模塊進行查看，獲取幫助。因此這一類幫助形式通常會和被動式幫助進行聯動

同時，關于異常情況的引導也屬于主動式相關性幫助設計形式的一種。當用戶進入正常流程的末端節點或非正常流程中時，加入相關的引導性鏈接入口對于用戶重新進入正常功能流程非常有用。

綜上，在各種交互形式下，內容組織形式可以視情況選用以下三種形式：直接平鋪式、循序漸進披露式、入口提供式。

• 直接平鋪式：通過將幫助性信息一次性展示來達到效果，承接信息的載體小，若堆積過多內容，則會加重用戶的認知負擔；
• 循序漸進披露式：通過將幫助性信息進行步驟拆解，一步步引導用戶熟悉產品功能和流程，適合復雜業務功能的具體教程說明。承接信息的載體大，但如果數量過多，頻繁的操作也會加重用戶的交互負擔；
• 入口提供式：當內容信息和交互步驟都較多時，可以設置一個鏈接入口，讓用戶自行跳轉去幫助中心/文檔查看，獲取幫助。

4.1.2. 被動式幫助

被動式幫助是為了讓用戶遇到問題的時候系統能夠提供一些響應式的幫助，通過內置的幫助和指導性說明來解答用戶使用產品過程中遇到的疑惑。

核心使用場景是依托于主動幫助，集成包括主動式幫助中的一些共性幫助信息，提升產品體驗。被動式幫助可以分為兩種類型：匯總性幫助和臨時性幫助。

4.1.2.1. 匯總性幫助

一個良好的匯總性幫助模塊是一個新手用戶向專家用戶轉變的最有效學習工具。對于B端產品來說，缺少一些匯總性幫助文檔，會讓用戶在遇到問題時陷于束手無策的境地。這些幫助信息可以極大節省產品的培訓成本，讓用戶去自主去學習整個產品的邏輯。同時對于產品本身，匯總性幫助可以提高整體產品的完整度。匯總性幫助有以下兩種形式：

4.1.2.1.1. 幫助中心：

幫助中心的設計應當包含以下三部分：產品介紹，產品使用手冊，常見問題FAQ。并且應當符合以下原則：

1. 方便搜索；
2. 針對用戶的核心任務；
3. 描述要盡量步驟化和流程化，但不要運用大量文字篇幅。

幫助中心實際上大量文檔的匯總集合，因此文檔是否結構化清晰化展示是衡量一個幫助中心是否閱讀體驗良好的關鍵。另外由于大部分用戶實際上都不喜歡閱讀文檔，內容組織上需要簡明扼要。

4.1.2.1.2. 全局常駐功能：

全局常駐性功能通常作為匯總性幫助信息的入口，其在產品頁面中的具體表現形式就是其代表的功能操作控件始終存在于界面中，方便用戶隨時進行操作，常見的如首頁儀表盤、全局搜索框、幫助中心入口、聯系客服入口、便捷性操作等。

4.1.2.2. 臨時性幫助

臨時性幫助的設計一般是采用智能客服+人工客服的模式。通過智能客服先行過濾已在系統幫助中心的問題反饋，而后人工客服介入。

關于智能客服支持和人工客戶支持的協同，如何達到用戶響應及時但客服成本又能得到較好控制。關鍵點在于前者問題知識庫的業務覆蓋率是否足夠廣，問題識別的準確率是否足夠高，所呈現的答案滿意度是否夠高。

4.1.3. 自動式幫助

自動式幫助是通過一些系統自動化處理的方式來增加系統的容錯性，最大化減少用戶的決策壓力。

自動化幫助主要將復雜性轉移給了系統，從而減少用戶的決策步驟和操作風險。針對一些用戶操作風險較小且系統能力能夠支持的場景，可以直接交付系統來自動完成。

針對一些用戶操作風險較大且系統能力也能夠勉強支持的場景，可以提供部分選項供用戶進行選擇，同時提供必要的容錯能力。自動式幫助可以分為兩種類型：提醒性幫助和自動性幫助。

4.1.3.1. 提醒性幫助

提醒性幫助通過提醒的形式將功能的運行情況、用戶的交互操作反饋給用戶，讓用戶自行決定是否繼續行動。核心點在于讓最有可能是用戶需要的信息更接近用戶，從而減少交互成本。提醒性幫助有以下四種形式：

4.1.3.1.1. 參數模板預設：

將高頻的內容錄入、參數配置場景封裝為模板或方案供用戶選擇

4.1.3.1.2. 交互反饋：

當用戶進行系統操作后，無論成功還是失敗，系統都需要給予反饋。常件的操作反饋形式有：toast、表單錯誤校驗、模態彈窗、獨占式頁面。

• toast：一般3s左右消失，因體積小、展示位置靠上、自動消失等特點時常被用戶忽視。常用于操作結果、系統性無明確后續指引的反饋，例如“提交成功”、“操作失敗”、“服務器無反應”。

• 錯誤校驗：當操作出現輸入錯誤時，為用戶展示明確的提示性消息，引導用戶修改內容

• 彈窗提示：提示性和阻斷性都很強，能夠讓用戶聚焦信息本身。通常提示內容可為用戶提供指向性引導，需要強關注。

• 獨占式反饋：提交后頁面切變為獨立展示的頁面級狀態反饋。比彈窗的阻斷性更強，信息獲取更沉浸。在設計時建議搭配狀態插圖強化氛圍，并提供操作按鈕為用戶提供通路。

4.1.3.1.3.?智能推薦/填充：

數據填充后的推薦選項、自動模糊匹配、記住并自動顯示上一次輸入的內容

4.1.3.2. 自動性幫助

自動性幫助則直接省略了用戶的交互過程，將相應的行動交給系統后臺自動處理。**核心點在于讓系統幫助用戶做決定，直接解放用戶的一部分工作。**自動性幫助提醒主要有以下形式：

4.1.3.2.1. 自動糾正：

將不符合規定格式的數據進行自動糾正、文本錯別字的自動拼寫糾正、自動識別數據類型并進行分類、容錯性較大的搜索匹配等。

地址智能識別功能就是自動糾正的其中一種應用。

2. 第二步：搭建幫助體系

結合B端用戶功能生命周期，按照上文的搭建思路，我們可以靈活搭配組件搭建幫助體系：

幫助體系可以模塊化、組件化，但是搭建幫助體系應當全局考慮。在每個產品模塊或功能設計開始中，就根據B端用戶功能生命周期選用合適的組件搭建幫助體系。在功能設計之初就開始搭建幫助體系，會有以下的好處：

4.2.1. 自省產品方案：

在功能設計之初開始搭建幫助體系可以促使我們更深入地思考產品的設計方案。通過思考如何解釋和幫助用戶使用不同功能，可以幫助發現潛在的設計缺陷或用戶體驗問題。這有助于提前識別并解決可能存在的問題，確保產品方案更加完善和用戶友好。

4.2.2. 交互一致性：

在構建幫助體系時，可以定義一致的交互模式和設計準則，以確保不同部分的幫助內容在用戶界面中保持一致。這可以減少混淆和用戶困惑，提供更好的用戶體驗。

4.2.3. 提高產品易用性：

幫助體系的早期搭建可以確保用戶在使用產品時獲得及時的指導和支持。這提高了產品的易用性，減少了用戶的困惑和不滿，讓用戶更容易理解如何使用產品。

4.2.4. 提升上線質量：

通過早期的幫助體系搭建，可以在產品上線之前識別和解決潛在的問題和錯誤。這有助于提高產品的質量，減少了上線后需要緊急修復的問題的數量，也降低產品迭代對用戶造成的影響。

4.2.5. 提升上線效果：

一個清晰和有效的幫助體系可以幫助用戶更快速地掌握產品的功能和優勢。這可以增加用戶的滿意度，并提高他們的使用率。如果用戶在開始使用產品時遇到困難，他們可能會更快地放棄或尋找替代方案。通過提供良好的幫助體系，可以增加用戶的粘性，提升產品的上線效果和市場競爭力。

當然，如果產品仍在孵化期，處于MVP驗證階段時，我們可以不用上線整套的幫助體系。因為MVP階段我們需要直接和客戶溝通收集反饋，以完成產品快速驗證迭代和提升PMF。不過，在產品設計、界面與交互設計上面還是需要提前做好準備，把整體的基礎打好，會有利于后續版本的迭代建設。

3. 第三步：鏈路式埋點跟蹤工具

我們可以根據公司的實際情況選用鏈路式埋點跟蹤工具（自研or外采），此處所強調的是幫助體系的建設一定要有完善的鏈路式數據跟蹤，這將會支撐幫助體系的持續建設和產品易用性的持續提升，從而量化出幫助體系所帶來收益。

五、最后

以上是對幫助體系搭建的思考與拆解，單一的幫助形式是散落不起眼的，但是通過一些設計手段將這些點進行整合和連接起來形成幫助體系，那么產品整體的易用性也將會得到顯著提升。