使用手冊該怎么寫？_ai

文章圖片

文章圖片

許多產品團隊往往忽視了使用手冊的重要性，或者在編寫時缺乏系統性和針對性。本文將深入探討使用手冊的核心價值、主要內容、編寫方法以及管理維度，幫助產品團隊打造一份高質量的使用手冊，從而更好地滿足用戶需求，提升產品的市場競爭力。

一、什么是使用手冊？目的又是什么？使用手冊，又稱用戶使用說明書，是產品和用戶之間橋梁，核心目的是指導用戶使用產品；
優秀的產品是不需要使用手冊的，讓用戶的使用能夠沉浸式使用產品，才是最佳狀態；
對于B端產品，尤其是交付型產品，為客戶提供手冊是必備的環節，因為B端產品業務結構復雜，通常附帶業務全流程的表達以及內部管理規范體系，針對業務數據的流轉和特性業務字段需要有統一的執行標準和操作規范，故而在實際的B端產品落地過程中，需要提供必要的產品培訓；
產品培訓只能解決一時的問題，對于B端用戶日常的使用過程中，難免會有遺忘或者不知如何變動表達，甚至在使用過程中遇到問題時，也不知道如何進行解決，故而使用手冊更多執行的作用有兩種：操作指引、運維指南；
故而使用手冊主要的目的如下：

為用戶提供系統操作的全面指南
為用戶提供潛在問題的解決方案
為用戶提供產品使用的最佳實踐

二、使用手冊有什么價值？許多B端產品的使用手冊，是功能的集合或者功能模塊的描述，也是按照一定的套路和格式模版所寫，但是使用手冊的制作過程一般是產品做完以后，這就導致使用手冊的價值瞬間淪為產品的附屬物，也就喪失了其獨特的價值；
關于使用手冊的價值分析，我們用常用的5why分析法：

為什么要有使用手冊？ — 用戶需要手冊，指導他們使用產品
為什么需要指導用戶使用產品？ — 產品有一定的復雜度
產品為什么會復雜？ — 業務復雜
業務雖然復雜，但用戶最懂業務，為什么不會使用產品？ — 產品功能分散，用戶不知道入口，且不知道如何和業務做映射，即便是知道了怎么使用，但是也不知道怎么才算高效
產品是業務的表達，應該最貼近業務，且能夠解決用戶日常工作的效率問題，為什么對用戶會有阻塞？（包括入口、業務映射、最佳實踐） — 業務千變萬化，不能按照每一個業務需求來進行產品表達，需要進行抽象，依托抽象出來的模塊、功能等進行組裝，來滿足用戶的需要；且各家業務不同，業務表達上也不盡相同，需要用戶理解產品實現和業務之間的映射；
為什么不能提供統一的業務需求解決方案？ — 那就需要制定行業標準且推進用戶標準化使用困難比較大
難度主要是什么原因造成的？ — 首先行業不同，即便是同一個行業，各個客戶執行的業務流程和標準都不一樣，所以就要在基礎產品版本上，給客戶做項目化交付
項目化交付，就是按照客戶要求定制的，有什么功能客戶最清楚，提供手冊做什么用？ — 只有提出需求的人了解功能，其他客戶員工還不知道怎么操作，且不同權限，可操作的范圍也不同，會存在斷層，比如A不知道B做了什么，后續環節的C應該怎么做？等等
是不是只有按照角色寫清楚功能操作即可？ — 不光是功能操作，常見的問題也要寫清楚

