码农的产品思维培养第3节----KANO模型介绍《人人都是产品经理》

简介:

满意度的二维模式

满意度是用户对产品感知的效果与期望值相比较后,用户形成的开心或失望的感觉。在日常满意度应用中,我们都认为满意度是一维的,即某个产品(页面),提供更多功能、服务时用户就会感到满意,相反,当功能、服务不充足时,用户会感到不满。因此我们可能会不断在产品(页面)中添加新功能,通过这种方式提升用户的满意度。但是事实上会发现,并不是所有新增或优化的功能,都能提升用户的满意度,甚至有一些还会损害用户体验。

满意度理论研究中发现,并非所有的因素对用户满意度产生的影响都是一维的,二维模式认为,当提供某些因素时,未必会获得用户的满意,有时可能会造成不满意,有时提供或不提供某些因素,用户认为根本无差异,这就是满意度的二维模式。

满意度的二维模式是从赫茨伯格(Herzberg)的双因素理论发展而来。赫茨伯格的理论认为,满意和不满意并非共存于单一的连续体中,而是截然分开的;该理论通过考察一群会计师和工程师的员工满意度与生产效率的关系,发现日常工作中员工的满意度分为两种,一种是激励因素,另一种称为保健因素。激励因素表示工作本身带来的成就、认可和责任;保健因素指公司政策和管理、技术监督、薪水、工作条件以及人际关系等。当具备激励因素时会增加员工的满意,但是当缺乏时不会不满意;而当具备保健因素时不会提高员工的满意,但是当缺乏时,则会造成不满。

Kano模型的二维属性模式

日本教授狩野纪昭(Noriaki Kano)在1984年首次提出二维模式,构建出kano模型。将影响因素划分为五个类型,包括:

 

                                                                                                                                                        Kano模型

魅力因素:用户意想不到的,如果不提供此需求,用户满意度不会降低,但当提供此需求,用户满意度会有很大提升;

期望因素(一维因素):当提供此需求,用户满意度会提升,当不提供此需求,用户满意度会降低;

必备因素:当优化此需求,用户满意度不会提升,当不提供此需求,用户满意度会大幅降低;

无差异因素:无论提供或不提供此需求,用户满意度都不会有改变,用户根本不在意;

反向因素:用户根本都没有此需求,提供后用户满意度反而会下降;

从kano模型的因素分类可以发现,kano并不是直接用来测量用户满意度的方法,而是通过对用户的不同需求进行区分处理,帮助产品找出提高用户满意度的切入点。它常用于对影响指标进行分类,帮助产品了解不同层次的用户需求,识别使用户满意的至关重要的因素。

实际中如何应用kano模型

Kano主要是通过标准化问卷进行调研,根据调研结果对各因素属性归类,然后计算better-worse系数,以显示达成此项因素属性对增加满意或消除不满意的影响程度。

Better的数值通常为正,表示如果产品提供某功能或服务,用户的满意度会提升。其正值越大,代表用户满意度提升的效果会越强,满意度上升的越快;

worse的数值通常为负,表示如果产品不提供某功能或服务,用户的满意度会降低。其负值越大,代表用户满意度降低的效果会越强,满意度下降的越快;

因此,根据better-worse系数,对系数绝对分值较高的项目应当优先实施。

从一个案例来说明:某产品希望优化5项功能,但是不知道哪些是用户需要的。通过kano调研分析,可以分别计算出5项功能的better-worse系数,构建如下四分位图。

 

 
 

根据5项功能的better-worse系数值,将散点图划分为四个象限。

第一象限表示:better系数值高,worse系数绝对值也很高的情况。落入这一象限的因素,称之为是期望因素(一维因素),功能5落入此象限,即表示产品提供此功能,用户满意度会提升,当不提供此功能,用户满意度就会降低;

第二象限表示:better系数值高,worse系数绝对值低的情况。落入这一象限的因素,称之为是魅力因素,功能1落入此象限,即表示不提供此功能,用户满意度不会降低,但当提供此功能,用户满意度会有很大提升;

第三象限表示:better系数值低,worse系数绝对值也低的情况。落入这一象限的因素,称之为是无差异因素,功能2、3、4落入此象限,即无论提供或不提供这些功能,用户满意度都不会有改变,这些功能点是用户并不在意的功能。

第四象限表示:better系数值低,worse系数绝对值高的情况。落入这一象限的因素,称之为是必备因素,即表示当产品提供此功能,用户满意度不会提升,当不提供此功能,用户满意度会大幅降低;说明落入此象限的功能是最基本的功能。

在实际中,我们首先要全力以赴地满足用户最基本的需求,即第四象限表示的必备因素,这些需求是用户认为我们有义务做到的事情。在实现最基本的需求之后,我们应尽力去满足用户的期望型需求,即第一象限表示的期望因素,这是质量的竞争性因素。提供用户喜爱的额外服务或产品功能,使其产品和服务优于竞争对手并有所不同,引导用户加强对本产品的良好印象。最后争取实现用户的魅力型需求,即第二象限表示的魅力因素,提升用户的忠诚度。

因此,根据kano模型计算出的better-worse系数值,说明该产品先需要优化功能5,然后再满足功能1。功能2、3、4对用户来说,有或者没有都是无差异的,并没有必要花大力气去实现。

相关文章
|
2月前
产品经理的行业经验重要吗?
初入职场的产品小白总是会问一个问题:“行业经验对产品经理来说,真的很重要吗?”小编可以坚定地告诉你:“重要!”
|
7月前
|
安全 程序员 数据安全/隐私保护
创业之路的故事|如何设计一个用户系统
本文作者将用户系统的设计类比为一次创业项目。深入浅出地介绍了用户系统的设计方式。
|
安全 小程序 测试技术
初级软件测试面试会问什么 一般分为常识以及技术问题两个板块
对于职场人来说,面试决定了你最后是否能进入到自己喜欢的公司,干上自己想干的工作, 尤其是对于新手测试人来说,如果没点真本事真技术,不了解hr在面试会问些什么问题,就很容易因一时紧张而回答得乱七八糟,导致错失机会,而初级软件测试面试时hr会问些什么,这应该是很多准备找工作的测试人都想要知道。
121 0
|
算法 网络协议 程序员
一个茶艺师转型程序员的小故事
太稳说:别让梦想只是梦想,而要去创造机会,让它成为现实。
150 0
一个茶艺师转型程序员的小故事
|
安全
敏捷回顾会议的套路与实践分享
敏捷回顾实践过敏捷的人都知道,在敏捷中会有很多的会议要开,比如计划会议、站立会议、评审会议以及回顾会议等。如果用几个简短的词语来概括敏捷的精髓,我想一定是:“小步迭代,快速反馈,持续改进”。那么,如何做到持续改进呢?这就涉及到今天谈论的话题:“回顾会议”。
1617 0
敏捷回顾会议的套路与实践分享
|
数据处理 缓存 UED
什么技能产品经理不会提,但技术人必须懂?
缓存是搭建高性能高并发系统的必备手段之一,通常用来解决性能瓶颈,是程序员的必备知识点,也是面试必备考点。
2048 0
|
人工智能
一个阿里产品经理眼中的“垃圾分类”
有人说它是“国内首款真正的垃圾图像识别产品”,对着物品拍照就可以知道这是哪一类垃圾。我不知道是不是真的首款,网友说是那就姑且是吧。
2007 0