企业官网建设流程全解析

很多团队都有过这种经历：产品功能做得挺完整，一上线，用户不看手册，客服群里全是“这个按钮在哪”“为什么我保存失败”。管理员把手册文档扔给用户，用户翻两页就关掉了，转过头继续问客服。问题出在哪？大多数时候不是用户懒，是手册本身写得没法用。

我写了十来年用户手册和技术文档，从几十页的软件操作手册到上千页的硬件维护手册都碰过。踩过不少坑之后，总结出一套还算靠谱的编写流程。这篇内容就是把这套流程掰开揉碎讲清楚：动手之前要想明白什么、章节怎么搭、每一步怎么写、截图怎么配、发布之后怎么维护。适合产品经理、技术工程师、运营同学、创业团队里被临时抓壮丁当文档负责人的朋友参考。跟着这套方法走一遍，至少能保证你写出来的手册用户愿意看、找得到、照着做能走通。

1. 动手动笔之前，先把这三件事想清楚

写手册最大的忌讳就是一上来就打开Word开始码字。你连读者是谁、用户拿手册来干嘛都没搞清楚，写出来的东西一定是功能说明书式的陈列，而不是能解决问题的操作指南。我一般会先花半天到一天时间，把下面三件事彻底想透，再动笔。这三件事，直接决定手册的目录结构、语言风格和内容取舍。

1.1 先搞清楚读者是谁，再谈写作风格

读者画像看起来像是市场部的事，但写手册的人必须自己先做一遍。不同读者对同一本手册的需求差异非常大，你不把读者搞清楚，语言组织就容易跑偏。

举个例子，我服务过一个给企业做考勤机的客户。他们的产品有两个使用群体：一个是企业里负责排班考勤的HR，一个是每天上班打卡的普通员工。HR需要配置班次、处理异常考勤、导出报表，普通员工只需要知道怎么打卡、怎么看自己的考勤记录。一开始客户给的资料是把所有功能平铺写进一本手册，结果HR嫌找不到深度功能，员工嫌手册太厚看不懂。

后来我们做了两本手册：一本《管理员配置指南》，一本《员工快速上手》。两本手册对同一个打卡功能的描述方式完全不同——员工版写“把手指放在感应区，听到‘滴’声后拿开”，管理员版写“在【设备管理】中选择设备，进入【考勤规则】配置打卡方式为指纹识别”。

这就是读者画像带来的差异。动手之前，拿出一张纸回答几个问题：主要使用者是终端用户、管理员、还是维修工程师？他们的计算机操作水平大概什么程度？他们是在什么状态下打开手册——是安装时遇到问题，还是日常使用中需要某个功能？这几个问题的答案，决定了你的手册是全彩图解为主、还是文字步骤为主，决定你用词是浅白直给还是允许专业术语。

1.2 写使用场景，优秀手册的隐藏骨架

很多手册写不好，是因为作者只列功能清单，不写使用场景。功能清单是产品视角，用户根本不会按照“功能A、功能B、功能C”的顺序去用产品，他们只会在“遇到一个问题”的时候，来找“对应的解决办法”。

我习惯在动笔前先列一个使用场景清单，一页纸就够了。比如我最近整理一个项目管理工具的手册，列出了这么几个核心场景：新成员加入后如何快速创建自己的第一个项目、项目进行中如何调整任务负责人和截止时间、项目结束后如何归档并导出报告。每个场景对应一个或几个功能模块，这样写的时候，我就知道哪个功能要详细写，哪个功能可以一句话带过。

场景清单还有一个作用，就是和功能清单对照去查漏。把产品所有功能列出来，再和场景清单比一下，你会发现有一些功能没有任何场景覆盖——这些功能往往使用频率极低，或者根本就是给特殊人群用的。这类功能不要在正文里给太多篇幅，放进附录或者单独章节即可，避免干扰主线阅读。

1.3 任务清单：把功能列表翻译成用户要做的事

场景想清楚之后，还需要把一个场景拆成具体的任务步骤。任务和功能的区别在于：功能是产品能做什么，任务是用户要做什么。

还是拿项目管理工具举例。“分配任务”这个功能，从产品菜单来看可能分散在多个模块里：创建任务时可以直接指定负责人、任务详情页可以修改负责人、列表视图里可以拖拽变更负责人。如果按功能写，用户要看三个地方才能搞明白；如果按任务写，就只有一个动作——“把任务分配给张三”，我告诉你用哪种方式最快捷，其他方式在“另见”里提一句就行了。