從以上的問題，我們可以清楚的知道，使用手冊本質是用戶需求的業務化表達，也就是我們常說的用戶故事。
從用戶的角度來看，包括業務流程、業務操作等，從生成者的角度來看，包括功能清單、產品規格等；
對產品生產者來講，可以快速的將產品交付給用戶，快速落地；實際操作過程中，如果針對不同的行業和用戶，有對應的使用手冊，可以通過使用手冊來管理項目的功能清單、規格清單，那么在用戶的后期需求迭代過程中，能夠通過清單快速的完成功能迭代和項目交付，也就可以快速的提高交付效率；
對產品使用者來講，通過使用手冊，可以快速的知道某個業務的流程及操作步驟，指導用戶進行功能隔離，規避人員權限失控，且通過流程化執行，讓業務參與者清楚的知道上下游的協作，可以有效的提升內部的運營效率；
故而，使用手冊的主要價值：
1）對生產者：提高交付效率、降低交付成本、降低內部管理和維護成本
2）對使用者：降低培訓成本、減少運營事故、提高運營效率

三、使用手冊有哪些形式？早期互聯網不是很發達的時候，使用手冊更多的是以圖文/書籍方式，同產品一起交付的，可閱讀性比較差，這種形式的使用手冊核心的表達在于索引目錄的編寫和關鍵功能的提取，期望用戶能夠依據自身的問題，快速通過目錄查找 / 檢索關鍵功能，快速定位；
隨著4G的普及，數據傳播效率的極大提升，視頻方式逐漸普及，用戶不必再去閱讀圖文，可以極其快速學習；但視頻表達也有局限性，視頻本質是一段有邏輯的腳本的可視化表達，所以視頻通常是一整段的功能/操作的使用，所以特別冗長，對于特定問題的解決就顯的乏力；這種情況下，一般B端產品會同時提供文本型手冊，方便用戶進行查閱；
在短視頻逐漸流行起來后，使用手冊又可以增加一種表現形式，短視頻的特點就是“短” ，所以特別適合碎片化的功能使用介紹和特定場景的用戶操作指導；
2024年我們有幸進入了AI時代， AI使用時可以不必在固定的框架內，讓用戶去尋找答案，而是根據用戶的描述，由算力綜合計算，給予用戶最終的分析結果，對用戶更加友好，但目前還沒有見過一家B端產品，給客戶提供AI解決方案，主要原因還是目前AI成本太高；
不論采用什么形式，其實底層的內容仍是早期的圖文，只是現在有了更高效的表達方式而已，所以對于B端產品仍然還是要有砌磚的心態；

四、使用手冊的主要內容？1、業務能力領域一個完整的B端產品，必然會涉及較多的內外部系統的連接，以便完成業務的串通，而針對用戶來說，各個系統之間是由什么部門執行？具體執行哪些內容？核心數據之間是如何流轉的？等等，類似這樣的問題，對每一個用戶來講，都是需要清楚知道的；這樣，每個用戶就能夠自行帶入角色進入產品的世界中，知道了自己所處的板塊和位置，以及上下游之間的聯系；
業務能力領域應該包括主要內容以及目的：

2、功能清單功能清單是指產品領域下，產品功能的集合，包括功能描述、使用場景等，便于產品生產者對產品功能維護和使用者對產品功能的查閱；功能清單應該根據產品完整的結構，梳理出樹形結構功能列表，詳細介紹用戶所能見到的所有功能及功能描述；
功能清單的基礎結構如下：
對功能操作和交互來講， B端產品在不同的子系統/模塊中，存在大量相同含義的操作和獨屬于某個對象/業務的操作；產品的一致性就顯的非常重要，讓用戶能夠對相同含義的操作不至于迷路，也能夠對個性功能有清晰的認知，在使用的時候，能夠快速找到功能入口和保證使用的一致；
對于功能來講：一致性包括功能的一致性、交互的一致性（也就是說，整個產品前端要保證一致的描述），舉幾個常見的例子：

如新建，有些頁面是新建XX、有些就是新建/新增；這就是缺乏一致性，要不都叫新增，要不都叫新建，格式要不都是新增，要不都是新增XX；
如二次確認，有些是toast提示+操作，有些是hover提示+操作，有些是提示框+操作，有些同學可能會說提示的強度不一樣，這種想法是不對的，針對同一類功能操作來講，應該要保持一致的交互，一致的提示，一致的格式，這樣對于使用者來講，才是最友好的，交互本身也是一種認知理解，強度是無法明確告訴用戶的，對于用戶來講都是二次確認；
如表單，有些是抽屜，有些是表單，這也屬于不一致的體現；

