用戶使用說明書，是為了能夠讓用戶能更清晰地使用產品而編寫的。作者提到了一個編寫的小技巧，就是把它當成一個需求來處理，那么具體要如何編寫，注意哪些細節？作者從明確需求的目的到最后的調整和完善都做出了詳細的講解，歡迎閱讀。

01 前言

最近主導了幾個項目操作手冊的編寫。有新開發的項目，要重新編寫操作手冊；有中途接手別的項目，后來功能迭代，需要更新原操作手冊；有客戶對操作手冊有意見，需要調整；零零散散寫了數萬字的手冊。

其實寫操作手冊或者叫用戶使用說明書可以當作一個需求來處理。既然是需求，那么處理需求的幾個主要步驟對于產品經理來說就是輕車熟路了。

1. 明確需求的目的
2. 明確目標用戶
3. 明確使用場景
4. 形成解決方案
5. 最小代價驗證方案
6. 調整并完善方案（編寫文檔到這一步就可以結束了）

02 明確編寫目的、目標用戶、使用場景

編寫目的：操作手冊就是介紹系統如何操作。對于交付型的項目，在交付的時候需要有這個文檔。對于to B的項目，一般也會為客戶提供該文檔。即便目前有多種為用戶介紹系統如何使用的方式，但是這個手冊作為一個全面、詳細的文檔，在一些場景下還是有必要的。

目標用戶：客服人員、系統用戶（注意可能會有多個角色，比如管理員、操作員、被管理人員等）。

使用場景：客服人員多是軟件的開發方的人員，當系統大到一定程度后，一些詳細的規則單靠記憶很難覆蓋，在遺忘的時候可以拿操作手冊作為參考。一個是軟件的實際使用人員，在遇到問題又找不到客服時，可通過操作手冊進行快速查找。綜合來看主要是兩個場景：

1. 從頭開始認識一個功能。
2. 查找某個功能的某一步的詳細規則。

03 形成解決方案

針對編寫目的、用戶、場景，總結出操作手冊必備的幾個要素。

1. 明確的目錄結構，既能讓用戶對系統有個整體全面的認識，又能方便用戶查找
2. 功能概述，根據目錄的劃分，對功能進行簡要介紹，說明這個功能是干什么的
3. 詳細操作步驟，介紹每一步該怎么做，有什么注意事項

1. 目錄結構

一般操作手冊會根據不同的人有不同的版本，但是如果為每個人單獨寫一份，這個工作量就太大了。最好在寫的時候就按使用人來劃分，這樣就可以只寫管理員（擁有系統全部權限）版本，然后將管理員版本中的部分摘出來即可形成多個版本。

比如一個系統有移動端和PC端，如果PC端作為管理、配置功能，給操作員用。PC端是展示，給管理者用，那么目錄可以分移動端和PC端，然后再分更細的功能；如果同一個用戶既可以在移動端完成該功能，又可以在PC端完成，那么目錄可以按照功能進行劃分。按照這樣的邏輯劃分就可以達到上述目的。

如果系統目錄劃分比較清晰，詳細的功能可以按照目錄來劃分。這里to B系統的產品經理應該很熟悉。如果不清晰，建議先優化系統目錄?；蛘呦到y功能本身很瑣碎，操作手冊可以按照事項來劃分。

比如某項信息要在前端展示，需要經歷信息的上傳、審核、發布等流程。那么既可以分開介紹某各流程具體怎么操作，也可以將信息怎么發布作為一個模塊來整體介紹，或者寫一個整體的流程框架，具體某步驟參照某章節。具體寫法需根據系統的實際情況來判斷。

2. 功能概述

功能概述的目的是讓手冊使用者（很可能對系統完全不了解）對某個功能有一個整體的認識，知道為什么又這個功能，這個功能是干什么的，通過哪些步驟可以完成相關功能?？梢宰屍渌鼧I務線的小伙伴來看你的描述，如果一看就懂，說明寫的不錯。沒看懂的話可以與其進行溝通，看疑問的點在哪里，有針對性的調整描述。

可以如果流程較為復雜，可以用流程圖等來輔助說明。

3. 詳細操作步驟

每一步具體怎么操作，點擊哪個按鈕，填寫哪些字段。各個按鈕點擊有什么效果，字段填寫有什么意義會影響到哪里。這些內容該怎么寫，主要是根據頁面和功能的種類。

