怎么寫產品幫助文檔才能幫助用戶？

產品幫助文檔篇幅視產品的復雜度來定，有大有小。幫助文檔可以向用戶展示業務操作步驟，使用戶能夠邊看邊操作。

尼爾森十大互動原則的最后一個原則——“人性化幫助原則”建議我們應該向系統提供幫助文檔，以便用戶能夠盡快理解系統并熟悉操作。

事實上，用戶友好的概念，我接觸的第一件事是“幫助”。那時，老師說如果你遇到不能解決的問題，你可以去“幫助”找到相應的解決方案。雖然我當時不知道，但我很少使用這些幫助程序。但當時我認為這個軟件對小白很友好，它告訴我們如何使用這個東西。雖然當時的幫助文件并不了解小學生。那是另一個問題。

在互聯網時代，許多軟件培養了用戶習慣。用戶在使用大多數軟件時都有“沒有老師”的感覺。但面對To B軟件，特別是對于具有復雜和深入業務的大型To B軟件，用戶將無能為力。

那么此時，易于理解的幫助手冊尤為重要。如果幫助文檔寫得很好，它不僅給用戶留下了良好的印象，而且還大大降低了培訓成本。產品幫助文檔的長度很大，很小，具體取決于產品的復雜程度。

可能有兩種類型的幫助文檔。一個是網站上的幫助中心。幫助中心問題是一般性問題，例如公司、產品的定價和版本選擇。問題;幫助文檔一般嵌入在系統中，側重于向用戶顯示業務步驟，用戶可以在觀看時進行操作。

一個、幫助中心

在一些擁有較大系統的網站上，通常會有一個“幫助中心”模塊，其中包含有關用戶想要了解的產品的內容。

1. 騰訊云

騰訊云算是一個典型的例子了。由于旗下有很多產品，所以幫助文檔也整合成了一個平臺，匯集了所有產品的幫助文檔。用戶可以通過類型查找、輸入關鍵詞搜索找到自己想要了解的產品文檔。

當點進具體的產品文檔，可以看到產品文檔由多個部分組成。從產品介紹、購買說明、名詞解釋到使用場景、業務操作、常見問題說明，整個幫助文檔可以說是分類明晰，簡單易懂。

商業智能分析的幫助文檔

除了文字幫助文檔，騰訊云文檔平臺還有視頻教程，即云學院幫助用戶了解產品以及熟悉操作。

云學院

如果說上述的幫助文檔是幫助小白了解產品，那么“API中心”和“SDK中心”則是提供給開發人員的幫助文檔。

API中心

SDK中心

2. 阿里云

和騰訊云類似，阿里云的幫助文檔也是系統而詳細：既有文字文檔，又有學習視頻。和騰訊云略微有些不同的是，阿里云的文檔有非常詳細的基于系統的業務操作指導。這本應該是內嵌在系統內的幫助文檔，但是阿里云卻把這些詳細的文檔放在了平臺里。

詳細的充值流程

可以看到，除了詳細的充值流程，還有例外情況說明以及常見問題的解答。這不僅僅是一份幫助文檔，如果用心去鉆研的話，這也可以是一份詳細產品學習資料。不得不說，開源的很徹底，很優秀。

3. sales force

相對于騰訊云、阿里云的詳細的幫助文檔，著名的SaaS產品salesforce的幫助文檔就不涉及具體操作。可以看出，對于具體的業務流程，Salesforce是傾向于引導用戶申請免費試用的。

因為在常規的產品概述、功能介紹中涉及到具體的操作流程，都會跳轉到申請免費試用的頁面。Salesforce的問題解答主要集中在FAQ（常見問題解答）里了。FAQ里的問題是常見的一些小白用戶對于產品的一些入門、定價、實施問題。下面以SalesCloud為例子：

如果說Salesforce的幫助文檔很簡單，這也不公平。除了產品介紹和FAQ，它在整個幫助文檔中還附上了很多鏈接，這些鏈接中會有一些其他的講解頁面，或者說是一些列表，又或者說是一些說明書。

比如我就找到了一份實施指南。但是里面也是簡單的介紹，并沒有具體的流程。

4. Word

上文說到了Word的幫助，現在Word不僅在軟件里有幫助文檔，在網站上也有“幫助和培訓”。

軟件里的幫助

網站里的幫助和支持

Word軟件里內嵌的是常見問題解答，網站里的幫助和培訓則是詳細的操作流程。其實如果是將網站的鏈接放在軟件里的“幫助和培訓”里顯眼的地方的話，那應該是最好的。

二、內嵌幫助文檔

說完了那些文檔平臺的幫助文檔，現在來說一說系統內嵌的幫助文檔。系統內嵌的幫助文檔主要是幫助用戶了解操作流程。尼爾森認為幫助文檔的重點是“任何幫助信息都應該可以方便地搜索到，以用戶的任務為核心，列出相應的步驟，但文字不要太多”。

軟件里的內嵌的幫助文檔看似簡單，但其實細節也很多。有的軟件的幫助文檔的布局排版都非常隨意，而且內容全部都是文字，或者全部都是圖片，一眼看過去，密密麻麻，找不到重點。那么，內嵌的幫助文檔應該要怎么寫呢？

1. 流程清晰

產品在寫幫助文檔的時候，首先自己要非常熟悉流程以及各個流程中狀態的變化。比如說，手工入賬、管家結賬，那么產品經理應該自己首先弄清楚什么時候會在手工入賬產生記錄，什么操作會改變賬單的狀態等等。

如果產品自己不清楚，自然而然在幫助文檔里寫的也是非常糊涂的。此外，如果一個流程牽扯到多個終端，那么也要寫清楚在各個終端的操作會引發什么狀態，即記錄全流程。比如說手機端進行的操作會引發Web端的變化，這也要寫清楚。

2. 文字要少

幫助文檔中，文字不能太多，主要是描寫步驟。然后輔助截圖，以箭頭指示操作按鈕。

如果幫助文檔文字太多，會影響用戶的閱讀體驗，讓用戶沒有耐心閱讀下去。

3. 展示重要問題

我開始寫產品文檔的時候，容易將產品文檔寫成各個模塊的說明文檔。因為有一些模塊是展示模塊，不涉及流程，也沒有復雜的功能，對于這些模塊就是圖片加上干巴巴幾句介紹。這樣就導致寫出來的幫助文檔篇幅很長，沒有重點，可閱讀性也不高。所以在寫的時候，要思考用戶最關心的問題是什么，以及這個模塊里復雜的業務流程有哪些。

房源的查看、賬單的查看，這些簡單的問題，完全不需要介紹，用戶自然而然地就知道。而對于那些錄入房源、手工入賬、提現放款這些稍微深一些的業務問題才是用戶想看的。所以產品在寫之前，可以提煉出自己所負責的模塊的一些重要流程以及主要操作。然后在此基礎上，想著怎樣以最少的文字進行最全面的講解。