題外話：針對交互來講，功能是源頭，交互是表象；同一類的功能應保持一致的交互；比如新建/修改都使用抽屜，修改用戶等級、添加標簽等都使用彈窗；（可以思考一下：修改、修改用戶等級都是修改，他們功能的區別是什么？）

3、規格清單做產品的應該都知道，軟件產品本就是對現實世界的業務體現，而軟件產品在表達現實世界中的內容時，主要通過屬性進行表述和數據庫中表字段進行存儲；其中，屬性和字段都是有唯一來源的，所代表的含義也應該是唯一的，這樣基于資源規格管理的方式，無論是維護管理還是實際使用時都會有清晰且一致的認知；
很多產品的使用手冊中，都是將操作和屬性雜糅在一起；這樣的方式雖然是方便用戶操作時能夠快速知道每一個屬性/字段如何填寫，實際上是沒有區分出功能和規格的差異；
比如用戶名（user_name），是用戶這個對象的一個關鍵屬性，無論是用在表單上還是列表上，還是用在任何一個地方，他都代表用戶名，表述的都是用戶的姓名；用戶名唯一的來源就是用戶，代表的唯一含義就是用戶名稱，至于其他的如：長度、首個字符不能輸入特殊符合等，都是用戶名的校驗規則；
也就是說，對于任何對象/資源都有自身的屬性，而屬性又有自身的約束，這些屬性和約束稱之為規格；規格清單，就是整個產品中的對象/資源屬性描述清單；
規格清單的目的是方便用戶在對應功能使用的時候，能夠清楚的知道，每個屬性的含義及其使用約束，讓用戶在使用功能的時候，能夠通過查閱規格清單，了解每個屬性的業務含義，并在使用過程中，清楚的知道限制范圍和使用規范；

