DevOps文章之 操作手册用户使用说明书

时间:2024-02-16 17:57:33

前言

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

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

  1. 明确需求的目的
  2. 明确目标用户
  3. 明确使用场景
  4. 形成解决方案
  5. 最小代价验证方案
  6. 调整并完善方案(编写文档到这一步就可以结束了)

明确编写目的、目标用户、使用场景

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

目标用户:客服人员、系统用户(注意可能会有多个角色,比如管理员、操作员、被管理人员等)。

使用场景:客服人员多是软件的开发方的人员,当系统大到一定程度后,一些详细的规则单靠记忆很难覆盖,在遗忘的时候可以拿操作手册作为参考。一个是软件的实际使用人员,在遇到问题又找不到客服时,可通过操作手册进行快速查找。综合来看主要时两个场景:一、从头开始认识一个功能。二、查找某个功能的某一步的详细规则。

形成解决方案

针对编写目的、用户、场景,总结出操作手册必备的几个要素。一、明确的目录结构,既能让用户对系统有个整体全面的认识,又能方便用户查找;二、功能概述,根据目录的划分,对功能进行简要介绍,说明这个功能是干什么的;三、详细操作步骤,介绍每一步该怎么做,有什么注意事项。

目录结构

一般操作手册会根据不同的人有不同的版本,但是如果为每个人单独写一份,这个工作量就太大了。最好在写的时候就按使用人来划分,这样就可以只写管理员(拥有系统全部权限)版本,然后将管理员版本中的部分摘出来即可形成多个版本。比如一个系统有移动端和PC端,如果PC端作为管理、配置功能,给操作员用。PC端是展示,给管理者用,那么目录可以分移动端和PC端,然后再分更细的功能;如果同一个用户既可以在移动端完成该功能,又可以在PC端完成,那么目录可以按照功能进行划分。按照这样的逻辑划分就可以达到上述目的。

如果系统目录划分比较清晰,详细的功能可以按照目录来划分。这里to B系统的产品经理应该很熟悉。如果不清晰,建议先优化系统目录。或者系统功能本身很琐碎,操作手册可以按照事项来划分。比如某项信息要在前端展示,需要经历信息的上传、审核、发布等流程。那么既可以分开介绍某各流程具体怎么操作,也可以将信息怎么发布作为一个模块来整体介绍,或者写一个整体的流程框架,具体某步骤参照某章节。具体写法需根据系统的实际情况来判断。

功能概述

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

可以如果流程较为复杂,可以用流程图等来辅助说明。

详细操作步骤

每一步具体怎么操作,点击哪个按钮,填写哪些字段。各个按钮点击有什么效果,字段填写有什么意义会影响到哪里。这些内容该怎么写,主要是根据页面和功能的种类。比如列表页,如果都是些根据名称能知道含义的字段,那么就不需要介绍。如果有些容易混淆的词,比如“更新时间”是只有用户在当前页面对数据修改进行记录,还是在其它页面做修改,导致该页面的数据产生变化时也做记录。这时候需要说明,否则用户在使用过程中会进行大量的提问。如果系统有专有名词,也需要进行描述。(最好单独用一小节对其进行统一介绍)

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

验证并完善方案

小范围发布

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

根据反馈进行调整

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

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

几点经验

版本管理

首先有一个操作手册基线版本,在第一次写完后记录当前操作手册对应的系统版本。然后根据系统的升级情况,会逐步往操作手册中增加内容,此时需记录每次都增加了哪些内容,对应了系统的哪些版本。因为系统更新后不一定每次都有时间立即更新操作手册,而且当操作手册的规模大到一定程度,再去核对手册跟系统的区别,将耗费大量的时间且操作起来极其繁琐。

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

明确/申明概念

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

格式统一

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

  1. 文档格式。文档标题、正文、表头等内容格式统一。
  2. 表达格式。比如描述按钮时统一用【】,描述系统提示时统一用“”等等,这个在手册内统一即可。

其它形式的操作手册

  1. 页面内的提示文字
    对于容易产生疑问的地方,用简短的提示文字解释。可以直接写在页面上,也可以增加小图标,点击后查看提示;根据提示的重要程度进行设计。文字一定要简短易懂。
  2. 常见问题解答
    这个模块可在操作手册中增加,也可以在系统中提供相关页面。系统中提供页面的优势在于随时可查看,而且可以根据用户当前的页面,将与页面相关的问题排在前面。
  3. 视频
    通过录制视频进行讲解,相对于文字更容易理解,可作为操作手册的补充。
  4. 简化系统的操作逻辑。

最好的操作手册是不用操作手册用户上手即会用。操作手册是系统的一部分,那么手册的理想状态是没有手册。通过优化系统、将提示融入系统等等方式可向这个理想艰难前行。