KANO模型

针对KANO模型的一次详细介绍，帮助大家更深一步了解该模型以及对该模型的实践与应用，觉得不错就点个赞呀~

KANO模型

• 使用场景
  • 定性分析模型
    • 一般不直接用来测量用户的满意度，常用于识别用户对新功能的接受度
  • 举个栗子：产品经理说根据后台数据来看，很多功能用户不怎么用，使用率特别低。我们心里产生疑问，会不会是用户本身对些功能就没需求了，所以他不用。产品经理会觉得说，那会不会是功能的位置不太明显或者是推广力度曝光性不够。在这个时候，那我们就可以用卡诺模型来验证一下这个功能。到底用户有没有这个需求？
  • 并不适用于当价值衡量需考虑其他维度因素，如需要将战略、商业收益等等纳入考虑时
• 模型目的
  • 怎么样去辨别需求的真伪，以及确定是真需求以后怎么样去做量化的优先级排序
• 概念起始
  • 双因素理论
    • 国的心理学家（赫茨伯格）
    • 满意的反面不是不满意，他们不是连续体，二者是可以分开的
      • 激励因素
        • 用户满意的工作本身给你带来的成就感，认可度和责任
      • 保健因素
        • 保健因素就跟公司政策福利好不好，薪水好不好，工作环境如何这种就叫做保健因素
      • 双因素理论的核心是激励因素
        • 发自内心的认可责任，激励因素才能够给人们带来满意度的提升
        • 保健因素，只能够消除人们的不满意。刚刚具备的时候，员工并不会满意
  • 狩野模式(Kano model)
    • 子主题
• 需求组成
  • 基本型需求
    • 基本型需求和前面讲的保健因素相似，对用户而言，基本型需求是必须满足的，是理所当然是你该做的
      • 对于这种基本型需求，即使超过了顾客的期望，顾客充其量达到满意，但是他不会对此表示表示出更多的好感
      • 但是你只要稍微有一点点疏忽，没有达到用户的期望，用户的满意度就会一落千丈
  • 期望型需求
    • 其实没有对基本需求那样苛刻
      • 他们并不会认为说，期望型需求是产品必须提供的
      • 但当产品提供给用户的期望型需求越多，用户的满意度就会越好
  • 兴奋性需求
    • 给用户提供一些完全出乎他意料的，让用户感到惊喜的 ，但这种魅力型需求往往是些无关紧要的需求
      • 当给用户不提供种兴奋型需求时，用户无所谓
      • 但当提供了，用户会觉得好像也不错，用户满意度也会随之有所提升
  • KANO模型第一次提出时的三种用户需求层次
• 需求分级
  • • 横轴
      • • 功能的具备程度，完善程度可以理解为功能，它开发的好不好，做的好不好
        • 某功能或者是某一类需求它越向右边，功能做得越好，具备程度越高越完善。越靠左边，功能做得越差
    • 纵轴
      • • 用户的满意度
        • 用户的满意度，纵坐标越往下表示用户越不满意
  • • 必备需求/必备属性
      • M
        • • 相关指数函数关系
          • 当你功能越具备、功能做得越好，用户满意度你看他虽然有所提升，但是他永远是在零度以下的 ，他不会提升特别高。
          • 具有这类属性的功能属于产品的基本功能，如果不满足该需求，用户满意度会大幅降低。但是这类功能也无法给用户带来惊喜，满意度不会因为这类功能大幅提升。
        • Must -be- Quality/Basic
    • 期望需求/期望属性
      • O
        • • 线性相关且成正比
          • 如果提供该功能，客户满意度提高，如果不提供该功能，客户满意度会随之下降。
        • One- dimensional Quality
    • 兴奋需求/魅力属性
      • A
        • • 相关指数函数关系
          • 就算我提供需求，在具备程度很低的地方，蓝色的线最多永远接近于横轴，但是他不会低过下面。
          • 让用户感到惊喜的属性，如果不提供此属性，不会降低用户的满意度，一旦提供魅力属性，用户满意度会大幅提升。
        • Attractive
    • 无差异需求/无差异属性
      • I
        • • 一条横向直线
          • 无论提供或不提供此功能，用户满意度不会改变，用户根本不在意有没有这个功能。
        • Indifferent Quality
    • 反向需求/反向属性
      • Q
        • • 线性相关且成反比
          • 属于反向属性特点的功能是很少的，除非这个产品经理真的是个xx，要不然不太会做出反向属性的功能。
          • 提供具有此需求的功能后，用户满意度反而会下降。
        • Reverse Quality
  • 模型是变的
    • 需求属性会随时间变化而改变
      • 不是一次KANO模型就搞定终身的，要经常过几个月或一年，根据市场需求，竞品的竞争情况体验好坏来重新梳理一下工作的优先级
    • 需求会因人而异
    • 需求会因为文化差别而不同