4、用戶故事對于使用手冊來講，用戶更加關注：我[用戶角色
如何才能實現什么功能或者解決什么問題？
想象一下，當我們使用一個B端產品的時候，我們會關注左側的菜單都有什么嗎？至少我本人是不怎么關心的，在系統使用的過程中，我其實更關心遇到問題如何解決？
如電腦壞了，怎么樣才能申領一臺電腦？老板讓我做一個發布一個營銷活動，我該怎么樣發布一個活動？我沒有XX功能的權限，該如何申請權限？…
如果你按照功能清單的順序，寫了一大堆的使用手冊，那用戶是會崩潰的。因為想要發布一個活動，起碼要涉及到產品管理、活動管理、用戶管理、內部組織管理、消息通知管理等等，是一個完整鏈路和體系的工作，還會因為角色的不同，所承擔的工作和職責是不同的，所以教用戶使用產品的手冊，絕對不能按照功能清單結構搭建；
筆者認為，真正的產品使用手冊，應該主要從以下維度展開：業務域、用戶故事、角色（職位），如活動管理
在使用手冊實際執行的過程中，應該按照業務域&用戶故事，分角色（崗位）提供使用手冊；
用戶故事也可以按照父級故事、子級故事的方式進行管理；這樣用戶可以快速的根據需要進行查詢和搜索；

5、常見問題解決方案常見問題的解決方案是用戶使用產品的過程中，因外部因素或者用戶自身問題導致的使用問題，能夠讓用戶在不依賴工程師/客服的情況下進行問題處理；
比如因為硬件損壞而造成的系統不可用、瀏覽器緩存過大導致系統延遲卡頓等等
當然狀態最佳的產品是應該沒有常見問題的，但是一般是做不到的，尤其是配置性的產品功能，即容易因為用戶在使用過程中，造成系統錯誤，一般情況下我們可以將此類問題歸集到運維手冊中，給予系統管理員或者交付工程師進行查閱；
也有一些需要給予用戶常見問題的處理措施，如賬號token過期、網絡中斷如何恢復文件等；
所以常見問題解決方案，主要面對兩大類角色：運維人員–提供運維手冊、產品使用人員–常見問題QA；

6、最佳實踐范例一個B端產品，如果只是售賣軟件產品，將是毫無長遠價值的；回歸到B端產品的用戶本質需求來看，客戶之所以花大價錢購買軟件產品，大多是離不開合規、標準、數字化這3個因素；
回到原點來思考，不使用該產品就不能做生意了嗎？肯定是可以繼續做生意的，只不過不同行業依賴度不同而已；
比如做煤炭銷售的，不用軟件產品還是可以繼續賣煤炭的，可以脫離軟件產品，繼續做生意的；如果是做股票的， 90年代沒有軟件的時候，通過賬本記賬仍然是可以交易的，就是效率比較低，但是現在就不行了，合規性就過不了，就無法將生意繼續下去；
所以， B端產品需求是隨依賴度提高而提高的；天下攘攘皆為利往，需求強競爭也就激烈，早年可以享受時代的紅利，越往后發展將逐漸陷入白熱化的拼刺刀狀態；現如今，多數軟件開發公司的財報都是虧損的，根因就在于競爭過于激烈，鄙人曾親眼看過，普遍報價在600W左右的項目，被一家報價300W的拿下；不要責怪市場，尤其是做B端軟件產品的，因為代碼的邊際成本是逐漸降低的，所以軟件市場會有先行者優勢。
從我們天天用的手機談起，一個手機是沒有價值的，只有搭配上相機、音樂、游戲等軟件，這個手機才是有價值的，鄙人是很討厭某些品牌天天堆硬件參數，喪失了真正應該挖掘的價值，即人機交互的創新，比如如何通過手機實現更真實的通信？假如把我們的手電筒多裝幾個，可以形成三維投影，是否不就可以實現虛擬的立體人物，直接對話呢？（這是想象，因為不懂這些技術，但不代表技術上做不到），假如這個功能實現，不比測評跑5萬分更有產品力嗎！，而且必須要通過相機的功能，間接就不需要什么微信了！干掉微信不是夢！
同比到B端軟件產品上，賣一次產品就等于賣一個手機，只講產品有什么模塊、有什么功能點，是沒有營養的！要講怎么才能用我的產品玩的花！這就是最佳實踐，這么用就是好用，就是有效！同時，這些最佳實踐就是長在自身產品的基礎上的，別人想模仿都不一定能模仿，因為缺少軟資產，這一塊各家有各家的優勢，這里只講一下最佳實踐范例的作用，至于用什么方式呈現，看客戶的需要了；

五、使用手冊的管理維度？B端產品和客戶天然就是1對N的關系，且隨著產品的不斷迭代，產品也會衍生出很多版本，逐漸就會形成產品與客戶N對N的關系，如何管理這些手冊，也就成為了一個問題；
不過同類問題，在代碼管理上，已經有了成熟的解決方案，即方法引用和git倉庫的管理體系，手冊也可以進行借鑒；所以手冊可以從兩個維度上進行管理

產品級和工程級：產品級實現基礎能力，工程級采用引用產品級+工程定制點進行管理；
版本管理：同一個產品會不斷迭代版本，那么對應的手冊也可以按照版本分支進行管理；

六、綜上，總結一下要點手冊生產階段應該貫穿整個產品生命周期，不應該放在產品交付前；
手冊應該包括：業務能力領域、功能清單、規格清單、用戶故事、最佳實踐；
手冊管理維度：產品級和工程級、版本管理；
本文由@七月泮原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash ，基于 CC0 協議
【使用手冊該怎么寫？】該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。