核心模型:从答案出发,而非从解决方案开始
核心模型是一种颠覆传统数字开发的实用方法论。不同于从解决方案或结构入手,我们首先提出关于用户需求的假设,然后遵循一个简单框架,将不同团队聚集在一起创建更有效的数字体验。通过按正确顺序提出六个好问题,团队围绕用户任务和业务目标达成一致,创建超越组织界限的清晰度。
解决方案优先思维的陷阱
您是否曾参加过每个人都直接跳转到解决方案的会议?“我们需要一个新应用程序!”“让我们重新设计主页!”“人工智能将解决所有问题!”这种解决方案优先的思维在数字开发中普遍存在——这也是为什么如此多的项目未能提供真正价值的原因。
作为核心模型方法的创建者,我开发了这种方法来翻转剧本:不是从解决方案开始,而是从答案出发。
有什么区别?从解决方案开始意味着强加我们先入为主的想法。从用户任务的答案出发意味着形成关于用户需求的假设,然后退后一步遵循一个验证和完善该假设的简单结构。
六个带来更好答案的好问题
核心模型的核心就是按正确顺序提出的六个好问题,再加上第七个驱动行动的问题。它诉诸常识——在复杂的数字项目中,常识往往供不应求。
当我向一个网站运营困难的大型组织介绍这种方法时,他们的数字负责人承认:“我们一直在分别问所有这些问题,但从未以这种将它们连接起来的结构化方式。”
这些问题帮助团队暂停、围绕重要事项达成一致,并创建实际有效的解决方案:
- 我们试图帮助谁,他们的处境如何?
- 他们试图完成什么?
- 我们想要实现什么?
- 他们如何接近这个需求?
- 他们下一步应该去哪里?
- 他们需要的基本内容或功能是什么?
- 需要做什么来创建这个解决方案?
这个简单框架在团队边界之间创造了清晰度,将内容创作者、设计师、开发人员、客户服务、主题专家和领导层聚集在一起,形成共同的理解。
从假设开始
核心模型过程通常在研讨会之前开始。项目负责人或协调人与关键利益相关者合作:
- 根据组织优先级和用户需求确定候选核心
- 收集现有的用户洞察和业务目标
- 形成关于这些核心应该实现什么的初步假设
- 为研讨会参与者准备相关的背景材料
这种准备确保了研讨会本身是专注和高效的,团队验证和完善假设而不是从零开始。
核心模型:创造一致的六个要素
让我们详细探讨核心模型的每个要素:
-
目标群体:首先建立同理心
核心模型不是使用详细的人物角色,而是从快速原型人物角色开始,为特定情境中的用户建立同理心:
- 一位父母在漫长的一天后深夜研究托儿选项
- 一位小企业主在客户会议间隙试图理解税务要求
- 一位新居民用第二语言导航不熟悉的公共服务
关键是在深入解决方案之前人性化用户并理解他们的情感和实践背景。
-
用户任务:人们实际试图做什么
除了功能或内容,用户实际试图完成什么?
- 就重大购买做出明智决定
- 找到申请服务的正确表格
- 理解复杂过程中的下一步
- 检查项目或福利的资格
这些任务应基于用户研究并驱动后续一切。顶级任务方法论是实现这一目标的好方法。
-
业务目标:成功的模样
每个数字计划都应连接到明确的组织目标:
- 增加在线自助服务采用率
- 降低支持成本
- 提高满意度和忠诚度
- 满足合规要求
- 产生潜在客户或销售
这些目标提供了成功的衡量框架。(如果您使用OKR,您可以将这些视为连接到您整体目标的关键结果。)
-
向内路径:用户场景和方法
这个要素不仅包括可查找性,还包括用户的整个方法和心智模型:
- 什么场景导致他们有这个需求?
- 他们使用什么术语来描述他们的问题?
- 他们会如何向Google或LLM表达他们的需求?
- 他们正在经历什么情绪或紧迫感?
- 他们使用什么渠道或接触点?
- 他们带来了什么现有知识?
理解这些不同方法的角度确保我们在用户所在的位置满足他们。
-
向前路径:引导旅程
用户在与这个核心互动后应该做什么?
- 采取特定行动继续他们的任务
- 探索相关信息或选项
- 连接到适当的支持渠道
- 保存或分享他们的进度
这些路径创建连贯的旅程(核心流)而不是死胡同。
-
核心内容:基本解决方案
只有在映射了前面的要素之后,我们才定义实际的解决方案:
- 必须包含什么信息?
- 什么功能是必需的?
- 什么语气和语言是合适的?
- 什么格式最能满足需求?
这成为我们需要创建什么的蓝图。
行动卡:从洞察到实施
核心模型过程以回答关键第七个问题“需要做什么来创建这个解决方案?”的行动卡达到高潮。
这些卡片通常包括:
- 需要的具体行动
- 负责人
- 完成时间表
- 所需资源
- 依赖关系和约束
行动卡将洞察转化为具体的下一步,确保研讨会导致实际改进而不仅仅是有趣的讨论。
核心对的力量
核心模型方法的一个独特方面是核心对工作——来自不同能力或部门的两个人在同一张核心表上合作。这种方法创造了几个好处:
- 跨学科洞察:将具有深厚主题知识的人与带来新鲜视角的人配对
- 内置质量控制:合作伙伴发现盲点并挑战假设
- 简化沟通:一对一对话比小组讨论更有效
- 共享所有权:两个参与者都对解决方案产生承诺
- 知识转移:技能和洞察在学科之间自然流动
理想的对结合不同的视角——内容和设计、业务和技术、专家和新手——创建任何一方单独都无法实现的平衡方法。
在团队内部和之间创造一致
核心模型擅长创造两种关键类型的一致:
在跨职能团队内部
现代团队汇集了不同的能力:
- 内容创作者专注于信息和叙述
- 设计师考虑用户体验和界面
- 开发人员考虑技术实现
- 业务利益相关者优先考虑组织需求
核心模型为这些专家提供了一个共同框架。不是设计师只关注界面或开发人员只关注代码,而是每个人都围绕用户任务和业务目标达成一致。
正如一位UX设计师告诉我的:“核心模型完全改变了我们的团队动态。不是将线框图交给不理解设计决策背后‘为什么’的开发人员,我们现在对我们试图实现什么有共同的理解。”
在客户旅程中的团队之间
用户不会在孤岛中体验您的组织——他们在接触点和团队之间移动。核心模型帮助连接这些体验:
- 营销团队理解他们的活动如何连接到服务交付
- 产品团队看到他们的功能如何适应更大的用户旅程
- 支持团队获得关于用户路径和常见问题的背景
- 内容团队创建支持整个旅程的信息
通过映射核心之间的连接(核心流),组织创建连贯的体验而不是碎片化的互动。
打破组织障碍
核心模型创建了一个中性框架,各种视角可以在保持统一方向的同时做出贡献。这在传统组织结构中特别有价值,其中内容责任分布在各个部门之间。
研讨会:使之发生
核心模型研讨会以实用格式将这些要素结合在一起,可以适应不同的背景和需求。
研讨会格式和时间安排
对于跨组织孤岛有多个利益相关者的复杂项目,理想格式是全天(6小时)研讨会:
- 第一小时:基础和环境
- 第2-4小时:核心映射
- 第5-6小时:演示、讨论和行动计划
格式高度灵活:
- 有方法论经验的团队可以在短短30分钟内进行重点会议
- 较小的项目可能只需要2-3小时
- 远程团队可能会将研讨会分成多个较短的会议
研讨会环境
核心模型研讨会在不同环境中蓬勃发展:
- 模拟:使用纸质核心表的传统方法
- 数字:使用Miro、Mural、FigJam或类似平台的虚拟研讨会
- 混合:物理研讨会中的数字画布,结合面对面互动和数字文档
注意:您可以在这里找到所有下载和模板。
核心对:成功的关键
核心对的组成对成功至关重要:
- 一个人应该很好地了解解决方案领域(主题专家)
- 另一个人带来新鲜视角(并了解不同领域)
这种组合确保了知识的深度和新鲜思维。跨职能配对创建自然的知识转移并打破孤岛。
研讨会可交付成果
重要提示:研讨会不产生最终解决方案。
相反,它创建一个包含以下内容的全面简报:
- 内容开发的优先级和背景
- 设计和用户体验的方向和想法
- 功能的要求和规范
- 具有明确所有权的实施行动计划
这份简报成为后续开发工作的基础,确保每个人都朝着相同的目标构建,同时在实施期间为专家专业知识留出空间。
开始:您的第一次核心模型实施
准备好将核心模型应用到您的组织了吗?以下是如何开始:
-
形成您的初步假设
在将所有人聚集在一起之前:
- 确定用户遇到困难且业务影响明确的核心
- 收集可用的用户洞察和业务目标
- 形成关于这个核心应该实现什么的假设
- 确定跨相关部门的关键利益相关者
-
聚集正确的核心对
选择代表不同视角的参与者:
- 内容创作者与设计师配对
- 业务专家与技术专家配对
- 主题专家与用户倡导者配对
- 资深人士与新鲜视角配对
-
遵循七个问题
指导核心对完成过程:
- 我们试图帮助谁,他们的处境如何?
- 他们试图完成什么?
- 我们想要实现什么?
- 他们如何接近这个需求?
- 他们下一步应该去哪里?
- 他们需要的基本内容或功能?
- 需要做什么来创建这个解决方案?
-
创建行动计划
将洞察转化为具体行动:
- 在行动卡上记录具体的下一步
- 为每个行动分配明确的所有权
- 建立时间表和里程碑
- 定义如何衡量成功
结论:结构化框架中的常识
核心模型有效是因为它将常识与结构相结合——按正确顺序提出正确问题,确保我们解决真正重要的事情。
通过从答案出发,而不是从解决方案开始,团队避免了过早的问题解决,并创建真正服务于用户需求同时实现组织目标的数字体验。
无论您是管理传统网站、创建多渠道内容还是开发数字产品,这种方法论都提供了更好的协作、更清晰的优先级和更有效结果的框架。
本文是我著作《核心模型——数字策略和设计的常识方法》的简短改编。您可以在thecoremodel.com上找到关于本书的信息和更新资源。