你的用户真的需要操作手册
最近在整理之前留下的债，刚好写到了操作手册，就有一些写操作手册的感悟和心得方法，与大家分享一下。以下内容仅针对于B端产品或者BtoC产品中的B端侧，C端产品最理想的状态是不需要操作手册，简单易懂即可。
一、传统的操作手册
传统的操作手册通常由引言、编写目的、背景意义、产品概述、产品功能描述等等冗长的内容组成，而这些真的是用户想要的么？或者这些真的是用户所关心的么？
下面举个例子，操作手册如下，大致分为三部分：前言、系统概述、系统操作。
无论写什么文档，文档完整性一定要保持文档封面，文档目录，前言。虽然这些是次要的东西，可写可不写，我个人习惯无论是对外输出什么文档，我都要将这些写上。
- 前言一般包括文档目的、文档读者、术语定义；
- 系统概述一般包括系统架构图、功能清单、业务流程图、岗位职责。这些和需求说明书的写法一样，这里主要说下系统操作怎么写。系统操作是系统的功能操作，从登录到退出都需要告诉用户在哪去操作、怎么去使用；
- 在写系统操作的时候，还需要注意，以用户的角度思考，写的时候需要告诉用户什么功能是谁用的。每个用户只关心自己用的功能是什么，所以这点需要特别说明。
系统操作一般包括以下部分：
- 业务场景
- 操作角色
- 操作路径
- 使用注意
- 操作说明
- 业务场景：描写用户在什么场景下使用这个功能。
- 操作角色：谁来用这个功能。
- 操作路径：在哪去用这个功能
- 使用注意：用户需要注意什么
- 操作说明：按页面上每个功能按钮进行说明。
没错，很多内容其实你是不需要的，你想知道的只有这个东西在什么场景下怎么用就行，其中的背景、意义、编写目的，只不过是我们在追求写作者自己的心里安慰罢了。洋洋洒洒几百页，最后用户体验却是极差的。
在这个快节奏的时代，人们往往想要第一时间找到自己想要的信息，而不是在众多冗余的信息中如大海捞针一般去慢慢寻找。因此，操作手册应该根据用户的使用场景和可能遇到的困难进行解答。
配以图片或者视频的形式来描述更为妥当，通过流程的方式来确定用户究竟想要什么样的操作手册，显得更为明智一些。那么，下面笔者将抛析操作手册的写法。
二、操作手册的定义
何为操作手册，官方的定义如下：操作手册是详细描述软件的功能、性能和用户界面，使用户了解到如何使用该软件的说明书。
看起来很简单，就是只要说明软件的功能，并让你的用户知道如何使用即可。描述软件的功能的粒度可大可小，大到模块级别，小到按钮级别，那怎样的一种粒度是用户最能接受的呢？
三、操作手册的原则
一本好的操作手册要有哪些原则？
- 好找：方便用户找到所需信息，预见用户可能遇到的问题和解决方法；
- 通俗易懂：内容清晰，语言和设计简单明了是关键；
- 开门见山：让用户知道该如何操作，并知道下一步该做什么。
最好采用总分总的形式，即开头给用户一个总体的手册流程概览，可以是业务的整体流程图，也可以是下面操作的每一小节的内容。
例如：
四、操作手册的目的
操作手册编写的目的，可以从两个角度出发：
- 提高用户使用平台的操作性，让用户成为你产品的主人，服务于你的用户才能产生价值；
- 减少运营人员解答不必要的问题的时间。例如，所有人都问相同的问题，那么他就应该出现在操作手册上，或者帮助模块中。
五、操作手册的粒度
这个业内没有标准的答案，只要用户读懂即可（这看起来是一句合理的废话）。其实，笔者认为写操作手册应该按照用户场景来写，一个闭环的场景即可。
那怎样是一个闭环的场景呢？
举个例子：笔者所在的体育产品领域，分为办赛资料、创建比赛、裁判分配、线上报名、裁判打分、颁奖管理等等。每一块就是一个完整的流程。用户做完一个完整的动作，并且得到一个结果。
六、操作手册的层级目录
按照上述的粒度，我们会给出一个一级目录，在一级目录下，我们又该如何确认二级、三级目录呢？
我们继续拿创建比赛为例，创建比赛的过程中每一个页面都需要完成它应该完成的内容，并对应业务的流转，我们只需要告诉用户如何操作即可，如填写比赛名称、比赛时间等等，不需要告诉用户比赛时间的规则为开始时间小于等于结束时间。
因为，我们的用户并不关心。且BtoC的产品还在用户了解一定的行业背景下，所以，大家会约定俗成一些事情。
七、操作手册的编写内容
用户都是很懒的，他们不会去看枯燥的文字，就像之前很火的数据大屏一样以及一直很火的短视频业务，用户对于知识的输入喜爱顺序为 视频 > 图片 > 文字 。因此，我们需要用图文混排的形式来告诉用户如何操作我们的系统。
当然，操作手册不单单是解决用户操作流程上面的问题，还需要解决用户常见的问题。例如：在赛事平台中，用户可能会好奇能举办那些比赛、参赛的人数限制、解决方案等等。
足够量的帮助解决和规范的操作手册能够提升用户的黏性并且提出更有价值的产品需求。
八、操作手册的术语统一
当你使用一款软件的时候，你希望软件内的名词都有统一的说法，我们继续拿赛事平台举例，例如 办一场比赛的时候，有比赛开始时间、比赛结束时间、报名开始时间、报名结束时间、比赛创建时间、比赛修改时间。
当用户想要统一一个维度去查询的时候，例如 查询一月份的比赛数目，那好了。我们使用比赛开始时间？比赛结束时间？这两个维度得到的数据是大不相同的。更不能给出一个莫能两可的“办赛时间”。
因此，统一平台操作手册的术语十分重要。纸上学来终觉浅，绝知此事要躬行。
赛事平台的操作手册：https://shimo.im/docs/vXWR9X3TckkvvRcw/
本文作者 @当下不杂
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
