在用户需求调研之后，对海量的、碎片化的原始信息进行系统性的归类整理，其核心在于通过一个从“发散”到“收敛”的、结构化的意义构建过程，将原始数据提炼为可指导产品决策的、富有洞察的知识资产。一套专业、有效的信息整理流程，必须涵盖五大关键环节：对原始数据进行初步的清洗与原子化处理、运用亲和图法进行自下而上的聚类与主题提炼、构建用户画像以建立共情、绘制用户旅程地图来可视化体验流程、以及最终将洞察转化为可行动的需求。
其中，运用亲和图法进行自下而上的聚类与主题提炼，是整个整理工作的枢纽。它要求我们将所有访谈记录、问卷答案中的每一个独立的知识点，都转化为一张张小卡片，然后，通过团队协同，将这些看似无关的卡片，根据其内在的关联性进行分组、聚合，并最终为每一个聚合后的小组，提炼出一个能够概括其核心思想的主题。这个过程，是发现“模式”、提炼“洞察”的关键所在。
一、为何要“整理”：从“听到”到“听懂”
用户需求调研，无论是通过访谈、问卷还是现场观察，其产出物，往往是大量的、非结构化的原始数据——可能是长达数十小时的访谈录音、上千份的问卷结果、或是密密麻麻的观察笔记。如果不对这些原始数据进行系统性的整理和分析，那么，我们仅仅是“听到”了用户的声音，而远未达到“听懂”用户的境界。
1. 未经整理的数据带来的陷阱
一个未经整理的、庞大的数据集，就如同一片浓重的迷雾。在这片迷雾中：
我们很容易“只见树木，不见森林”：我们的注意力，可能会被某个声音最大、或最健谈的用户的、极具个性的观点所吸引，而忽略了那些更具普遍性、但却隐藏在大多数沉默用户行为中的共性模式。
我们极易陷入“证实性偏见”：我们会无意识地，从海量的数据中，去寻找那些能够印证我们“原有假设”的证据，而对那些与我们想法相悖的、但却极其宝贵的数据，视而不见。
团队之间无法建立“共享的现实”：每个参与了调研的成员，都只对自己接触过的那一小部分信息，有深刻的印象。当需要进行决策时，团队内部会因为缺乏一个共同的、被整理过的“事实基础”，而陷入无休止的、基于“我记得那个用户说……”的争论。
2. 整理的目标：构建团队的共享认知
需求调研后信息整理的根本目的，是带领整个团队，共同地，将这些碎片化的数据，转化为结构化的信息，再从信息中，提炼出可行动的知识，并最终，升华为指导产品战略的智慧。 这个过程的最终产出物——例如，清晰的用户画像、用户旅程地图等——将成为整个产品团队的“共享知识库”。在后续长达数月甚至数年的产品开发周期中，每当团队需要做出一个决策时，他们都可以回到这个知识库中，去寻找那个最根本的、源自于真实用户的答案。
正如用户研究领域的专家艾丽卡·霍尔（Erika Hall）所强调的：“研究的最终目的，是建立共享的理解。所有的研究产出物，都只是那个共享理解的、有形的证据而已。”
二、第一步：数据的“原子化”处理
在进行任何有意义的聚合分析之前，我们必须首先，将所有非结构化的、长篇大论的原始数据，分解为最小的、不可再分的、有独立意义的“原子化的信息点”。
1. 什么是“原子化的信息点”？
一个“信息点”，可以是一个：
直接的用户引语：“我当时找那个‘保存’按钮，找了快半分钟，差点就放弃了。”
一个明确的行为观察：“用户在A页面，尝试点击了三次那个不可点击的图标。”
一个具体的痛点描述：“每次月底做报表，都需要从三个不同的系统里，手动导出数据再合并，非常痛苦。”
一个关键的问卷数据点：“有65%的用户，表示他们最希望增加的功能是‘模板库’。”
2. “一事一卡”的处理原则
最有效的原子化处理方式，是遵循“一事一卡”的原则。即，将每一个被我们从原始数据中，识别出来的“信息点”，都单独地，写在一张**虚拟或实体的便签（卡片）**上。
例如，在整理一份一小时的用户访谈录音时，我们最终产出的，可能不是一份长篇的纪要，而是20-30张，各自承载了一个独立信息点的便签卡片。
这个看似繁琐的过程，是后续所有自下而上的聚类分析的、必不可少的基础。
三、核心方法一：亲和图法
当我们将所有的“信息点”，都转化为上百张独立的“便签卡片”后，下一步，就是运用亲和图法，来从这些看似混乱的“点”中，发现其内在的“结构”和“模式”。
亲和图法，是一种强大的、协同的、自下而上的意义构建技术。其操作步骤如下：
准备工作：将所有信息点卡片，都展示在一个巨大的、共享的空间中（可以是一整面墙，或一个在线的白板）。邀请所有参与了本次调研的核心团队成员（产品、设计、研发、测试等）共同参与。
独立的、静默的分组：在工作坊的初始阶段（例如，前30分钟），所有参与者，都不能进行任何口头讨论。每个人，都独立地，在墙面前，反复地阅读这些卡片，并根据自己对它们之间“内在关系”或“亲和性”的理解，开始默默地，将那些“感觉上”应该在一起的卡片，移动到一起，形成一个个“卡片堆”。
协同的、有声的命名与再分组：在静默分组结束后，团队开始进入“有声”的协同阶段。由引导者，带领大家，逐一地，审视每一个被自发形成的“卡片堆”。
讨论：团队成员，会就“为何这些卡片应该在一起”，进行讨论。这个过程，常常会引发对用户问题更深层次的辩论和澄清。
命名：当团队对一个分组的“内核”达成共识后，就需要为这个分组，提炼出一个能够精准概括其“中心思想”的“主题名称”。
再分组：在所有小组都有了初步的命名之后，团队会进入更高层次的抽象，尝试将那些在逻辑上相关的“小组”，进一步地，合并为更大的“主题群”。
亲和图法的最终产出，是一张层次分明、逻辑清晰的“洞察地图”。它将上百个零散的信息点，系统性地，组织成了几个（例如，5-8个）大的、能够揭示用户核心痛点和期望的“核心洞察主题”。
在远程协作日益成为主流的今天，像 Worktile 这样的通用协作平台，其内置的“白板”功能，为进行这种多人的、实时的、可视化的亲和图分析，提供了完美的虚拟空间。
四、核心产出物一：用户画像
当亲和图为我们揭示了“用户们，普遍在关心什么”之后，我们还需要一个工具，来回答“我们的典型用户，到底是谁？”。用户画像，正是为此而生的、建立“用户同理心”的核心产物。
1. 什么是用户画像？ 用户画像，是一个基于真实调研数据的、虚构的、但却极其具体的“典型用户”模型。它不是一个冷冰冰的用户分类，而是一个有姓名、有照片、有故事、有喜怒哀乐的虚拟人物。
2. 如何构建
识别用户变量：在亲和图的“洞察主题”中，寻找那些与“用户自身属性”相关的变量，例如，他们的工作角色、专业技能水平、使用的工具、工作的目标、以及面临的挑战等。
发现用户聚类：基于这些变量，观察你的调研样本，是否能被清晰地，聚类为几个行为模式和诉求目标截然不同的“用户群体”。
为每个群体，塑造一个“代言人”：为每一个被识别出的核心用户群体，创造一个用户画像。一份好的用户画像，应包含：
基本信息：虚构的姓名、照片、年龄、职位等。
目标与动机：他/她使用我们产品的，最核心的目标是什么？
行为与习惯：他/她通常是如何工作的？
痛点与挑战：在他/她的工作和生活中，最令其感到痛苦和挣扎的是什么？
一句引言：一句能够高度概括其核心诉求或态度的、原汁味的用户引语。
五、核心产出物二：用户旅程地图
如果说用户画像，是让我们理解“用户是谁”，那么，用户旅程地图，则是让我们理解“用户的完整体验是怎样的”的可视化工具。
1. 什么是用户旅程地图？ 它是一张，以“时间”为横轴，以“用户的行为、思考和情绪”为纵轴的体验地图。它描绘了一个具体的用户画像，为了达成其某个特定的目标，而经历的、端到端的、所有环节。
2. 如何构建
定义旅程的“阶段”：将用户完成其目标的整个过程，划分为几个高阶的、逻辑递进的“阶段”。
填充每个阶段的“细节”：基于亲和图和访谈纪要，在每个阶段下方，详细地，填充上用户具体的“行为”、“想法”和“情绪”。
识别“痛点”与“机会点”：在“情绪”这一栏中，那些处于“波谷”的、用户最痛苦、最沮丧的环节，就是我们产品最亟待去解决的“核心痛点”，也是我们进行产品创新的、最佳的“机会点”。
六、从“洞察”到“需求”
最后，也是最关键的一步，是将上述所有整理和分析出的“洞察”，转化为具体的、可被开发团队理解和执行的“产品需求”。
从“痛点”中，提炼出“用户故事”：每一个在用户旅程地图上被识别出的、高优先级的“痛点”，都应该被转化为一个或多个，遵循“作为一个，我想要，以便于”格式的、清晰的“用户故事”。
将“用户故事”，录入到管理工具中：这些经过了充分的、定性和定量研究支撑的、高质量的“用户故事”，就可以被正式地，录入到像 PingCode 这样的研发项目管理平台的“产品待办列表”之中。在录入时，还应将相关的“用户画像”、“旅程地图”或“访谈纪要”的链接，作为附件，附在故事的描述中，以便于研发团队，能够随时追溯和理解其背后的、完整的“上下文”。
至此，我们就完成了一次，从混乱的原始数据，到清晰的用户洞察，再到可行动的产品需求的、完整的、系统性的整理与转化。
常见问答 (FAQ)
Q1: 用户调研后，是应该先整理数据，还是先有大致想法？
A1: 绝对应该先整理数据。带着预设的想法去整理数据，极易陷入“证实性偏见”，即只去寻找那些能印证自己想法的证据。一个科学的流程，是让“洞察”和“想法”，从对数据的、自下而上的客观整理中，自然而然地“浮现”出来。
Q2: 整理用户调研信息，需要多少时间？
A2: 一个常见的经验法则是，整理和分析的时间，应不低于进行调研本身所花费的时间。例如，如果你进行了一天（8小时）的用户访谈，那么，你至少需要预留出8-16个小时的时间，来进行后续的、高质量的信息整理。
Q3: 如果不同用户在访谈中，提出了完全相反的观点，该如何整理？
A3: 这恰恰是极其宝贵的“洞察”所在。你不应试图去“调和”或“抹平”这种矛盾。而应将其，作为一个“用户群体存在显著差异”的明确信号，进行深入的分析。这常常是进行“用户分群”，并为不同群体，设计差异化解决方案的起点。
Q4: 谁应该参与到调研信息的整理和分析中来？
A4: 应由一个“跨职能”的核心小组，来共同参与。这个小组，至少应包含产品经理、设计师和核心的研发工程师。让研发人员，早期地、直接地，参与到对原始用户反馈的整理中来，是后续建立“共享理解”、提升研发效率的最佳方式。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：百晓生，转转请注明出处：https://www.chuangxiangniao.com/p/640133.html
微信扫一扫 
支付宝扫一扫 
