產品一般都會幫助中心，幫助用戶解決一些不知道怎么操作的問題。因為使用場景的不同，B端的幫助中心使用頻率比C端的高很多，這個時候，幫助中心的設計就更加重要。

“請問你需要幫助嗎？”

在生活中，我們有任何問題都會請求別人的幫助；而在屏幕世界中，使用不同的軟件我們也需要尋求幫助。

使用 Notion，我會通過 B 站的視頻去尋找教程；管理待辦事項，我需要使用 GTD 的理念才能高效歸類；使用帆軟，我需要對 數據分析類 的專業知識有所了解。

對于我們而言，去做任何事情都會遇到困難。但是 B 端產品當中，作為設計師的我們，需要去為用戶解決困難。

為什么想要聊聊幫助體系，是因為現如今大多數的 B 端產品進入成長期、成熟期，開始意識到幫助體系的重要性。

比如在微盟的迭代復盤當中，就明確將幫助體系作為核心板塊進行迭代，同樣在京東的復盤當中也會有類似的觀點。

你會發現隨著行業的不斷發展，產品用戶不斷增多，你需要去教育用戶，讓他們從能用產品到用好產品，只有深入理解產品邏輯后，才能增加用戶黏性，后續才能更好為產品付費。

我們今天就來聊聊 B 端系統的幫助體系，講講究竟應該如何進行設計。

一、什么是幫助體系

1. 幫助體系的定義

幫助體系是“在用戶使用產品過程中，系統所進行的提示與指引，從而提升操作效率、降低認知成本”。

它作為我們系統與用戶之間的橋梁，能夠通過預設的“信息”來解決用戶的問題。

在理想情況下幫助體系本身是不應該存在的。因為一個“完美”的軟件系統當中，所有的設計都應該是符合用戶直覺的，根本不需要學習。

但是在 B 端系統本身就會存在行業門檻，同時系統當中包含有大量的 專業詞匯、業務邏輯，甚至需要大量的學習才能夠上手（主要是行業屬性型產品），也就造成幫助體系是作為系統當中的兜底策略，能夠解決 用戶 與 系統 之間理解不一致的問題，也就是讓三大模型[1]當中的理解能夠一致。

[1]三大模型其中包含，用戶模型、設計模型、心理模型。

1. 用戶模型：描述目標用戶的抽象，包括用戶特征、需求等信息，助力設計者更準確地預測和滿足用戶期望。
2. 設計模型：產品或系統的抽象表示，包括設計團隊對結構、功能、界面的構思，指導實際開發過程。
3. 心理模型：用戶對系統工作方式的腦海理解，設計者致力于通過設計使用戶心理模型與實際設計模型接近，提高用戶體驗。

幫助體系真的有這么重要，如果沒有好的幫助體系，會存在以下問題：

2. 幫助體系的痛點

1）B 端系統越來越難

因為 B 端產品已經 從初期的基礎功能向高級功能 開始過渡，因此你會發現系統當中會存在越來越多不能理解的設計。比如下面這個頁面主要用途是什么？

正確答案就是篩選的組合條件。

目前 B 端系統都在去強調 通用自定義 ，很多功能都變得異常復雜，如果這時候無法通過幫助體系去解決問題，對于用戶而言則會棄用這款軟件，導致用戶不斷流失。

比如在座的各位設計師，為什么不愿意從 sketch 遷移到 photoshop ，其實就是因為 photoshop 針對的是更為通用的位圖繪制的場景，所以它更難，很多功能也用不太上；而 sketch 則只針對的界面設計領域，相對而言達成目標更加簡單。

2）企業投入成本高

幫助體系本身就是為用戶進行服務，但一個系統有著糟糕的幫助體系，會導致 客服人員、技術支持 的壓力巨大，只能通過人力解決客戶問題。

因為現在的系統大多是為 中級用戶、專家用戶[2] 來進行的設計，沒有完整的幫助體系就需要大量的 客服人員進行解答；技術支持進行遠程協助；實施人員進行現場培訓，這都需要企業投入大量成本。

并且產品也在不斷更新，我們還需要反復地教學用戶新功能如何使用。如果沒有良好的幫助體系，就只能用“口口相傳”的方式表達設計理念，這也是需要花費巨大成本的。

