供需关系的本质到底是什么?是表面意义上的“供给”和“需求”之间的关系吗?“供给”在互联网产品思维上可以理解成“提供了哪些功能哪些模块”;而“需求”可以理解成用户对这个产品功能的满意度和需求度有多高。画一张“产品需求和满意度之间的关系”以及“供需关系”图。
对比图如下:
需求和满意度之间的——5种场景
第一种场景:某个功能越做,用户越反感——反向属性
第二种场景:某个功能不做用户满意度低,但是做了就会变高——期望属性
第三种场景:某个功能做了,用户维持低水平基本面的满意度——必备属性
第四种场景:某个功能做了,用户满意度维持到高水平——魅力属性
第五种场景:某个功能做与不做用户都无感——无差异属性
【期望属性】和【魅力属性】容易混淆
这两种属性确实很像,但是【期望属性】还有一个特点,就是可能现阶段还没有,随着功能迭代优化从0-1做下去,用户会越来越满意。而【魅力属性】是现阶段也是没有的,但是你只要一上线,用户一下就很满意了!
基于KANO模型,调查问卷要怎么设计。思路首先列出需求池里准备要做的功能,例如关于“功能A”是否做的问题。
选择题-设计
问:如果产品里面加上了功能A,你的满意度是?请选择
A:不满意 B:无所谓 C:满意 D:理所应当 E:非常满意
我们来分析一下以上5个答案分别对应哪些属性
理所应该 ——必备属性
不满意——反向属性
无所谓——无差异属性
满意——期望属性
非常满意——魅力属性
ps:当然,问题的设置你不仅可以问某个【功能】是否需要存在或者弱化,还可以问某个【功能的设计】如何,体验感觉如何。
在哪个阶段用kano模型更好呢?
在需求分析阶段用kano模型更好有利。这个阶段可以通过调研哪些功能需求需要优先做,哪些需求做还是不做的问题,就可以通过kano模型的问卷来解答
还有一种情况,当你觉得这个功能是反人性的反向属性的功能,可是你的领导想让你来做,你可以针对这个需求来发布一个调查问卷,借他人之口来证明这个需求的必要性。
可行性分析阶段
当到了可行性分析阶段的时候,往往用kano模型就没有特别大的意义了。因为这个阶段主要是视觉交互体验的时候,这个时候可能要用到眼动仪、或其它调研方法了,或者直接埋点看点击数据等方法来评判交互的好坏。
“不满意”三个大字赫赫然
当你看到满屏的“不满意”的时候,你就知道如果没有或者有某个功能,对于用户是有多么大的情绪反应,对于“不满意”的没有上线的功能,一定要上;对于“不满意”的已经上线提供的功能,一定要下掉!!!
还有满屏的“无所谓”,那这种功能的优先级可以排后,等空闲且有必要做的时候再说。优先级最低!!!这种功能是用户还无法感知的功能,也许在未来的时代会变得重要,但是对于目前来说,一定是不重要的!!!!