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

01 前言

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

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

明確需求的目的

明確目標使用者

明確使用場景

形成解決方案

最小代價驗證方案

調整並完善方案（編寫文件到這一步就可以結束了）

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

編寫目的：

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

目標使用者：

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

使用場景：

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

03 形成解決方案

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

明確的目錄結構

，既能讓使用者對系統有個整體全面的認識，又能方便使用者查詢

功能概述

，根據目錄的劃分，對功能進行簡要介紹，說明這個功能是幹什麼的

詳細操作步驟

，介紹每一步該怎麼做，有什麼注意事項

1. 目錄結構

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

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

如果系統目錄劃分比較清晰，詳細的功能可以按照目錄來劃分。這裡to B系統的產品經理應該很熟悉。如果不清晰，建議先最佳化系統目錄。或者系統功能本身很瑣碎，操作手冊可以按照事項來劃分。

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

2. 功能概述

功能概述的目的是讓手冊使用者（很可能對系統完全不瞭解）對某個功能有一個整體的認識，知道為什麼又這個功能，這個功能是幹什麼的，透過哪些步驟可以完成相關功能。可以讓其它業務線的小夥伴來看你的描述，如果一看就懂，說明寫的不錯。沒看懂的話可以與其進行溝通，看疑問的點在哪裡，有針對性的調整描述。

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

3. 詳細操作步驟

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

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

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

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

圈出每個步驟需要點選的按鈕的位置

標明第一步點選哪裡第二步點選哪裡

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

04 驗證並完善方案

1. 小範圍釋出

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

2. 根據反饋進行調整

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

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

05 幾點經驗

1. 版本管理

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

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

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

2. 明確/申明概念

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

3. 格式統一

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

文件格式。文件標題、正文、表頭等內容格式統一。

表達格式。比如描述按鈕時統一用，描述系統提示時統一用“”等等，這個在手冊內統一即可。

4. 其它形式的操作手冊

頁面內的提示文字對於容易產生疑問的地方，用簡短的提示文字解釋。可以直接寫在頁面上，也可以增加小圖示，點選後檢視提示；根據提示的重要程度進行設計。文字一定要簡短易懂。

常見問題解答這個模組可在操作手冊中增加，也可以在系統中提供相關頁面。系統中提供頁面的優勢在於隨時可檢視，而且可以根據使用者當前的頁面，將與頁面相關的問題排在前面。

影片通過錄制影片進行講解，相對於文字更容易理解，可作為操作手冊的補充。

簡化系統的操作邏輯。

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

本文由 @率然 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。