關于企業成本，越是成熟的產品企業投入越高。在 Salesforce 團隊的分享當中提到過，因為他們用戶量很大，一次產品更新所需要投入的成本在千萬美元。因為背后涉及到 員工學習、用戶培訓、更新講解 很多成本，這些都不可忽視。

[2]中級用戶、專家用戶：我們把 B 端系統的用戶群進行劃分，主要分為 普通用戶、中級用戶、專家用戶。其中中級用戶是指對產品使用較為頻繁的用戶群；專家用戶是指對這一領域有著自己獨特認識的用戶群。

3）產品角色多

在我們系統當中本身就會有很多角色，不同角色他們所關注的利益點并不相同。

對于幫助中心來說，就不能針對單一角色展開，需要更為全局的考慮每一個角色所關注的內容，需要給出當前場景下的合理的解決方案，才能搭建好用的幫助體系。

二、幫助體系的類型

正是由于上面提到的痛點，你會發現系統中需要幫助的地方非常之多，這也就形成了常見的八個幫助類組件：提示信息、新手引導、全局提示、幫助中心、人工客服、任務預設、智能助手、產品學院。

在這里的每一個組件都會有：提示方式、展示位置、呈現內容 等差異，我們便可通過這些維度分門別類的去做總結。

1. 提示方式的維度

提示方式就是在系統當中，是如何給到用戶提供的幫助。它主要分為：主動提示與被動提示

主動提示：系統主動發起向用戶提供幫助，其目的是為了讓用戶盡快熟悉系統。

常見的主動提示組件有：工具提示、新手引導、全局提示、任務預設、功能提示。

因為是系統主動發起，對于用戶的干擾較為明顯，所以在條件的判斷上要更加的苛刻。

比如：新用戶進入系統，不能有過度的主動幫助，在適當的幫助后就得讓用戶自主探索，如果這時候你剛完成一個新手引導、緊接著讓你查看一個任務預設，同時旁邊還伴隨著全局提示以及小窗解釋，這對于用戶而言干擾過多，用戶會極度反感。

被動提示：系統被動的向用戶提供幫助，這類情況往往是用戶遇到問題，需要自行尋求解決方案。

常見的被動幫助組件有：幫助中心、人工客服、智能助手、產品學院。

這類幫助通常整體的耗時都會較長，都是用戶在遇到的疑難雜癥時，需要進入系統的解決方案中進行尋找，因此需要花費大量時間，所以在設計時需要給出清晰明確的指引。

比如：幫助中心的分類、人工客服的快速幫助、智能助手的智能提示，都是在想要快速解決用戶的疑惑。

2. 幫助范圍的維度

幫助范圍就是在系統當中，針對哪些模塊提供的幫助提示。因為 B 端系統本身就比較龐大，對于幫助的對象也會有所不同，所以我們按照由小到大劃分為 字段 – 組件 – 功能 – 系統。

1）字段層面

服務于系統當中的文字信息，是用于解釋批注文字中的專業信息，它是系統當中最小的幫助單位。

通常字段幫助主要有：工具提示、文案提示。因為范圍最小，所以使用的時候也較為頻繁。同時字段提示大多數為被動提示，因此需要考慮它出現的位置，以及如何呈現幫助內容。

比如我們在文章當中，進行的專業名詞標注；在系統當中的標簽提示，都是屬于字段層面的幫助。

2）組件層面

主要服務于系統當中的組件模塊，它能夠解釋復雜組件的各種邏輯，幫助用戶快速進行組件使用。

常見的組件幫助有：提示信息、全局提示。在 B 端產品當中組件規范化已經深入人心，其實在組件規范的過程當中，就會去考慮對應的幫助提示，便于用戶快速理解。

比如在輸入框中，就可以通過 popover 進行信息提示，幫助用戶快速理解輸入的格式與內容要求。

3）功能層面

專注于系統的功能模塊設計，它是去解決這個功能究竟應該如何使用，具體配置規則的重要方式。

我們可以使用：任務預設、解釋頁面、幫助中心（會包含功能的維度） 等方式進行解決。