• 实践步骤
  • 收集需要分析的功能，并明确定义
    • 同一问题正反Likert五点式量
      • • 设置问卷问题的组成
          • 功能定义，要告诉给用户是什么样的功能定义
          • 给用户正向题。如果有这个功能，你的评价是？
          • 给用户反向题，就假设我们没有了你会怎么做，你会怎么样，开心还是难过。
        • 定义的功能有哪些
          • 想要去验证的功能属性，但是是平台上没有上线的功能
          • 想上线十个新功能，但是到底先上哪个后上哪个？把每个功能做成每一道题目，让用户去选择 ，那么这个时候功能的定义，你更加要写的非常清楚了
  • 发放问卷
    • 时间允许的话建议使用电话访问
      • 因为当这个用户，给到你一些让你觉得不太正常或匪夷所思的一些选项或者态度时，你可以及时问为什么
      • 可以回访
  • 问卷编译
    • 把回收到的问卷转换成可视化的数值
      • • 正向的用5、4、3、2、1表示。反向用A、B、C、D、E表示这样的话，就可以合并单元格了
        • 就可以把单个用户针对单个功能的正反两个数字合并成组合答案形式
    • 记录
      • 这个用户对这个功能的正向评价是几分，反向评价是几分
  • 合并每项功能的正反向答案，统计每项功能的答案占比
    • • 5*5=25种的答案形式（因为正像提示五个选项，反向也是五个选项）
  • 需求属性对应表
    • • 查看
        • 黄色区域则代表该功能是必备属性
          • 具备的时候，用户觉得理所当然无所谓，勉强接受 ，感情不强烈，一旦不具备用户很不喜欢，他是属于必备因素
        • 绿色则代表期望属性
          • 具备，用户很喜欢。不具备，用户很不喜欢。
        • 红色则代表是魅力属性
          • 当功能具备的时候，用户都是选择很喜欢。当不具备的时候，表现的态度是理所当然 、无所谓、勉强接受。
        • 灰色则为无差别属性
          • 功能做不做都一样。做也无所谓，不做也能接受，所以这个功能可做可不做。
          • 一般我们是选择不做的。
        • 蓝色则是反向属性
          • 当功能具备的时候，用户就很不喜欢。当这个功能不具备的时候，用户是很喜欢的。很明显的反向属性的结果。
          • 该功能是不能做的，做了以后用户就不开心，是得罪用户的功能。
      • 可疑数据
        • 都满意/都不满意
  • 需求判别
    • 原则：总和占比多者取胜
      • • 一道题目是对应上面的一张表格的
        • 哪个单元格中的选择的人数最多，单元的是颜色，它属于那种结果属性了。该功能就是那种属性
        • 以上面的表格举个栗子： 黑色区域，可疑结果 ，百分之零的用户选择这个选项 ，可疑记为：2% 红色区域，魅力属性，的人数占比分别是：14%+3%+7%，即魅力人数占比：24% 绿色区域，期望属性，占比43%，即该功能选择是期望属性的人数占比是：43%
        • 进行大小对比：期望>魅力>无差异>必备>可疑>反向
        • 说明该功能属于期望属性功能
    • Better系数和Worse系数
      • 适用场景
        • 当属性占比出现两个第一的时候，这个时间段只有一个功能开发的排期
        • Worse系数或者Better系数是当用来无法无法根据属性来去做优先级的时候，但是又不得已一定要选做一个
      • 计算方法
        • Better系数=（魅力属性+期望属性）/（魅力属性+期望属性+必备属性+无差异因素）
          • Better/SI=（A+O）/(A+O+M+I)
        • Worse系数=（必备属性+期望属性）/（魅力属性+期望属性+必备属性+无差异因素）（-1）
          • Worse/DSI= -1 *（O+M）/(A+O+M+I)
      • 系数表示
        • Better满意系数
          • 代表如果产品提供某种功能或服务，用户满意度会提升
          • Better值越大/越接近1，则表示用户满意度提升的效果会越强
        • Worse不满意系数
          • Worse的数值通常为负，代表产品如果不提供某种功能或服务，用户的满意度会降低
          • 其绝对值越接近1，则表示对用户不满意度的影响越大，满意度降低的影响效果越强，下降的越快
      • 判断方法
        • 做了以后满意度提升度更大，我就做哪个。或者哪功能不做满意度下降会更多，那我就做哪个
  • 分析功能优先级
    • worse为横坐标，better为纵坐标。将用户对功能重要程度的打分作为气泡的平均值
      • 正负原值表示
        • • 第一象限
            • 期望属性，优先级较高的需求
          • 第二象限
            • 兴奋属性/魅力属性
          • 第三象限
            • 无差异属性
          • 第四象限
            • 必备型属性
      • 绝对值表示方式
    • 确定优先级
      • 基本型需求 > 期望型需求 > 魅力型需求
      • 尽量避免做无差异需求和反向需求
    • 如何做
      • 根据KANO模型建立产品需求分析优先级，运用到产品设计中就是要抓住用户的核心需求，解决用户痛点（基本型需求），抓住用户痒点（期望型需求）。在确保这两者都解决的前提下，再给用户一些high点（兴奋型需求）。
• 优缺点
  • 优点
    • 细致全面的挖掘功能的特质，基本上五个功能属性已经很全面了，帮你细致的来定义，它属于哪种功能属性的特性
    • 进行优先级的排期来辅助项目
    • 原来用户没有抱怨，并不代表他满意，转变我们的思维认知
  • 缺点
    • 引起情绪上的波动，引起数据质量的下降
      • 一道题目要问两遍，正想问一遍反向的一遍。会引起用户情绪上的焦躁，有些波动
      • 解决办法
        • 尽量减少要去探索了功能的个数
        • 建议在做KANO模型时，功能最好控制在十个以内
    • 部分功能属性用户也许并不是很好理解
      • 解决办法
        • 可以通过一些用户案例来做一些诠释备注，帮助用户更好地去理解功能
    • 我很喜欢"和"我很不喜欢"过于极端化
      • 解决办法
        • 去掉“很”字
    • 幸存者偏差，反馈的用户本身就有较强的反馈意愿，无法体现全体用户的真实情况
    • 只从用户满意度和功能具备度出发，不适用与需要考虑其他维度因素，例如，收益、战略等等
  • 注意点
    • 样本相对越多，数据相对越准确
    • KANO问卷就跟正常的一样，回收有效样本量至少三十的来做
• 通过使用KANO模型来判断哪个需求是最有价值，是最能提高用户对于产品的满意度的，以便更好地排出功能开发的优先级。