时间: 2021-07-30 09:22:48 人气: 6 评论: 0
编辑导语：操作手册是详细描述软件的功能、性能和用户界面，使用户了解到如何使用该软件的说明书。很多时候，当我们对产品的某个功能感到困惑时，往往需要一份操作手册来帮助我们解答疑惑。在本篇文章中，作者就对操作手册的目的、原则、层级目录等进行了分析。
最近在整理之前留下的债，刚好写到了操作手册，就有一些写操作手册的感悟和心得方法，与大家分享一下。以下内容仅针对于B端产品或者BtoC产品中的B端侧，C端产品最理想的状态是不需要操作手册，简单易懂即可。
传统的操作手册通常由引言、编写目的、背景意义、产品概述、产品功能描述等等冗长的内容组成，而这些真的是用户想要的么？或者这些真的是用户所关心的么？
下面举个例子，操作手册如下，大致分为三部分：前言、系统概述、系统操作。
无论写什么文档，文档完整性一定要保持文档封面，文档目录，前言。虽然这些是次要的东西，可写可不写，我个人习惯无论是对外输出什么文档，我都要将这些写上。
系统操作一般包括以下部分：
没错，很多内容其实你是不需要的，你想知道的只有这个东西在什么场景下怎么用就行，其中的背景、意义、编写目的，只不过是我们在追求写作者自己的心里安慰罢了。洋洋洒洒几百页，最后用户体验却是极差的。
在这个快节奏的时代，人们往往想要第一时间找到自己想要的信息，而不是在众多冗余的信息中如大海捞针一般去慢慢寻找。因此，操作手册应该根据用户的使用场景和可能遇到的困难进行解答。
配以图**或者视频的形式来描述更为妥当，通过流程的方式来确定用户究竟想要什么样的操作手册，显得更为明智一些。那么，下面笔者将抛析操作手册的写法。
何为操作手册，官方的定义如下：操作手册是详细描述软件的功能、性能和用户界面，使用户了解到如何使用该软件的说明书。
看起来很简单，就是只要说明软件的功能，并让你的用户知道如何使用即可。描述软件的功能的粒度可大可小，大到模块级别，小到按钮级别，那怎样的一种粒度是用户最能接受的呢？
一本好的操作手册要有哪些原则？
最好采用总分总的形式，即开头给用户一个总体的手册流程概览，可以是业务的整体流程图，也可以是下面操作的每一小节的内容。
例如：
操作手册编写的目的，可以从两个角度出发：
这个业内没有标准的答案，只要用户读懂即可（这看起来是一句合理的废话）。其实，笔者认为写操作手册应该按照用户场景来写，一个闭环的场景即可。
那怎样是一个闭环的场景呢？
举个例子：笔者所在的体育产品领域，分为办赛资料、创建比赛、裁判分配、线上报名、裁判打分、颁奖管理等等。每一块就是一个完整的流程。用户做完一个完整的动作，并且得到一个结果。
按照上述的粒度，我们**给出一个一级目录，在一级目录下，我们又该如何确认二级、三级目录呢？
我们继续拿创建比赛为例，创建比赛的过程中每一个页面都需要完成它应该完成的内容，并对应业务的流转，我们只需要告诉用户如何操作即可，如填写比赛名称、比赛时间等等，不需要告诉用户比赛时间的规则为开始时间小于等于结束时间。
因为，我们的用户并不关心。且BtoC的产品还在用户了解一定的行业背景下，所以，大家**约定俗成一些事情。
用户都是很懒的，他们不**去看枯燥的文字，就像之前很火的数据大屏一样以及一直很火的短视频业务，用户对于知识的输入喜爱顺序为 视频 > 图** > 文字 。因此，我们需要用图文混排的形式来告诉用户如何操作我们的系统。
当然，操作手册不单单是解决用户操作流程上面的问题，还需要解决用户常见的问题。例如：在赛事平台中，用户可能**好奇能举办那些比赛、参赛的人数限制、解决方案等等。
足够量的帮助解决和规范的操作手册能够提升用户的黏性并且提出更有价值的产品需求。
当你使用一款软件的时候，你希望软件内的名词都有统一的说法，我们继续拿赛事平台举例，例如 办一场比赛的时候，有比赛开始时间、比赛结束时间、报名开始时间、报名结束时间、比赛创建时间、比赛修改时间。
当用户想要统一一个维度去查询的时候，例如 查询一月份的比赛数目，那好了。我们使用比赛开始时间？比赛结束时间？这两个维度得到的数据是大不相同的。更不能给出一个莫能两可的“办赛时间”。
因此，统一平台操作手册的术语十分重要。纸上学来终觉浅，绝知此事要躬行。
赛事平台的操作手册：https://shimo.im/docs/vXWR9X3TckkvvRcw/
本文由 @当下不杂 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