因為功能本身邏輯會特別的多，我們對于需要少量解釋的情況，可以使用解釋頁面、任務預設來解決，如果內容較多，則會考慮跳轉到 幫助中心 以及 系統層面 的方式進行解決。

4）系統層面

用于解決系統當中的所有問題，它是在聚合前三種范圍，并且講解全面完整的進行呈現。

常見的 幫助體系、漫游引導（新手）、產品學院，都是系統層面的幫助體系。

系統層面就需要全面、易查找，因為系統當中會存在很多問題，所以如何快速解決，就像你們去到一個大型的圖書館，怎樣才能夠找到你心儀的那一本書一樣，系統層面的就是這個圖書館，因此層級的合理性，內容的劃分都格外重要。

三、幫助體系的用法

幫助體系當中的組件非常多，為了讓大多數同學能夠用于實際的工作當中，我們將其分為 初創期、成長期、成熟期 三個階段。

因為每一個階段對于幫助體系的需求并不相同，我們所采取的設計策略也會有所不同，大家可以根據自己產品的目前狀況做到上手即用。

1. 初創期 – 提示信息

首先，在系統剛剛搭建的初創期，我們想到的便是投入產出比，“希望能夠花小錢，辦大事”。而大多數的幫助方式都格外復雜，需要增加很多工作量，所以初創期考慮的第一個幫助方式便是提示信息。

在提示信息當中，主要包含有 工具提示、文案提示、錯誤提示，

我們需要了解這些提示信息，并且在工作當中跟隨每一個需求同步設計，這樣就能提高我們的投入產出比。

工具提示：通過用戶主動觸發的方式呈現系統當中的文字說明，來解決用戶對系統當中字段、組件信息不理解的情況。

在設計當中我們要求能直接展示的信息最好就不要隱藏，而使用工具提示主要是呈現層級較低的內容，同時又可以避免信息過載導致頁面臃腫。

文案提示：將重要的文字信息通過直接平鋪的方式展示在頁面當中，能夠輔助用戶進行輸入與決策。

在文案提示當中，主要有三類使用場景：輔助說明、占位提示、重要提示。

錯誤提示：在用戶操作過程中，無法通過校驗規則而出現的錯誤提示信息，目的是讓用戶及時的發現并且糾正問題。

錯誤提示一般都與組件設計密切相關，是我們在進行基礎組件設計時重要的一部分。

在我們使用提示信息時，是需要考慮將提示的文案進行精準的表述，并且描述時，同樣會存在很多技巧，比如：

對于專業名詞，我們需要通過 「」 進行標注，這樣能夠讓用戶快速理解其含義，如果不知道可以通過搜索引擎進行查詢；

對于對比信息，通過 序列化的 的方式進行呈現，讓用戶能夠快速理解其中差異；

對于文案描述上，應該更多的使用口語化描述，不要為了解釋一個專業名詞而引出一堆專業名詞，增加用戶閱讀門檻。

這些都是我們在使用工具提示上所需要注意的，幫助體系當中對于文案的使用頗有講究，這部分就留著我們后面有時間再進行講解。

2. 初創期 – 新手引導

由于初創期會存在大量的新手用戶，因此新手引導會讓這些用戶理解產品的基礎邏輯。

新手引導：是指在用戶初次使用系統時，通過講解系統設計思路，幫助用戶熟悉和了解產品，提高其使用體驗。新手引導的目的是降低用戶的學習難度，減少初次使用時可能遇到的困惑和挫折感，從而提升用戶對產品的初次印象，促使其更好地上手使用。

常見的新手引導主要會有 漫游引導、視頻介紹、任務預設 三種方式， 而在初創期，我們一般只會使用漫游引導、視頻介紹。因為實現起來較為簡單，任務預設主要針對功能部分所展開的，因此放在成長期進行實現。

在設計過程中同樣需要注意以下問題：

• 在形式上，盡可能少的去使用文字。因為這是和用戶第一次見面，使用文字會感覺到比較“寒酸”，常見做法是通過 視頻 的方式講解產品理念，能夠讓用戶快速理解其含義。
• 在內容上，趣味性同樣重要。因為新手引導整個形式會非常干擾，用戶第一次進入，需要先有趣才會讓用戶有更多的探索欲望。
• 在設計上，預留合適的出口。因為新手引導通常整個流程周期很長，因此需要留下出口方便熟悉的用戶快速退出。