任务清单还有一个隐藏价值：它会逼着你把产品流程理顺。很多时候，任务拆到一半你就发现产品设计本身有断点——某个操作根本走不通，或者某个功能按钮藏在三级菜单里。这种时候，手册作者往往是第一个发现问题的人，解决这个问题的价值比写文档本身大得多。

2. 用户手册的整体架构怎么搭

架构是手册的骨架。骨架正了，后面的内容填充就顺。我常用的结构分七块：封面与版本信息、目录、安全警告与重要说明、快速上手、操作指南、常见问题与故障排查、附录。听起来很简单，但每个部分的先后顺序和详略安排都有讲究。

2.1 操作指南按任务拆解，比按菜单拆解好用

操作指南是手册的核心部分，这一部分怎么组织最影响用户体验。最常见的错误写法是按产品菜单顺序来：文件菜单是什么、编辑菜单是什么、视图菜单是什么，依次介绍下去。这种写法写出来的是功能索引，不是操作指南。用户脑子里没有你的菜单结构，他只有“我想把这张图片插到文档里”这种具体任务。

更好的组织方式是按任务模块划分章节。比如一份后台管理系统的手册，操作指南可以分成：账号与权限管理、内容发布与审核、数据报表查看、系统参数配置。每个模块下再拆具体任务。按任务拆解对作者也友好，因为每个任务都有明确的边界，写到什么程度、需要哪些截图，一目了然。

章节顺序也有讲究。把最高频、最核心的任务放在最前面。比如电商后台，商品上架就是最高频任务，应该放在操作指南的第一个模块；而设置快递模板这种低频操作，放在后面甚至附录都行。千万别按产品开发顺序写，那是最省作者事、最坑用户的事。

2.2 安全警告与免责声明：放最前面最管用

涉及安全的手册，比如操作工业设备、电气设备，或者牵扯到数据删除、权限控制的软件，安全警告一定要放在目录之后、正文之前，用显著的颜色或边框标注。别觉得这是形式主义。真实场景里，用户往往是出了事故才会翻手册的安全页，所以这部分一定要独立成页，内容要具体，别写“请安全操作设备”这种正确的废话，要写“通电状态下严禁打开设备后盖”“删除项目数据前请确认已导出备份”这种能阻止事故的话。

免责声明同样要前置。尤其是软件产品，功能界面经常调整，文档里必须写明“本手册仅供参考，实际界面可能因版本不同略有差异”。这不仅是法务要求，更是给文档维护留退路——产品改版后手册跟不上，至少不会被当作严重质量问题投诉。

2.3 常见问题这一部分，要放在故障排查之前

常见问题和故障排查看起来很像，实际操作中我会把两者分开。常见问题放操作指南之后，主要收录使用中频率最高的困惑：能不能多人同时操作、数据保存在哪里、试用版和正式版有什么区别。这些问题往往一两句话就能答完，但用户的搜索命中率很高。

故障排查单独成章，放常见问题后面，专门解决报错提示、操作失败、异常现象这类问题。用表格整理是最好的形式，表格一般四列：错误现象、可能原因、解决方法、注意事项。用户照着现象去查表，找到对应处理方式，照做即可。这种格式对使用价值很高，后面我会单独讲这个部分怎么写。

3. 页面规范与交互约定：一开始就要定好的文档规则

写手册的时候，如果每个人按照自己的习惯来排版，最后合稿时一定是灾难现场。我在项目启动时会先定一套页面规范，这不复杂，但能省掉后期大量的返工时间。规范越早定，写出来的内容越统一。

3.1 编号体系：章节、图表、步骤统一编号

编号体系是手册里最容易忽视、也最容易变乱的地方。章节编号大家都会写，但图表编号很多人会漏。一本手册一旦超过20页，没有图表编号会非常痛苦——正文里写“如下图所示，点击右上角按钮”，但图多的时候读者根本不知道是哪个图，也没法在目录里跳转。

我的习惯是完整建立三级编号：章号-图表序号-步骤号。第二章的第三张图编号就是“图2-3”，如果图表多，可以用“图2-3-1”表示第二章第三节的第一个图。表格类似，叫“表2-1”。步骤编号用阿拉伯数字从1开始，每一个主步骤单独一个编号，中间尽量不要出现“2.1、2.2”这样的小步骤，宁可拆成多一个主步骤，这样在电话支持的时候，工程师说“你按照第4步，检查一下那个选项”，用户能在文档里快速定位。

3.2 警示信息的四级用法

