资料中心有型号参数，售后页有保修规定，另一个文件写着维护步骤。用户遇到问题时，仍要问：“这份说明适合我的设备吗？”内容都在，不代表关系已经讲清楚。
概念图专门整理这种关系。概念写成节点，连接词说明它们怎样关联，连起来应能读成一句话，例如“这份维护说明适用于某个型号”。它适合团队准备内容、讨论知识库结构，也能让技术和设计人员发现各自以为已经说清的规则。
从用户的一次提问，确定这张图要回答什么
假设一家设备企业要做售后知识库，各部门交来的材料包含型号、使用条件、故障表现、处理步骤和保修规定。文件名称不同，一些相同词语还指向不同东西。
“整理全部产品知识”很容易画成一张无边无际的图。这次可以收窄为：“设备出现问题后，用户怎样判断应自行检查还是联系售后？”图里哪些概念值得放，围绕这个问题决定。
提取文件中的名词和短语，先检查同义词与不同含义。技术人员说“故障”，客服记录里可能写“异常”；如果两者范围不同，不能只为了简洁合成一个词。
还要说明图表达现有规则，还是未来设想。团队希望有在线诊断，不代表当前售后已经提供；这类概念可以放入候选方案，但要与已核验关系分开。
把每根线读出来，含糊的地方就会露出来
“型号”和“配件”连上了，看图的人仍会问：是标配、可选，还是仅部分型号适配？连接词往往比节点更能暴露知识缺口。
| 两个概念 | 需要讲清的关系 | 对内容的影响 |
|---|---|---|
| 型号与配件 | 适配、标配或可选 | 是否要注明具体型号 |
| 故障与维护 | 预防、检查或处理 | 操作说明应放在哪种问题下 |
| 服务与用户 | 受理范围和必要条件 | 什么时候可以联系哪个渠道 |
| 文件与产品 | 介绍、证明或操作说明 | 用户取走文件后如何判断用途 |
从较广的概念往具体概念组织层级，譬如服务范围下面再放受理的问题类型。层级表达知识包含关系，不要把公司部门顺序或页面视觉大小当成依据。
请懂业务的人逐条读连接形成的句子，检查有没有缺少条件。设计师能组织表达，却不能凭一条漂亮的连线认定技术规则。未确认的部分写上问题及需核对的人，避免下一位内容编辑把它当成事实。
一条维护步骤同时关联型号和故障类别，跨分支的连接就有用了。它提醒团队：文件不仅要说明解决什么，也要说明适用于谁。只按一个维度分类，另一个判断就得让用户自己补。
成功标志：不同专业的同事读图，能说出同一条关系，并用它回答最初的售后问题；内容编辑也能指出哪些说明缺少适用条件、哪些页面需要相互引用。关键关系有业务人员确认，未知项没有被完整画面掩盖。
保存焦点问题、词语定义、已确认关系和待核对问题即可。不必为节点数量设目标；一条关系改准，可能比多画一片分支更有用。
知识关系讲清楚以后，还要找用户入口
概念图能指导内容编写和相互引用，但网站菜单不能照着整张图复制。产品知识的层级，与用户开始查找时想到的分类，未必相同。
这个售后示例可以考虑按型号进入，也允许从故障表现进入，两条路径指向同一份经过维护的说明。再用卡片分类了解用户怎样分组和命名，而非默认技术部门的称呼人人都懂。
纸质说明书、包装和随设备提供的工具，也可能承担一部分解释。如果用户习惯先翻实体文件，可以借助物件分析看他保留什么、在哪个时刻使用，再决定网页与文件怎样配合。
产品规则改变后，图和相关页面要有人更新。指定业务核验与内容维护的责任，让同一条说明不要在多处各改一遍、最后再次出现冲突。
内容多之前，先让关系准确
用户真正需要的，可能只是确认“我能不能按这份说明做”。把概念之间的适用、依赖和例外讲清楚，知识库才有机会替他少做一次猜测。
58UI可以先梳理产品知识关系，再落实到信息架构、UI/UX与企业官网设计开发；品牌视觉和响应式适配也需要建立在清楚内容之上。查看设计服务，或带着现有产品资料联系58UI，可以先讨论客户最常问的那个问题。
相关服务