3. 成長期 – 幫助中心

渡過初創期邁入成長期的產品，幫助中心一定是必不可少的。

幫助中心就像是一個產品的完整知識庫，能夠展示平臺所有的信息，它能夠幫助用戶了解整個系統全貌，同時也能教育用戶，讓用戶在系統中游刃有余，使用戶水平不斷提高。

在設計幫助中心時，我們需要注意以下幾點：

1）清晰的框架結構：因為幫助中心的內容量很多，我們會按照 用戶角色、使用目的 等維度進行劃分。

比如在滴答清單會按照使用目的劃分為：新手指南、最佳實踐、常見問題、設計理念、更新動態，同時會按照產品功能與特色功能兩個維度進行劃分。

在飛書應用端幫助模塊中，按照 用戶角色 劃分為：我是成員、我是管理員，這樣去使用的時候，通過當前個人角色進行選擇可以更清晰的推薦解決方案

同時 B 端產品本身角色屬性很強，可以按照角色、類型進行劃分，能夠將幫助體系設計得更為易用。

2）良好的更新機制：幫助中心是需要根據產品更新迭代不斷地進行調整，因此我們要確立良好的更新機制。

通常幫助中心都是由 產品負責功能迭代的設計，然后交給運營人員進行內容文案的優化，設計師輔佐提供成熟的圖片素材，最后進行更新。

建立完善的協作機制就能夠持續的進行造血，提供更多優質的幫助內容。一般在剛開始搭建時，通常會利用各種文檔類軟件快速搭建，既簡單又高效。

比如 raycast 就是在 notion 當中維護其幫助文檔～ （順便安利一下 raycast 設計師提效神器）

3）生動的內容形式：好的幫助中心一定要“活”起來，更注意用戶的情緒價值。因為用戶進入幫助中心情緒肯定難受，同時幫助中心又是一個被動方式進行幫助，整體的用戶感受也會非常糟糕，因此考慮呈現活的形象，更容易樹立品牌形象。

首先在幫助中心入口設計上，我們可以呈現更為生動的員工形象，這樣能夠緩解用戶情緒，是一個情感化設計的好點子。

同時在內容呈現上，基礎內容可以多以視頻的方式進行講解。對于初次接觸產品的用戶，能夠通過教學視頻更直觀，更容易的了解內容的全貌。

4）預留入口更多可能：同時在幫助中心處，預留 在線客服、交流群 等入口，方便用戶在當前幫助中心沒有解決問題的情況下，有一個解決問題的出口，并且設計師可以在后續做用戶研究時，通過群成員進行定性研究等。

4. 成長期 – 人工客服

人工客服是在用戶有疑惑時，通過人工的方式去解答用戶所遇到的各種問題，就像我們撥打 10086 去咨詢中國移動的各種問題，在 B 端系統當中也需要有自己的 10086 來解決問題。

在系統當中，通常會在全局菜單處提供一個人工客服呼出入口，讓用戶能盡快找到對應人進行解決。

同時在小的功能模塊當中，也可以將人工客戶放在右下角進行訪問。

人工客服幾乎在每一個平臺都會存在，雖然問題被處理的效率會大大提高，但是對于企業而言，相應的成本也隨之提升。我們一般不會推薦，這也是為什么很多人工客服難以觸達到的原因（比如 微信聯系人工客服，需要有漫長的跳轉）

作為設計師，其實是有必要參與的客服的服務當中，通?？梢圆扇≥啀徶频姆绞?，一個月安排一天時間，深入接觸用戶，了解他們的真正痛點。

5. 成長期 – 任務預設

任務預設是新手引導當中的一個分支，它主要是在系統成熟后，會存在很多獨立的新功能，這時候我們便可以通過任務預設的方式將其進行引導呈現。

因為在B端產品的配置端，通常其邏輯都會比較復雜，我們可以通過任務預設，讓用戶能了解其設計邏輯。

比如我最常使用的 Focus 軟件，當你使用時，會讓你立即使用它的核心功能。

6. 成熟期 – 智能助手