操作手册里的警示词，专业文档标准里是有严格分级的，但在内部手册里，我一般简化成四级，够用且不累赘：

• 危险：会导致人身伤害或严重设备损坏。比如：带电维修可能造成触电。
• 警告：可能导致数据丢失或功能不可用。比如：执行此操作将清空所有用户数据。
• 注意：可能导致操作结果异常或效率下降。比如：不同型号的耗材不通用。
• 提示：补充信息，帮助用户更好地操作。比如：查看本操作之前，请先完成系统初始化。

这四级警示词，前三级排版上要非常醒目，提示级就用普通格式加灰色底框即可。千万别整本手册都刷满红色警告——警示词一旦泛滥，真正出危险时用户已经麻木了。

3.3 统一术语和界面控件名，杜绝“一词多义”

术语不统一是用户手册的大敌。同一个按钮，有人写“确认”、有人写“确定”、有人写“OK”；同一个概念，有人写“订单”、有人写“单据”、有人写“工单”。这会导致全文检索时用户找不到目标内容。

开始写作之前，我会从产品界面和需求文档里把核心术语全部拉出来，建一个术语表：标准名称、别名、说明、在文档中统一使用的表述。比如，产品界面上按钮就叫“提交”，手册里就不能写成“递交”；短名称“后台”和全称“管理后台”允许同时出现，但要统一使用方式。这个术语表还要同步给开发和测试团队——界面文案本身也别乱改，一会儿叫“登录”、一会儿叫“登陆”，用户不被搞晕才怪。

4. 用操作化语言替代功能描述

手册内容的文字功夫，决定了用户是“读得下去”还是“看不进去”。最常见的毛病是写手册的人用了太多形容词、功能描述和抽象总结。要改变这个局面，核心是学会操作化表达——把每一个环节都写成用户能执行的行动。

4.1 把形容词换成动作

先看一组对比：

功能描述式：系统后台提供强大的数据统计功能，支持多维度数据报表展示。 操作指导式：登录后台后，在左侧菜单选择【数据中心】，可以查看今日订单量、销售额和转化率。如需查看历史数据，请点击右上角【日期筛选】按钮，选择起止日期。

第一种写法看起来高大上，但用户读完毫无收获，既不知道去哪里看，也不知道能看什么。第二种写法每一个分句都是可执行的——登录、选择、点击、筛选，用户跟着做就行。写手册时养成习惯，每写一句话，停下来问自己：用户看了这句话之后知道下一步动作吗？不知道就改。

4.2 每一步式写作与判定结果

操作步骤不仅要写“做什么”，还要写“做完后看到什么”。这叫结果判定。如果没有结果判定，用户执行完一步之后不确定自己做没做对，就会犹豫、卡壳。比如：

• 错误写法：在弹窗中设置密码，点击确定。
• 正确写法：在弹窗中设置登录密码，至少包含8位字符，点击【确定】。系统提示“密码设置成功”，进入登录页。

正确的写法多了一句话，但这个反馈让用户知道自己走对了。所有关键步骤之后都要有结果判定，哪怕只是一句“页面自动跳转到步骤2”。

另外，每个操作步骤尽量只包含一个动作。把“点击A、勾选B、输入C、点击确定”揉成一个步骤，用户很容易漏掉中间的某个环节。宁可步骤多三五个，也不要把多个动作压在一起。我自己写的时候有一个标准：用户不需要回看前一步，那他就不需要思考，直接照做。

4.3 给一个完整的操作段落做示范

拿一个常见的场景举例：修改账号密码。

正确示范：

修改账号密码

1. 在右上角点击头像，弹出下拉菜单。
2. 点击【账号设置】。
3. 在【安全设置】区域，点击【修改密码】。
4. 输入原密码、新密码和确认新密码。新密码需同时包含数字和字母，长度不少于8位。
5. 点击【保存】。系统提示“密码修改成功”，下次登录请使用新密码。

这个写法的特点：每步一个动作，有操作位置（右上角头像）、有对象名称（账号设置/安全设置）、有输入规则（8位以上字母数字组合）、有结果反馈（系统提示密码修改成功）。

再对比一下很多人会写出来的版本：

用户可以在账号设置中修改个人密码，修改时需输入原密码和新密码，新密码需要满足强度要求，修改后下次登录时生效。

这个版本信息没错，但用户要自己琢磨在哪里设置、怎么算强度达标、到底改没改成。信息不缺失，体验完全不一样。

5. 截图、配图和排版的实操规范

