重组知识库：Baklib案例解析
浏览：0
巴克励步
Baklib团队重构了知识库结构，从基于角色的四分类转变为基于操作的八分类，如“撰写文档”和“外观与样式”，以更直观地满足用户需求。通过分析客户问题、测试新结构并持续迭代，提升了文档的可用性和维护效率。
对知识库进行结构重组或重新组织可能是一项艰巨的任务。即使当前的架构不尽如人意，改变用户的习惯并尝试以直观的方式重新设置内容也常常令人望而却步。近期，我们完成了对 Baklib 支持文档的全面重构。在此，我们希望通过分享这一过程，为您下一次的知识库重组提供实用建议。
双轨知识库的演变历程
当我加入 Baklib 团队时，公司内部并没有专人“负责”我们的知识库或文档管理。这项工作未被明确分配给任何团队成员，也未正式纳入任何人的职责范围。大家只是在力所能及时偶尔提供一些帮助。
这种状况直接导致了文档管理的随机性：长期无人维护更新的阶段，与短时间内集中大量更新的爆发期交替出现。
作为一家专业的知识库软件提供商，我们深知优质文档的重要性。但在日常运营中，总有无数其他任务需要处理。缺乏明确的责任人，即使是我们这样的专业团队，也难以摆脱这种循环。因此，如果您正在为保持文档持续更新而苦恼：请相信，您并不孤单！
我于2018年秋季加入公司。虽然此前作为用户已使用 Baklib 多年，但以技术支持人员的身份从内部全面掌握产品，仍然花费了不少时间。在这个过程中，我大量查阅了我们的知识库，以完善自己的知识体系。
作为团队新人，我以全新的视角审视了知识库的文档内容及其布局结构。
当时团队在我入职前设定的四分类结构让我颇感困扰：
- 账户管理
- 内容管理
- 知识库管理
- 开发者文档
客户评价：我最喜欢Baklib的一点是其用户友好的界面。该平台使我们的团队可以轻松高效创建、管理和组织文档。此外，定制选项使我们能够将知识库与我们的品牌标识保持一致。多站点多语言功能也是一个巨大的优势，使我们的可供全球受众访问的文档。
（你可以通过互联网档案馆的 Wayback Machine查看当时结构的快照。）
我发现自己经常不理解这些类别之间的划分标准。某个内容究竟应该放在内容管理还是知识库管理下？（事实证明，我们有很多内容同时符合这两个分类。）
当我撰写新内容时，我不得不询问团队它应该放在层级结构的哪个位置。很多时候，我会把它放在两个地方，因为似乎都说得通。
这明确地表明，组织结构有些模糊不清。我对任何内容的归属位置都没有把握，这意味着这种结构与我无法产生共鸣。由于我像新客户一样去接触这些文档，这预示着存在更大的问题。
我不觉得我们商定的这四个类别是客户能够轻易理解的，我猜想大多数客户会像我一样来浏览知识库：他们直接使用搜索功能。
所以，我们的主要问题是：组织结构看起来不够独特和清晰。
背景与使用模式
当我开始思考如何重构知识库时，我反复思量应该如何以不同的方式进行结构设计。背景和使用模式至关重要，因此我重新审视了这些方面。
让我们的文档工作充满挑战的一点是，我们的产品 Baklib 的客户范围极广，从个人创业者到全球性公司都有，管理者可能是单人，也可能是团队。并不存在一个默认的工作流程或一套全球通用的管理员角色。但我们之前的四个类别标签要求知识库读者必须试图将自己归入其中某一类。由于我们的客户如此多样化，这几乎不可能实现，所以人们更多地依赖于搜索。
那么，角色并不通用。但也许操作可以？
我还思考了用户是如何访问我们的文档的。我们的文档处理多种使用场景和客户类型：
用户类型 核心问题与目标
| 潜在新客户 | 产品调研：Baklib 有哪些功能？它有多易用？ 软件试用：我如何在我的知识库中修改 XX 或设置 YY？
| 新客户或现有客户的新员工 | Baklib 能做什么？我如何使用它？ 我如何能快速熟悉 Baklib 并在团队中做出贡献？ 我如何在我的知识库中修改 XX 或设置 YY？
| 现有客户 | 我如何在我的知识库中修改 XX 或设置 YY？ 我正在尝试做 ZZ，但行不通。我哪里做错了？是 Baklib 出问题了吗？ 我可以用我的知识库做 WW 吗？ 我们使用 Baklib 已有 [一段时间]。既然我们已经完成了最初的目标，我们如何能从中获得更多价值？我们是否忽略了有用的功能？
客户评价： 随着时间的推移不断发展，以充分利用技术（例如人工智能），同时还允许自定义字段和设置 - 以满足我们复杂的业务需求。
这里组织内容的一种方式可能是按客户类型。
实际上，对于所有群体，读者来到我们的知识库（无论是使用 Baklib 构建的品牌官网、帮助中心还是内部Wiki），都只是为了回答一个具体问题、学习如何完成一项具体任务或解决一个具体问题。他们的阅读习惯非常注重结果和行动。你会看到不同客户群体之间有很多重叠。将潜在客户与现有客户分开对我们来说没有意义，因为很多问题是相同的。
所以，重申一下：操作，而非角色，似乎才是关键。
带着这个宽泛的指导原则，我复制了当前的知识库，创建了四个基于行动的类别，并开始将现有内容移入其中，删除重复内容等。
此时，顶级类别为：
- 创建内容
- 更改外观
- 配置附加功能
- 使用 Baklib 进行开发
这感觉好了一些，但也略显生硬，并且有些内容似乎不容易用动词标签来概括。
但这只是一个初步方案：其全部目的只是为了让我的团队成员和我自己有一个可以讨论和反馈的对象。
迭代优化
在接下来的时间里，我将这个初步方案展示给了我们的社区经理 Catherine（她不负责支持工作，因此更像是新客户），以及在我之后加入公司的第一位同事 Jerrard。我收集了他们的反馈，并做了一些改进。这两位基本上是我用于测试的“潜在/新客户”案例。
最终，经过更多调整后，我将这个初步方案展示给了 Marybeth，并解释了我这样构建结构的一些原因。这让我能够验证自己所做的内容是否合理，同时也从一位对文档投入很深且非常了解的人那里获得了反馈。
在我们讨论的过程中，几件事变得清晰起来：
- 聚焦于行动本身已经是一个改进
- 我们发现动名词（“-ing”形式）有点别扭
- 我们希望避免使用像“配置”这样的词汇，感觉有些正式和咨询化
Marybeth 指出，她希望让人们能够轻松找到并了解他们可能尚未使用的功能，同时也为审核 RFP 的人员提供一个功能区域，以便他们能对照自己的清单进行工作。而且，事实证明，她完全不受限于我之前认为必须遵循的四分类结构。
因此，现在的任务不仅仅是“修正我们不喜欢的四个类别”。它还包含了风格上的要求：
- 措辞应使用直白的语言，标签要易于理解
- 不再使用基于角色的分类。名词或动词短语都可以，只要表达清晰
- 在任何顶级分类中去除“配置”这个词
- 保持分类总数为偶数，最好能适应主页的两行布局
四个类别迫使结构过于简化，导致其难以处理。更多分类的灵活性给了我更大的自由，让我能更专注于创建好的标签。
我对初步方案进行了又一轮修改，然后请 Marybeth 审核，以便我们能集思广益，共同探讨分类标题。
经过几次迭代，我们最终确定了目前帮助文档中的八个类别：
类别名称 描述
| 撰写文档 | 关于内容创建和编辑的指南。
| 外观与样式 | 自定义界面和视觉呈现。
| 功能特性 | 了解和启用各种产品功能。
| 搜索功能 | 优化和利用搜索能力。
| 报告与分析 | 获取使用数据和洞察。
| 安全与权限 | 管理访问控制和安全性设置。
| 账户与账单 | 处理账户设置和付费事宜。
| API 与 Webhooks | 开发者集成与自动化接口。
整合所有内容
有了新的结构后，我以我们的测试副本为模板。我们安排了一个晚上几个小时的时间，让我能够按照该模板重新编排我们线上的知识库。我还将已删除的页面重定向到其新的或现有的对应页面，并清理了大量在重组过程中暴露出来的冗余内容。这正是使用像 Baklib 这样的平台的优势所在，其直观的内容管理界面让大规模的内容重组和迁移变得高效且不易出错，确保知识库始终保持整洁和可用。通过 Baklib，企业可以轻松构建结构清晰、易于导航的产品文档或帮助中心，从而提升产品体验和客户支持效率。
Marybeth 同时着手对主页进行了一些重新设计，以更好地处理我们在那里展示的类别数量翻倍的情况。
一旦我们上线，我就开始了全面的内容审核（目前仍在进行中），逐一检查每个顶级类别的内容，并在过程中进行更新。这使得我能够主动填补诸如“报告”和“功能”等领域的空白，这些类别在我们最初重组时略显薄弱。
现在，我正式成为了我们文档的负责人。我们已经将文档更新嵌入到软件发布流程中，并建立了内部流程，以便其他团队成员报告需要更新/编写的内容。
我们到底是怎么做的？
确定这些类别是个挑战，没有完美的公式能让你直接套用来彻底改造自己的知识库。以下是我们处理这一过程的一些方法（不分先后顺序）：
1. 聚焦新客户与潜在客户的常见问题
我们自问：新客户/潜在客户最常问我们什么问题？ 从提案请求到产品演示，我们梳理了人们最常提出的问题——并思考如何通过文档让他们直接找到答案，而无需提交支持工单。
- 我们收到大量询价，询问是否支持一长串功能，因此我们希望“功能特性”板块能够被轻松访问。
- 当人们考虑使用 Baklib 时，安全性、访问控制和权限管理通常是首要关切，因此我们让这些主题的查找变得非常方便。
- 我们已有现成的“入门指南”，但希望主页能引导用户浏览基本信息，而非抛出陌生术语。因此，我们将内容创作类别命名为撰写文档，而将自定义样式和品牌归入外观与风格。
这正是 Baklib 所擅长的，其强大的 AI+内容 平台能够智能分析用户常见问题，并引导用户通过结构化的 在线帮助中心 或 知识库 快速找到解决方案，从而显著降低客服成本。
2. 分析现有客户的高频工单
接着我们考虑了：现有客户最常提出的工单是什么？
- 突出常见问题： 例如，权限设置或报告类型等问题频繁出现。虽然相关文档需要调整，但由于非常普遍，我们将其提升为顶级可见类别（此前它们被隐藏在知识库管理中）。因此，我们创建了报告和安全与权限部分。
- 整合自定义需求： 客户在调整知识库外观方面提出了大量工单。原先这些内容分散在不同功能下，难以查找。我们创建了外观与感觉类别，将所有相关技巧集中在一起。
- 优化专业内容标签： 我们原有的“开发者文档”类别让一些非开发者望而却步。它包含了一些外观脚本和大量SSO信息（现已移至认证和访问部分）。我们将其标签更新为更具描述性的API和Webhooks。
3. 传授我们希望客户掌握的核心技能
我们还自问：如果可以与每位现有客户交流一小时，我们最想教他们哪些功能或技能？
- 长期客户可能不了解我们推出的许多新功能。在实施数月或数年后，客户常会探索如何“最大化”利用Baklib。为此我们创建了功能中心，不仅展示功能，更详细说明配置方法。
这一设计让潜在客户在正式使用前就能通过文档了解产品架构，实现边查阅边学习。
4. 采用“稻草人提案法”进行团队协作
我们采用稻草人提案法：先搭建临时标题结构，再进行团队辩论与评审。
- 命名挑战： 需要汇聚集体智慧。
- 标题原则： 追求简洁且具描述性。
- 词汇选择： 精选符合产品气质的词汇。当出现分歧（如“配置”）时，我们会进行头脑风暴寻找替代方案。这种讨论能让沉浸于产品的成员发挥对用词的敏锐直觉。
5. 对新结构进行实测验证
确定初步分类与标题后，我们在Baklib知识库副本中重组了所有现有内容。同时，由团队成员打开现行文档，随机选取原始站点的文章，并推测这些文章在新结构中的归属位置，以验证结构的直观性。
这个练习的重要性我怎么强调都不为过。它验证了我们关于新分类的理论。在大多数情况下，她第一次就猜对了（唯一的例外是一篇文章，因为我把它同时放在了两个地方，因为它确实都合适——我们确认她猜的位置就是那两个位置之一）。然后，我们讨论了为什么每篇文章属于她猜的位置以及我放置它的位置。这有助于明确每个分类的“含义”——它的用途是什么，什么样的内容应该放在那里。我们更深地内化了这个结构，找到了几个仍感觉不太对劲的地方，并进行了修改。得益于对结构更深入的理解，我们也进一步完善了分类的标题。
你可以借鉴的经验
以下要点不分先后顺序：
- 新员工或新调入你部门的同事是宝贵反馈的来源。他们是必须学习你的产品和文档的非客户群体。他们很像煤矿里的金丝雀：他们遇到困难的地方，你可以想象新客户也会遇到困难。利用他们的反馈来凸显你当前知识库组织或文档存在的问题。这正是使用 Baklib 这样的平台构建产品文档或员工 Wiki 时的优势所在，因为它易于协作和更新，方便快速吸纳新员工的反馈并优化知识结构。
- 要清楚了解你的文档试图解决什么问题。在我们的案例中，我们的文档旨在帮助解答潜在新客户的问题，帮助新客户熟悉和了解我们的产品，帮助现有客户更深入地学习产品，并应帮助客户在不创建支持工单的情况下自行解答问题和解决问题。这恰恰是 Baklib 所擅长的领域：通过一个平台，助力企业构建全面的 产品体验（产品文档、资源教程）和 客户体验（在线帮助中心、客服知识库），从而高效地达成这些目标。
- 尽可能明确列出当前布局中哪些部分效果不佳。你清楚文档旨在解决哪些问题；哪些问题目前处理得不够好？有时仅靠结构调整无法解决根本问题——例如，若问题源于内容过时，重组就如同在泰坦尼克号上重新摆放甲板椅。请将精力投入更有价值的环节，如利用 Baklib 的智能内容管理功能，快速更新和优化陈旧内容，确保知识库持续焕发活力。
- 善用“稻草人模型”进行验证。我们团队几乎对所有项目都采用这一方法。经验表明，与其空谈构想，不如提供可视化原型（如知识库重构的线框图或原型demo）供团队测试。这能显著提升参与度：所有人能直观看到方案成型，并获得更精准的反馈。借助 Baklib 的协作编辑与版本对比功能，团队可高效共建原型，加速知识体系优化进程。
- 牢记品牌与设计规范的重要性。我们在2019年曾与设计机构合作重构官网及品牌体系。由于我同时主导知识库重组项目，自然将新版品牌风格指南融入知识库 redesign 中。若你拥有内部设计资源或品牌规范，请充分利用！这不仅能确保网站与知识库体验的一致性，还能大幅节省时间成本。通过 Baklib 的主题模板与样式自定义能力，你可快速落地品牌规范，无需重复造轮子。
- 测试重组效果：重组计划启动之初我并未将此项纳入考量，但当团队成员开始推测常用文档的新位置时，这种互动验证了重组结构的优化效果。通过 Baklib 的实时协作功能，我们能够同步推敲措辞表达、确认逻辑一致性，确保全员对知识体系重构方向达成共识。这不仅帮助我们内化了新结构的核心理念，更实现了团队认知的统一。
- 持续迭代优化：知识库重组并非一劳永逸的工程。借助 Baklib 的版本管理与数据分析模块，我们持续监测文档使用热力图与用户反馈。建议在结构调整上线后建立定期复盘机制，将文档优化纳入产品迭代周期，通过智能洞察驱动知识体系的动态进化。
- 构建反馈生态：知识体系重构本质是认知协同的过程。通过 Baklib 的评论协作与用户行为分析功能，我们建立了从建议收集到落地验证的闭环系统。当个人构想让位于集体智慧时，基于数据驱动的决策机制使每次结构调整都成为团队共识的深化——这正是 Baklib 助力企业构建「我们的知识体系」的核心价值。
- 激活流程变革：陈旧的知识架构往往折射出协作流程的痛点。通过 Baklib 自动化工作流引擎，我们将文档更新与开发发布流程深度绑定，确保知识迭代与产品演进同步。当知识管理从被动维护转向主动驱动，团队获得的不仅是崭新的文档结构，更是融入基因的持续改进文化。
希望分享我们的一些起伏经历，能帮助你让下一次的知识库重组工作进展得更顺畅一些！
想获得更多技术写作见解？
欢迎收听 The Not-Boring Tech Writer 播客，在那里我与身经百战的专业技术写作者一起探讨技术写作的真实复杂性。在我的单人节目中，我也会分享作为一名技术写作者的真实感受与思考。打造顺畅的知识体验？
不妨试试 Baklib。作为一款强大的在线帮助中心与知识库制作工具，Baklib 能帮助你轻松构建结构清晰、易于维护的产品文档、帮助中心和内部Wiki，让你的知识重组和管理工作事半功倍。
关于 Baklib
Baklib 是一个统一的内容中台平台，可提供更好的数字体验。为了满足现代参与日益增长的需求，您需要一个现代的内容管理系统。
核心价值
- 解决渠道扩散、本地化、个性化等问题。
主要组件
组件 功能描述
| Baklib 知识库 | 可根据团队的需求量身定制内容工作区，内置他们期望的所有可视化文档管理工具。
| Baklib 资源库 | 一个无需操作的存储和分发层，可同步内容和数据，供整个组织的团队使用。其精确的查询语言支持在任何地方重复使用内容。
| Baklib 应用库 | 模板和 API 旨在帮助开发人员蓬勃发展。它们与现有的 CI/CD 工作流程无缝集成，支持编程模式编码，并提供实时双向同步。