當系統進入到了成熟期過后，你會發現在系統當中會存在很多通用的問題，其實我們可以通過智能助手的方式進行解決。

比如現在在京東、淘寶，當你提問常見的問題時，智能助手都會對于你的問題進行快速的回答。同樣當系統當中有各種問題時，我們可以讓智能助手快速提示對應的解決方案，進而解決用戶的問題。

為體現智能化，可以考慮與AI進行結合，通過正常的溝通對話，快速解決用戶遇到的各種問題。

比如最近 小鵝通就將 AI 與智能客服進行結合，讓問題更快解決，同時根據 AI 也能提供更多商家需要的服務。

7. 成熟期 – 解釋頁面

幫助體系本身就是要解決 在特定的地方，為特定的用戶，提供特定的幫助，在 B 端產品里面特定的地方一般指的就是一個核心的功能。

為清楚了解該核心功能，我們可以將「解釋頁面」通過抽屜的方式，讓用戶快速知道當前頁面所有會遇到的問題。

這種做法的邏輯就是將幫助中心里重要的幫助提示前置到問題頁，抽屜的方式讓用戶不用跳轉，同時也能快速查看頁面的詳細解釋。

比如在飛書審批當中，就能通過解釋頁面，查看不同步驟的配置視頻指南。

8. 成熟期 – 產品學院

產品學院是在成熟期后，是企業為想要深度使用的用戶，提供一個學習的渠道。

因為在專業領域較強的產品當中，本身就會包含有很多邏輯，是需要通過系統的學習，才能夠正常的使用軟件。比如在帆軟當中，我們就能夠直接報名課程，并且會有學習班，針對不同的分類進行學習。

我們通過學院的方式，將產品當中的精華通過線上教學的方式傳授給我們的用戶。因為通過這樣的方式，才能夠培養初級、中級用戶，讓他們能夠快速提升，更加深度的使用這款產品，同時也可以增加用戶的粘性。

四、如何搭建幫助體系

關于幫助中心的搭建，我們還需要考慮幾類原則，因為大多數場景都可以通過這幾類原則進行解決。

1. 就近解釋

幫助體系本質上就是要解決用戶的問題，如果過程需要花費非常多的時間，消耗大量精力，就會顯得得不償失。因此在設計時，我們需要考慮將答案快速觸達，這樣就能更高效的為用戶解決問題。

比如在一個優惠券配置頁面，對于優惠券的不同差異，我們需要快速準確的進行展示，而不是需要讓用戶進行 hover 觸發。

2. 高效傳達

在用戶閱讀幫助內容時，就會打斷之前的閱讀任務。所以幫助體系不是終點，而最終目的還是想讓用戶回到之前的任務當中。

高效傳達主要是在內容上優化展示形式，比如簡化幫助內容，考慮角色更為合理的展示，先展示更為容易的內容再展示復雜的邏輯，這些都能夠起到高效傳達的作用。

3. 清晰明確

清晰明確不光是指內容清晰，你還需要了解用戶的場景，盡可能采取最簡單的方式。比如告知整體流程需要花費多少時間，具體流程步驟，通過清晰的方式能夠讓用戶更為明確的進行操作。

4. 形式多樣

在產品的設計形式上，我們可以有 圖片、文本、視頻、動圖、音頻 等多種手段進行表達。而不同的手段都能夠在用戶特定場景下進行學習。

比如 圖片，你會發現它就會比單純的文本表達更為明確；動圖，又會比單純的圖片講得更高效；視頻，又會伴有音頻的提示更容易理解。因此形式上的多樣性才能保證系統的完整性。

5. 克制理性

對于幫助體系，也不是越多越好。作為設計師的職責就是要將復雜的系統更為簡單的呈現，如果每一個模塊，設計師都不會思考，遇到問題就幫助體系，很容易造成系統依舊難用。

因為并不是每個用戶都會去仔細閱讀，所以做好設計，理性使用幫助會更為重要。

講了這么多，對于幫助中心的設計，我們只有了解到宏觀的內容過后，才能夠進行更多微觀的設計。

而體系的搭建，也是一個循序漸進的過程，因此我們在設計時，需要不斷反復思考才行。

希望大家能夠根據階段，合理的搭建幫助體系。