文字写得再好，没有配图或者配图一塌糊涂，手册的整体质量会掉一个档次。我自己看用户手册时，如果一页纸超过300字没有任何图片，我大概率先把它判定为“辞海”而不是手册。截图和排版占手册观感权重的一半以上，这块值得专门花时间打磨。

5.1 截图处理三原则：区域、状态、修饰

第一，截关键区域，不要截整个屏幕。很多新手喜欢截全屏，把任务栏、桌面背景、无关菜单全都截进去，读者根本看不清重点。正确做法是只截操作区域，可以稍微留一点上下文，但主体必须清晰。比如要说明“点击右上角的保存按钮”，只截工具栏那一块足够，别把整个编辑器界面都塞进去。

第二，截关键状态，不要截界面刚加载完的样子。操作类截图最有价值的是点击之后、输入之后、完成之后的界面。比如填表单，你要展示的是填写好的范例状态，而不是空白表单。很多手册作者偷懒，只截一个初始界面，用户照着操作后无法确认自己是否操作正确。

第三，给截图做标记。用红色或蓝色方框圈出要点击的按钮，用编号圆圈标注操作顺序，用箭头指示路径。但标记要克制，一张图上最多两三个标记，多了反而乱。所有标记风格要保持一致，别这张图用红色方框、那张图用绿色箭头，这会让用户感到混乱。

5.2 图文排版的基本节奏

排版的核心原则是“图文对应”，文字讲到哪一步，图就紧跟在哪一步下面，别放在这一页末尾，更别放到下一页。用户阅读时视线是“文字——看图——再回到文字”这样一个来回跳转的过程，图放远了，阅读成本立刻翻倍。

另一个要点是把步骤编号和图片编号对应起来。步骤3对应图3，这样用户看图时不用猜是哪一步。Word或在线文档里，可以使用题注功能自动编号，不要手打“图1、图2”这种编号，后期插入删除图片时全乱套。

字体的选择不需要发挥创意，正文用无衬线字体（黑体、微软雅黑、思源黑体这类），字号小四或五号，行距至少1.5倍。别用花体、艺术字，更别用一堆配色来显示文档“美观”。用户手册追求的是信息传递效率，不是视觉效果。

6. 发布之后的维护和反馈闭环

手册写完发给用户，不等于工作结束，恰恰是真正的开始。手册是指南标题，写作完成后，还要保证它跟着产品一起进化。很多手册的寿命终结不是因为初始写得差，而是因为没人维护，产品改了三个版本，手册还停在一代。

6.1 让用户找得到、搜得到

再好的手册，用户找不到就等于零。发布手册时要考虑用户的使用场景：如果是软件产品，手册的PDF版要能通过帮助菜单直接打开，网页版要有站内搜索；如果是硬件产品，说明书要随产品箱附带，同时提供二维码，扫码即可查看在线更新版。

在线版本尤其要重视搜索引擎的命中率。核心问题词、功能名、操作名都要出现在正文和标题里，这样用户用百度或谷歌搜“怎么修改密码”，才有可能找到你的手册页面。我见过很多优质的手册内容被埋没，就是因为文档藏在后台深处，搜索引擎根本收录不到。

6.2 建立文档更新节奏

和产品研发同步更新文档，听起来是常识，做起来却经常被遗忘。最好的做法是：把文档更新写进产品发布流程里，作为上线前的必备步骤，而不是可选项。产品经理在提测需求时同时提交文档变更说明；产品上线前，文档必须改版完成，否则不予发版。这个机制一开始执行起来会有阻力，但跑顺之后团队会发现，文档跟得上版本，客服的咨询量会肉眼可见地下降。

文档维护频率上，不用天天更新，但至少要跟着大的版本迭代更新。每次更新后记录版本号和改动内容，放到手册前面的版本记录里。这样用户拿到手册时，能快速判断这是不是符合自己手上产品版本的说明。

7. 常见问题排查速查表

结合这些年写手册过程中收集到的反馈，整理一个高频问题速查表，遇到同样情况可以直接对照解决。

这个表我自己一直在用，每次写新文档之前都会从头扫一遍，避免踩进上面的坑。

最后分享一个我自己的习惯：每份手册写完之后，找一位完全不了解这个产品的同事或朋友，让他只看着手册，从零开始操作一遍。你做在旁边不发一言，记录他卡住的地方。这些卡点，就是你手册里最需要补写的位置。基本上两三轮这样的“用户测试”跑下来，手册质量会有一个肉眼可见的飞跃。这个方法比你请十个专家来审稿都管用。