在产品开发过程中，理解并满足用户需求是成功的关键。设计团队、工程团队、管理团队以及支持团队都有各自的需求和看法，如何协调这些不同的需求并制定有效的产品策略？卡诺模型提供了一种独特的方式来识别和分类客户偏好，帮助团队做出更明智的决策。
设计团队会列出一份用户对产品的需求清单。工程团队会提出不同的功能组合。管理团队只想要那些能给公司带来利润的功能。支持团队则看到完全不同的需要修复的功能。
产品团队如何知道该朝哪个方向发展？
作为设计研究人员，我们依靠客户的言论和行为来深入了解并发现他们想要什么。
然而，我们中的许多人经常难以找到新方法来有效地量化和可视化这些需求，以便这些团队达成一致。客户当然可以对功能进行投票和排名，这提供了一个很好的概述，但并不总是能让人们更深入地了解哪些是必备功能，而不是已经预期的功能。
进入卡诺模型。
卡诺模型是20 世纪 80 年代由Noriaki Kano教授开发的一种产品开发和客户满意度理论，它将客户偏好分为五类。
该模型通过评估每个功能的两个指标（满意度和情绪）来帮助我们了解客户对产品功能的看法。
对这两个指标的回应将分为以下五个类别之一：有吸引力、表现良好、无所谓、必须有、不想要。
制作一份问卷，将每个功能单独列出。对于每个功能，最好通过原型或交互式线框展示该功能可以做什么（如果可能）。不要为此花费太多时间制作原型：它只是一个让大家了解想法的原型。
有些人甚至在原型中也会对细节很着迷，因为他们可能喜欢这个想法，但不喜欢它的实现方式。
如果无法演示这些功能，那么解释性文字描述也能起到很好的作用。
专业提示：在与其他 IBM 研究人员的讨论中，那些更成功的人测试了 15-20 个功能。那些不太成功的人测试了 30-40 个。测试超过 20 个功能对于客户和研究人员来说都是大量的数据，需要进行分析。
查看每个功能后，用户选择对 Kano 问卷的回答：
（丹尼尔·扎卡里亚斯就如何清晰地提出这些问题提出了一些很好的建议）
针对以上两个问题的标准卡诺问卷答案是：
Daniel Zacarias还为这些答案的答案集提供了一些其他选项。基本上，如果你想尝试 Kano 模型，请阅读他的整篇文章。这真是太棒了。
Jan Moorman还建议添加第三个问题：这个功能有多重要？她建议使用 9 点李克特量表，从“一点也不重要”到“极其重要”。但是，当试图在李克特量表上说出 9 点的重要性时，这有点棘手。似乎 7 点李克特量表更容易。
一旦你有了答案，你就可以开始分析过程了，Daniel Zacarias对此进行了非常详细的描述。我强烈建议你去读一下。
IBM 的研究人员发现，虽然这些数字很棒，但数字本身并没有告诉任何人为什么，这是我们管理团队必然会问到的问题。一个团队使用 Kano 模型进行了大约 15 次定性访谈。另一个团队在收到 40 人的问卷后进行了 5 次定性访谈。两个团队都强烈建议在此过程中添加定性访谈，因为它增加了有助于为数据提供缺失背景的叙述。
IBM 的一个使用 Kano 模型的团队对再次使用该模型犹豫不决。该团队使用他们认为是当前工作方式的场景来设置问卷以描述功能。
然而，随着测试的进行，很快就发现设计团队的场景并没有反映出客户实际使用产品的方式，测试很快就偏离了轨道。
使用场景来描述特征的想法很好，但当我们讨论他们的方法时，很明显必须事先验证场景。在建立现状的生成研究之后，Kano + 场景组合将非常有效。
另一条建议是减少测试功能的数量。负责测试 30-40 个功能的团队表示，测试内容过于繁琐，测试结束后客户会感到不知所措和疲惫不堪。
卡诺模型非常擅长对功能进行优先排序。卡诺模型背后的理论是丹尼尔·扎卡里亚斯所说的“愉悦感的自然衰减”。
创新的想法和产品从令人兴奋和新颖的功能（位于卡诺图的顶部，具有吸引力）转变为预期的功能（位于底部，最好是必备功能，最差是贬低功能）。
以无线互联网为例。那是 2001 年，你正在出差，有一台配有以太网端口和 WiFi 的顶级笔记本电脑。你住在一家酒店，你得知他们有以太网端口供你连接互联网。他们的房价中不包含无线互联网，但你可以在他们的商务中心使用 WiFi。你很兴奋！太棒了！多么棒的选择！
时间快进到 2017 年。您正在出差，有一台带 WiFi 的基本笔记本电脑。您在一家酒店，发现他们有以太网端口供您连接互联网。他们的房费中不包含无线互联网，但您可以在他们的商务中心使用 WiFi。您很生气！这家酒店是哪个星球的酒店，您还要为互联网支付额外费用？！还有谁会使用他们的以太网端口连接互联网？
最初是一个很有吸引力的功能（房间里有以太网端口，商务中心有 WiFi），但 16 年后却变成了不受欢迎的功能。
如果团队不了解客户的需求，他们可能会专注于预期的功能，而不是有吸引力的功能。一位使用卡诺模型的 IBM 研究人员在自己的团队中注意到了这一点：“有些功能让团队非常兴奋，然后意识到那些是赌注。”
当我们讨论卡诺模型时，我们推测它还具有其他一些潜力：
衡量痛点的深度
在产品生命周期内对功能进行基准测试，以评估满意度随时间的自然衰减
这个模型可以帮助揭示现有的痛点到底有多严重。卡诺问卷很容易让研究深入挖掘，以了解更多关于痛点为什么如此严重，以及这些功能对客户如此重要的原因。它可以揭示一些以前未被发现的需求，并带来进一步的创新。
我们讨论了使用 Kano 模型定期评估功能，以观察哪些功能降级到较低类别。这种纵向测试，在拥有足够大的客户群的情况下，可以表明市场趋势和期望，并有助于随着时间的推移继续证明研究价值。它还可以帮助团队了解他们的产品何时开始停滞不前，需要创新的想法来重回引领潮流的地位。
IBM 的设计团队有时会担任项目顾问。IBM 的一些设计团队被要求参与项目，以“清理可用性”，并在产品发布前不久为产品增添神奇的用户体验。其他设计团队则暂时嵌入更广泛的产品团队。
讨论结束时，我们留下了一个未解决的问题：如果你无法影响产品，卡诺模型还有用吗？你可能无法影响产品，因为它已经在开发中，因为管理层的反对，因为设计团队只是产品团队的临时组成部分，等等。使用卡诺模型值得吗？
或者，即使你无法影响产品，它仍然有用？
有什么想法吗？
翻译：蒋昌盛
原作者：cary-anne olsen-landis
原文链接：https://medium.com/design-ibm/kano-model-ways-to-use-it-and-not-use-it-1d205a9cf808
本文由 @蒋昌盛 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。