怎么寫幫助文檔？產品人看過來

隨著信息化的快速發展，對絕大部分企業來說，打造站點幫助中心已是當下勢不可擋的發展趨勢。

在互聯網時代，很多軟件都把用戶習慣培養起來了。用戶對大部分軟件的使用都有一種“無師自通”的感覺。但是在To B軟件面前，尤其是業務復雜且深入的大型To B軟件，用戶會顯得有些束手無策。

那么這個時候，一份簡單易懂的幫助手冊就顯得尤其重要。如果幫助文檔寫得好，不僅能夠給用戶留下良好印象，同時還能大大減小培訓成本。產品幫助文檔的篇幅有大有小，這個視產品的復雜度來定。

幫助文檔其實大概有兩類，一類是在網站上的“幫助中心”，幫助中心的問題是一些通用的問題，比如這款軟件適合哪類規模的公司、產品的定價和版本選擇等等入門問題；而幫助文檔一般是內嵌在系統里的，著重于向用戶展示業務操作步驟，用戶可以邊看邊操作。

良好的幫助中心網站架構良好并精心呈現，使客戶可以輕松瀏覽網站并找到他們要搜索的內容。

幫助中心應始終易于搜索，為客戶提供品牌知識庫的可訪問版本，該幫助中心應以用戶體驗為核心。該站點通常會包含常見問題解答、文章和各種說明，所有內容都應具有易于理解。

幫助臺中心降低了與客戶服務相關的成本，同時改善了客戶體驗。

幫助臺中心為客戶提供一直被問到的問題的答案，使消費者更容易訪問他們需要的信息，而無需聯系客戶服務團隊的成員。因此，可以快速處理常見查詢，讓客戶服務團隊有更多時間專注于需要他們注意的復雜問題。

幫助臺中心為任何需要它們的人提供大量資源，使品牌能夠改進其產品并優化客戶旅程。

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

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

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

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

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

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

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

尼爾森的交互原則中，有一條就是“一致性原則”。這對幫助文檔也適用。由于一般會是不同的產品負責不同的模塊，所以如果不在一開始的時候統一模板，這會導致最后呈現出來的效果很容易五花八門亂七八糟。

幫助文檔的模板最好是使用統一的模板，然后在頁面上展示公司姓名和logo。

樣式其實有很多，有word、有ppt、有pdf文檔。現在看下來，樣式比較好的就是用ppt做好，然后轉成pdf格式，這樣的話，不管是頁面展示還是在線觀看，體驗都更好一些。

內嵌的幫助文檔也需要常見問題說明，尤其是一些常見的異常情況，更需要提醒。比如說一些隱性的限制，拒絕結算放款后第二天會自動進行結算發起放款申請，由于這些是通過定時任務來進行，很難在頁面中告訴用戶。所以可以在幫助文檔中，解答用戶的這些疑問。

不論是搭建網站幫助中心還是制作產品內嵌幫助文檔，其實使用一款軟件就可以輕松解決。

Baklib是一款優雅的云知識庫構建平臺， 基于人工智能技術，可幫助公司在線制作，知識庫，幫助中心，指南，FAQ, API文檔，產品手冊。幫助企業實現向內知識協同和對外產品宣傳的網站內容管理。

只需簡單四步，即可完成整個站點的搭建，之后就可以正式地進行幫助中心和文檔的內容撰寫，完成網站幫助中心和內嵌幫助文檔的創建。

總結起來，無論是選擇搭建網站幫助中心還是撰寫內嵌幫助文檔，都可以有效地改善客戶服務，提高工作效率，并且只要使用簡單的工具就可以實現。