2023年写过数万字的操作手册聊聊用户使用说明书该怎么写

写过数万字的操作手册，聊聊用户使用说明书该怎么写？01前言

最近主导了几个项目操作手册的编写。有新开发的项目，要重新编写操作手册；有中途接手别的项目，后来功能迭代，需要更新原操作手册；有客户对操作手册有看法，需要调整；零零散散写了数万字的手册。

其实写操作手册或者叫用户使用说明书可以当作一个需求来处理。既然是需求，那么处理需求的几个主要步骤对于产品经理来说就是轻车熟路了。

明确需求的目的明确目标用户明确使用场景形成解决方案最小代价验证方案调整并完善方案（编写文档到这一步就可以结束了）02明确编写目的、目标用户、使用场景

编写目的：操作手册就是介绍系统如何操作。对于交付型的项目，在交付的时候需要有这个文档。对于toB的项目，一般也会为客户供应该文档。即便目前有多种为用户介绍系统如何使用的方式，但是这个手册作为一个全面、具体的文档，在一些场景下还是有必要的。

目标用户：客服人员、系统用户（留意可能会有多个角色，比如管理员、操作员、被管理人员等）。

使用场景：客服人员多是软件的开发方的人员，当系统大到肯定程度后，一些具体的规章单靠记忆很难掩盖，在遗忘的时候可以拿操作手册作为参考。一个是软件的实际使用人员，在遇到问题又找不到客服时，可通过操作手册进行快速查找。综合来看主要是两个场景：

从头开头熟悉一个功能。查找某个功能的某一步的具体规章。03形成解决方案

针对编写目的、用户、场景，总结出操作手册必备的几个要素。

明确的名目结构，既能让用户对系统有个整体全面的熟悉，又能便利用户查找功能概述，依据名目的划分，对功能进行简要介绍，说明这个功能是干什么的具体操作步骤，介绍每一步该怎么做，有什么留意事项1.名目结构

一般操作手册会依据不同的人有不同的版本，但是假如为每个人单独写一份，这个工作量就太大了。最好在写的时候就按使用人来划分，这样就可以只写管理员（拥有系统全部权限）版本，然后将管理员版本中的部分摘出来即可形成多个版本。

比如一个系统有移动端和PC端，假如PC端作为管理、配置功能，给操作员用。PC端是展现，给管理者用，那么名目可以分移动端和PC端，然后再分更细的功能；假如同一个用户既可以在移动端完成该功能，又可以在PC端完成，那么名目可以根据功能进行划分。根据这样的规律划分就可以达到上述目的。

假如系统名目划分比较清楚，具体的功能可以根据名目来划分。这里toB系统的产品经理应当很熟识。假如不清楚，建议先优化系统名目。或者系统功能本身很琐碎，操作手册可以根据事项来划分。

比如某项信息要在前端展现，需要经受信息的上传、审核、发布等流程。那么既可以分开介绍某各流程详细怎么操作，也可以将信息怎么发布作为一个模块来整体介绍，或者写一个整体的流程框架，详细某步骤参照某章节。详细写法需依据系统的实际状况来推断。

2.功能概述

功能概述的目的是让手册使用者（很可能对系统完全不了解）对某个功能有一个整体的熟悉，知道为什么又这个功能，这个功能是干什么的，通过哪些步骤可以完成相关功能。可以让其它业务线的小伙伴来看你的描述，假如一看就懂，说明写的不错。没看懂的话可以与其进行沟通，看疑问的点在哪里，有针对性的调整描述。

可以假如流程较为简单，可以用流程图等来帮助说明。

3.具体操作步骤

每一步详细怎么操作，点击哪个按钮，填写哪些字段。各个按钮点击有什么效果，字段填写有什么意义会影响到哪里。这些内容该怎么写，主要是依据页面和功能的种类。

比如列表页，假如都是些依据名称能知道含义的字段，那么就不需要介绍。假如有些简单混淆的词，比如“更新时间”是只有用户在当前页面对数据修改进行记录，还是在其它页面做修改，导致该页面的数据产生变化时也做记录。

这时候需要说明，否则用户在使用过程中会进行大量的提问。假如系统有专出名词，也需要进行描述。（最好单独用一小节对其进行统一介绍）

图片是操作手册的重要部分。但不能把系统上的图直接放在操作手册中。有几个需要留意的点：

圈出每个步骤需要点击的按钮的位置标明第一步点击哪里其次步点击哪里做到这两点已经很清楚了。在大量的实践中，我发觉最好把同一个功能里的几个步骤做一个长图，这样在文档中查看时不会形成大量的空白部分，能够更快的看出每个步骤是什么。假如客户没有看操作手册，直接问，客服可以把长图给他。

04验证并完善方案

1.小范围发布

写好后，可以让公司其它小伙伴看一下，最好是目标用户。比如你手册的目标用户是运维，可以找其它产品线的运维伙伴来看。比如你的目标用户是客户，可以先小范围发给典型客户或关系较好的客户，收集问题，对操作手册进行调整。这个类似于产品的初步验证，用草图、原型各种能让用户理解体会到产品流程的方式，对产品进行初步的体验并提出看法。

2.依据反馈进行调整

目标用户对操作手册的反馈主要有两个方面。一个是用户的直接反馈，一个是用户的使用方式。

用户阅读手册后，可以与用户沟通使用看法，看哪里不简单理解，哪里查看起来不便利，以此来调整手册的结构及表达方式。另外可以观看用户如何查阅手册，看针对几个特别场景（初次使用时的整体阅读及查询某个细节时查找解决方法）的使用状况，来发掘文档可能存在的优化点。这个相当于既要通过访谈的方式沟通用户对产品的看法，又要通过观看的方式找出用户在使用中遇到的问题。

05几点阅历

1.版本管理

首先有一个操作手册基线版本，在第一次写完后记录当前操作手册对应的系统版本。然后依据系统的升级状况，会逐步往操作手册中增加内容，此时需记录每次都增加了哪些内容，对应了系统的哪些版本。

由于系统更新后不肯定每次都有时间马上更新操作手册，而且当操作手册的规模大到肯定程度，再去核对手册跟系统的区分，将耗费大量的时间且操作起来极其繁琐。

可在手册中增加一个小节对此进行特地记录，写明手册版本、更改人、更改时间、更改内容。如有必要可增加审核人及审核时间。

2.明确/申明概念

将系统中特出名词进行解释。这些内容在系统设计之初应当有相关描述，可依据需要进行摘录。明确了概念才能顺畅沟通，而且许多问题本身也是不知道概念才产生的。

3.格式统一

主要是为了便利阅读。查看起来文档美观，查找相关内容也比较便利。写之前先定好规范，审核文档时作为审核项。修改文档前先看一下其它章节，不至于每次增加内容有用新的格式。文档格式主要有下面两种。

文档格式。文档标题、正文、表头等内容格式统一。表达格式。比如描述按钮时统一用【】，描述系统提示时统一用“”等等，这个在手册内统一即可。4.其它形式的操作手册

页面内的提示文字对于简单产生疑问的地方，用简短的提示文字解释。可以直接写在页面上，也可以增加小图标，点击后查看提示；依据提示的重要程度进行设计。文字肯定要简短易懂。常见问题解答这个模块可在操作手册中增加，也可以在系统中供应相关页面。系统中供应页面的优势在于随时可查看，而且