使用手册该怎么写？

许多产品团队往往忽视了使用手册的重要性，或者在编写时缺乏系统性和针对性。本文将深入探讨使用手册的核心价值、主要内容、编写方法以及管理维度，帮助产品团队打造一份高质量的使用手册，从而更好地满足用户需求，提升产品的市场竞争力。

一、什么是使用手册？目的又是什么？

使用手册，又称用户使用说明书，是产品和用户之间桥梁，核心目的是指导用户使用产品；

优秀的产品是不需要使用手册的，让用户的使用能够沉浸式使用产品，才是最佳状态；

对于B端产品，尤其是交付型产品，为客户提供手册是必备的环节，因为B端产品业务结构复杂，通常附带业务全流程的表达以及内部管理规范体系，针对业务数据的流转和特性业务字段需要有统一的执行标准和操作规范，故而在实际的B端产品落地过程中，需要提供必要的产品培训；

产品培训只能解决一时的问题，对于B端用户日常的使用过程中，难免会有遗忘或者不知如何变动表达，甚至在使用过程中遇到问题时，也不知道如何进行解决，故而使用手册更多执行的作用有两种：操作指引、运维指南；

故而使用手册主要的目的如下：

为用户提供系统操作的全面指南为用户提供潜在问题的解决方案为用户提供产品使用的最佳实践二、使用手册有什么价值？

许多B端产品的使用手册，是功能的集合或者功能模块的描述，也是按照一定的套路和格式模版所写，但是使用手册的制作过程一般是产品做完以后，这就导致使用手册的价值瞬间沦为产品的附属物，也就丧失了其独特的价值；

关于使用手册的价值分析，我们用常用的5why分析法：

为什么要有使用手册？ — 用户需要手册，指导他们使用产品为什么需要指导用户使用产品？ — 产品有一定的复杂度产品为什么会复杂？ — 业务复杂业务虽然复杂，但用户最懂业务，为什么不会使用产品？ — 产品功能分散，用户不知道入口，且不知道如何和业务做映射，即便是知道了怎么使用，但是也不知道怎么才算高效产品是业务的表达，应该最贴近业务，且能够解决用户日常工作的效率问题，为什么对用户会有阻塞？（包括入口、业务映射、最佳实践） — 业务千变万化，不能按照每一个业务需求来进行产品表达，需要进行抽象，依托抽象出来的模块、功能等进行组装，来满足用户的需要；且各家业务不同，业务表达上也不尽相同，需要用户理解产品实现和业务之间的映射；为什么不能提供统一的业务需求解决方案？ — 那就需要制定行业标准且推进用户标准化使用困难比较大难度主要是什么原因造成的？ — 首先行业不同，即便是同一个行业，各个客户执行的业务流程和标准都不一样，所以就要在基础产品版本上，给客户做项目化交付项目化交付，就是按照客户要求定制的，有什么功能客户最清楚，提供手册做什么用？ — 只有提出需求的人了解功能，其他客户员工还不知道怎么操作，且不同权限，可操作的范围也不同，会存在断层，比如A不知道B做了什么，后续环节的C应该怎么做？等等是不是只有按照角色写清楚功能操作即可？ — 不光是功能操作，常见的问题也要写清楚

从以上的问题，我们可以清楚的知道，使用手册本质是用户需求的业务化表达，也就是我们常说的用户故事。

从用户的角度来看，包括业务流程、业务操作等，从生成者的角度来看，包括功能清单、产品规格等；

对产品生产者来讲，可以快速的将产品交付给用户，快速落地；实际操作过程中，如果针对不同的行业和用户，有对应的使用手册，可以通过使用手册来管理项目的功能清单、规格清单，那么在用户的后期需求迭代过程中，能够通过清单快速的完成功能迭代和项目交付，也就可以快速的提高交付效率；

对产品使用者来讲，通过使用手册，可以快速的知道某个业务的流程及操作步骤，指导用户进行功能隔离，规避人员权限失控，且通过流程化执行，让业务参与者清楚的知道上下游的协作，可以有效的提升内部的运营效率；

故而，使用手册的主要价值：

1）对生产者：提高交付效率、降低交付成本、降低内部管理和维护成本

2）对使用者：降低培训成本、减少运营事故、提高运营效率

三、使用手册有哪些形式？

早期互联网不是很发达的时候，使用手册更多的是以图文/书籍方式，同产品一起交付的，可阅读性比较差，这种形式的使用手册核心的表达在于索引目录的编写和关键功能的提取，期望用户能够依据自身的问题，快速通过目录查找 / 检索关键功能，快速定位；

随着4G的普及，数据传播效率的极大提升，视频方式逐渐普及，用户不必再去阅读图文，可以极其快速学习；但视频表达也有局限性，视频本质是一段有逻辑的脚本的可视化表达，所以视频通常是一整段的功能/操作的使用，所以特别冗长，对于特定问题的解决就显的乏力；这种情况下，一般B端产品会同时提供文本型手册，方便用户进行查阅；

在短视频逐渐流行起来后，使用手册又可以增加一种表现形式，短视频的特点就是“短”，所以特别适合碎片化的功能使用介绍和特定场景的用户操作指导；

2024年我们有幸进入了AI时代，AI使用时可以不必在固定的框架内，让用户去寻找答案，而是根据用户的描述，由算力综合计算，给予用户最终的分析结果，对用户更加友好，但目前还没有见过一家B端产品，给客户提供AI解决方案，主要原因还是目前AI成本太高；

不论采用什么形式，其实底层的内容仍是早期的图文，只是现在有了更高效的表达方式而已，所以对于B端产品仍然还是要有砌砖的心态；

四、使用手册的主要内容？

一个完整的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 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。