比如列表頁，如果都是些根據名稱能知道含義的字段，那么就不需要介紹。如果有些容易混淆的詞，比如“更新時間”是只有用戶在當前頁面對數據修改進行記錄，還是在其它頁面做修改，導致該頁面的數據產生變化時也做記錄。

這時候需要說明，否則用戶在使用過程中會進行大量的提問。如果系統有專有名詞，也需要進行描述。（最好單獨用一小節對其進行統一介紹）

圖片是操作手冊的重要部分。但不能把系統上的圖直接放在操作手冊中。有幾個需要注意的點：

1. 圈出每個步驟需要點擊的按鈕的位置
2. 標明第一步點擊哪里第二步點擊哪里

做到這兩點已經很清晰了。在大量的實踐中，我發現最好把同一個功能里的幾個步驟做一個長圖，這樣在文檔中查看時不會形成大量的空白部分，能夠更快的看出每個步驟是什么。如果客戶沒有看操作手冊，直接問，客服可以把長圖給他。

04 驗證并完善方案

1. 小范圍發布

寫好后，可以讓公司其它小伙伴看一下，最好是目標用戶。比如你手冊的目標用戶是運維，可以找其它產品線的運維伙伴來看。比如你的目標用戶是客戶，可以先小范圍發給典型客戶或關系較好的客戶，收集問題，對操作手冊進行調整。這個類似于產品的初步驗證，用草圖、原型各種能讓用戶理解體會到產品流程的方式，對產品進行初步的體驗并提出意見。

2. 根據反饋進行調整

目標用戶對操作手冊的反饋主要有兩個方面。一個是用戶的直接反饋，一個是用戶的使用方式。

用戶閱讀手冊后，可以與用戶溝通使用意見，看哪里不容易理解，哪里查看起來不方便，以此來調整手冊的結構及表達方式。另外可以觀察用戶如何查閱手冊，看針對幾個特殊場景（初次使用時的整體閱讀及查詢某個細節時尋找解決方法）的使用情況，來發掘文檔可能存在的優化點。這個相當于既要通過訪談的方式溝通用戶對產品的意見，又要通過觀察的方式找出用戶在使用中遇到的問題。

05 幾點經驗

1. 版本管理

首先有一個操作手冊基線版本，在第一次寫完后記錄當前操作手冊對應的系統版本。然后根據系統的升級情況，會逐步往操作手冊中增加內容，此時需記錄每次都增加了哪些內容，對應了系統的哪些版本。

因為系統更新后不一定每次都有時間立即更新操作手冊，而且當操作手冊的規模大到一定程度，再去核對手冊跟系統的區別，將耗費大量的時間且操作起來極其繁瑣。

可在手冊中增加一個小節對此進行專門記錄，寫明手冊版本、更改人、更改時間、更改內容。如有必要可增加審核人及審核時間。

2. 明確/申明概念

將系統中特有名詞進行解釋。這些內容在系統設計之初應該有相關描述，可根據需要進行摘錄。明確了概念才能順暢溝通，而且很多問題本身也是不知道概念才產生的。

3. 格式統一

主要是為了方便閱讀。查看起來文檔美觀，查找相關內容也比較方便。寫之前先定好規范，審核文檔時作為審核項。修改文檔前先看一下其它章節，不至于每次增加內容有用新的格式。文檔格式主要有下面兩種。

1. 文檔格式。文檔標題、正文、表頭等內容格式統一。
2. 表達格式。比如描述按鈕時統一用【】，描述系統提示時統一用“”等等，這個在手冊內統一即可。

4. 其它形式的操作手冊

1. 頁面內的提示文字對于容易產生疑問的地方，用簡短的提示文字解釋?？梢灾苯訉懺陧撁嫔?，也可以增加小圖標，點擊后查看提示；根據提示的重要程度進行設計。文字一定要簡短易懂。
2. 常見問題解答這個模塊可在操作手冊中增加，也可以在系統中提供相關頁面。系統中提供頁面的優勢在于隨時可查看，而且可以根據用戶當前的頁面，將與頁面相關的問題排在前面。
3. 視頻通過錄制視頻進行講解，相對于文字更容易理解，可作為操作手冊的補充。
4. 簡化系統的操作邏輯。

最好的操作手冊是不用操作手冊用戶上手即會用。操作手冊是系統的一部分，那么手冊的理想狀態是沒有手冊。通過優化系統、將提示融入系統等等方式可向這個理想艱難前行。