軟件的使用說明書例子?用戶使用說明書，是為了能夠讓用戶能更清晰地使用産品而編寫的作者提到了一個編寫的小技巧，就是把它當成一個需求來處理，那麼具體要如何編寫，注意哪些細節？作者從明确需求的目的到最後的調整和完善都做出了詳細的講解，歡迎閱讀，今天小編就來聊一聊關于軟件的使用說明書例子?接下來我們就一起去研究一下吧!

軟件的使用說明書例子

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

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

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

明确需求的目的

明确目标用戶

明确使用場景

形成解決方案

最小代價驗證方案

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

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

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

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

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

明确的目錄結構，既能讓用戶對系統有個整體全面的認識，又能方便用戶查找

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

詳細操作步驟，介紹每一步該怎麼做，有什麼注意事項

1. 目錄結構

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

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

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

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

2. 功能概述

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

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

3. 詳細操作步驟

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

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

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

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

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

标明第一步點擊哪裡第二步點擊哪裡

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

1. 小範圍發布

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

2. 根據反饋進行調整

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

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

1. 版本管理

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

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

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

2. 明确/申明概念

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

3. 格式統一

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

文檔格式。文檔标題、正文、表頭等内容格式統一。

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

4. 其它形式的操作手冊

頁面内的提示文字對于容易産生疑問的地方，用簡短的提示文字解釋。可以直接寫在頁面上，也可以增加小圖标，點擊後查看提示；根據提示的重要程度進行設計。文字一定要簡短易懂。

常見問題解答這個模塊可在操作手冊中增加，也可以在系統中提供相關頁面。系統中提供頁面的優勢在于随時可查看，而且可以根據用戶當前的頁面，将與頁面相關的問題排在前面。

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

簡化系統的操作邏輯。

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

本文由 @率然 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。