访谈结束，团队总结“客户希望方便、专业、清楚”。设计师听完，仍不知道服务页应该补什么。参与者说“接不上现有设备怎么办”，那句具体的担忧却在概括中消失了。
主题网络从文本编码出发，将基本主题组织为中层的组织主题，再提炼总体主题。它适合分析丰富的访谈、开放回答或笔记，让结论能回到具体材料，解释用户怎样理解一个问题。
用一个服务判断问题划定材料
以技术服务企业整理官网服务页访谈为假设场景。分析问题是：客户如何判断服务是否适合自己的需求。案例、兼容条件、准备资料和咨询后责任都可能相关，闲聊则不必全部进入同一网络。
先匿名化材料，保留参与者、任务、片段的内部编号与上下文。删除身份信息不能顺手删除理解所需的条件，例如旧设备与新设备会影响兼容疑问。
逐段读，给有意义的片段加简短代码。一段可以有多个代码，暂时分不清就保留。代码先接近具体意思，别一开始就用“体验差”覆盖内容。
从原话往上走，层级不能只换大词
“我不知道设备能不能接入现有系统”，可以标为兼容条件不明确。“不知道要提前给什么接口资料”，则是准备要求缺失。这些基本主题共同涉及判断实施条件，可以形成一个组织主题。
| 示例片段 | 基本主题 | 可讨论的组织主题 |
|---|---|---|
| 不知道能否接现有设备 | 兼容条件不明确 | 判断实施条件 |
| 找不到应准备的接口资料 | 准备要求缺失 | 判断实施条件 |
| 案例相似但规模不同 | 案例可比性不足 | 判断经验是否相关 |
| 咨询后不知道由谁处理 | 后续责任不清 | 判断协作方式 |
再比较组织主题，可能提炼“客户在咨询前需要判断合作能否推进”的总体主题。它是一项解释，需要其他片段支持，不能只因一句话听起来有道理，就设为网络中心。
原因、感受和方案建议要分清。客户缺判断依据，不等于他明确要求某个选型工具；研究者喜欢工具，也不能把偏好写进主题。
画出关系之后，返回原文检查
将总体主题置于中心，连接组织主题，再连接基本主题。每条线都应能解释，名称也应有层次区别；把“资料不足”“信息不够”“体验不完善”连在一起，并没有增加理解。
沿连接回查片段，看看是否遗漏条件、抽错意思或隐藏反例。有人可能愿意直接咨询，不需要事先看完实施细节，这会限制总体解释的适用范围。必要时拆成不同网络。
主题会随着阅读修订。例如“缺资料”逐渐分成“资料不存在”与“无法判断资料是否适用”，两者需要不同设计回应。改定义后回查前面的材料，避免只有后来的片段使用新标准。
多人分析时，可以各读同一小段，再讨论代码和主题。目的在于说明规则与差异，不用职位决定正确解释，也不强求每个人一次就完全一致。
成功标志是团队能从总体主题沿层级找到具体片段，解释关系，并指出哪些反例限制了结论。换一位分析者，也能理解为什么这样归纳。
主题出现得多，未必意味着更多人这样想
一个人反复提兼容问题，会留下很多片段。片段数量不等于人数，更不能当成全部客户的比例。要汇报覆盖，可以另列参与者与主题对应，但仍需说明招募与材料范围。
节点大小也要谨慎。若尺寸只是排版，别让它暗示统计重要性。主题网络解释意义与关系，不自动证明因果，也不会自行选出改版优先级。
亲和图整理可以帮助早期聚类，但进入主题网络后，仍要保留三层主题及文本关系，不能只有几堆卡片和一个总标题。
从主题到服务页，仍有一段设计判断
本例的主题可以支持“服务页应提供判断兼容条件的必要信息”。团队再讨论把条件放在哪、怎样解释、什么情况转人工，而不是直接将总体主题变成功能需求。
用原型请目标客户判断服务是否适用，检查这些信息能否支持任务。资料可信度与技术条件由相应人员核实，页面理解由用户任务验证。
交付匿名材料索引、代码定义、网络、代表片段、反例和待验证项。这样“更清楚”终于落到实施条件与咨询责任上，设计师也知道为什么改，以及哪些解释仍有限制。
把访谈线索转成页面信息
58UI的企业官网设计开发与UI/UX服务，可把已分析的问题落实到服务页层级、说明和咨询原型；品牌视觉设计则帮助这些内容形成一致表达。界面取舍应接到具体证据，效果还需实际任务检查。
你可以了解设计与开发服务，查看官网与界面案例。通过沟通具体设计问题提供匿名片段与初步主题，比只带几句概括更容易确定改版重点。
相关服务
