你的用戶真的需要操作手冊
編輯導語:操作手冊是詳細描述軟件的功能、性能和用戶界面,使用戶了解到如何使用該軟件的說明書。很多時候,當我們對產品的某個功能感到困惑時,往往需要一份操作手冊來幫助我們解答疑惑。在本篇文章中,作者就對操作手冊的目的、原則、層級目錄等進行了分析。
最近在整理之前留下的債,剛好寫到了操作手冊,就有一些寫操作手冊的感悟和心得方法,與大家分享一下。以下內容僅針對于B端產品或者BtoC產品中的B端側,C端產品最理想的狀態是不需要操作手冊,簡單易懂即可。
一、傳統的操作手冊
傳統的操作手冊通常由引言、編寫目的、背景意義、產品概述、產品功能描述等等冗長的內容組成,而這些真的是用戶想要的么?或者這些真的是用戶所關心的么?
下面舉個例子,操作手冊如下,大致分為三部分:前言、系統概述、系統操作。
無論寫什么文檔,文檔完整性一定要保持文檔封面,文檔目錄,前言。雖然這些是次要的東西,可寫可不寫,我個人習慣無論是對外輸出什么文檔,我都要將這些寫上。
- 前言一般包括文檔目的、文檔讀者、術語定義;
- 系統概述一般包括系統架構圖、功能清單、業務流程圖、崗位職責。這些和需求說明書的寫法一樣,這里主要說下系統操作怎么寫。系統操作是系統的功能操作,從登錄到退出都需要告訴用戶在哪去操作、怎么去使用;
- 在寫系統操作的時候,還需要注意,以用戶的角度思考,寫的時候需要告訴用戶什么功能是誰用的。每個用戶只關心自己用的功能是什么,所以這點需要特別說明。
系統操作一般包括以下部分:
- 業務場景
- 操作角色
- 操作路徑
- 使用注意
- 操作說明
- 業務場景:描寫用戶在什么場景下使用這個功能。
- 操作角色:誰來用這個功能。
- 操作路徑:在哪去用這個功能
- 使用注意:用戶需要注意什么
- 操作說明:按頁面上每個功能按鈕進行說明。
沒錯,很多內容其實你是不需要的,你想知道的只有這個東西在什么場景下怎么用就行,其中的背景、意義、編寫目的,只不過是我們在追求寫作者自己的心里安慰罷了。洋洋灑灑幾百頁,最后用戶體驗卻是極差的。
在這個快節奏的時代,人們往往想要第一時間找到自己想要的信息,而不是在眾多冗余的信息中如大海撈針一般去慢慢尋找。因此,操作手冊應該根據用戶的使用場景和可能遇到的困難進行解答。
配以圖片或者視頻的形式來描述更為妥當,通過流程的方式來確定用戶究竟想要什么樣的操作手冊,顯得更為明智一些。那么,下面筆者將拋析操作手冊的寫法。
二、操作手冊的定義
何為操作手冊,官方的定義如下:操作手冊是詳細描述軟件的功能、性能和用戶界面,使用戶了解到如何使用該軟件的說明書。
看起來很簡單,就是只要說明軟件的功能,并讓你的用戶知道如何使用即可。描述軟件的功能的粒度可大可小,大到模塊級別,小到按鈕級別,那怎樣的一種粒度是用戶最能接受的呢?
三、操作手冊的原則
一本好的操作手冊要有哪些原則?
- 好找:方便用戶找到所需信息,預見用戶可能遇到的問題和解決方法;
- 通俗易懂:內容清晰,語言和設計簡單明了是關鍵;
- 開門見山:讓用戶知道該如何操作,并知道下一步該做什么。
最好采用總分總的形式,即開頭給用戶一個總體的手冊流程概覽,可以是業務的整體流程圖,也可以是下面操作的每一小節的內容。
例如:
四、操作手冊的目的
操作手冊編寫的目的,可以從兩個角度出發:
- 提高用戶使用平臺的操作性,讓用戶成為你產品的主人,服務于你的用戶才能產生價值;
- 減少運營人員解答不必要的問題的時間。例如,所有人都問相同的問題,那么他就應該出現在操作手冊上,或者幫助模塊中。
五、操作手冊的粒度
這個業內沒有標準的答案,只要用戶讀懂即可(這看起來是一句合理的廢話)。其實,筆者認為寫操作手冊應該按照用戶場景來寫,一個閉環的場景即可。
那怎樣是一個閉環的場景呢?
舉個例子:筆者所在的體育產品領域,分為辦賽資料、創建比賽、裁判分配、線上報名、裁判打分、頒獎管理等等。每一塊就是一個完整的流程。用戶做完一個完整的動作,并且得到一個結果。
六、操作手冊的層級目錄
按照上述的粒度,我們會給出一個一級目錄,在一級目錄下,我們又該如何確認二級、三級目錄呢?
我們繼續拿創建比賽為例,創建比賽的過程中每一個頁面都需要完成它應該完成的內容,并對應業務的流轉,我們只需要告訴用戶如何操作即可,如填寫比賽名稱、比賽時間等等,不需要告訴用戶比賽時間的規則為開始時間小于等于結束時間。
因為,我們的用戶并不關心。且BtoC的產品還在用戶了解一定的行業背景下,所以,大家會約定俗成一些事情。
七、操作手冊的編寫內容
用戶都是很懶的,他們不會去看枯燥的文字,就像之前很火的數據大屏一樣以及一直很火的短視頻業務,用戶對于知識的輸入喜愛順序為 視頻 > 圖片 > 文字 。因此,我們需要用圖文混排的形式來告訴用戶如何操作我們的系統。
當然,操作手冊不單單是解決用戶操作流程上面的問題,還需要解決用戶常見的問題。例如:在賽事平臺中,用戶可能會好奇能舉辦那些比賽、參賽的人數限制、解決方案等等。
足夠量的幫助解決和規范的操作手冊能夠提升用戶的黏性并且提出更有價值的產品需求。
八、操作手冊的術語統一
當你使用一款軟件的時候,你希望軟件內的名詞都有統一的說法,我們繼續拿賽事平臺舉例,例如 辦一場比賽的時候,有比賽開始時間、比賽結束時間、報名開始時間、報名結束時間、比賽創建時間、比賽修改時間。
當用戶想要統一一個維度去查詢的時候,例如 查詢一月份的比賽數目,那好了。我們使用比賽開始時間?比賽結束時間?這兩個維度得到的數據是大不相同的。更不能給出一個莫能兩可的“辦賽時間”。
因此,統一平臺操作手冊的術語十分重要。紙上學來終覺淺,絕知此事要躬行。
賽事平臺的操作手冊:https://shimo.im/docs/vXWR9X3TckkvvRcw/
本文由 @當下不雜 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自?Unsplash,基于 CC0 協議
挺好,比較人性化,從可能遇到的問題出發去寫,用戶視角。
作者第一部分,對于傳統冗長做法的態度有些矛盾,表述并不清楚。
個人理解是封面、前言等內容還是需要,后面的系統概述等根據用戶的不同來側重去寫,比如給決策者看,那么他更關注概述的部分,如果給實際操作的人,那么他更關注具體功能的操作。
對,沒看太明白作者對傳統用戶手冊的態度。你說的還是有道理的,如果給普通用戶看,更關心具體使用;如果是給上層人員,還是整體的介紹更重要