供需关系——需求与满意度

供需关系的本质到底是什么？是表面意义上的“供给”和“需求”之间的关系吗？“供给”在互联网产品思维上可以理解成“提供了哪些功能哪些模块”；而“需求”可以理解成用户对这个产品功能的满意度和需求度有多高。画一张“产品需求和满意度之间的关系”以及“供需关系”图。

对比图如下：

需求和满意度之间的——5种场景

第一种场景：某个功能越做，用户越反感——反向属性

第二种场景：某个功能不做用户满意度低，但是做了就会变高——期望属性

第三种场景：某个功能做了，用户维持低水平基本面的满意度——必备属性

第四种场景：某个功能做了，用户满意度维持到高水平——魅力属性

第五种场景：某个功能做与不做用户都无感——无差异属性

【期望属性】和【魅力属性】容易混淆

这两种属性确实很像，但是【期望属性】还有一个特点，就是可能现阶段还没有，随着功能迭代优化从0-1做下去，用户会越来越满意。而【魅力属性】是现阶段也是没有的，但是你只要一上线，用户一下就很满意了！

基于KANO模型，调查问卷要怎么设计。思路首先列出需求池里准备要做的功能，例如关于“功能A”是否做的问题。

选择题-设计

问：如果产品里面加上了功能A，你的满意度是？请选择

A：不满意 B：无所谓 C：满意 D：理所应当 E：非常满意

我们来分析一下以上5个答案分别对应哪些属性

理所应该 ——必备属性

不满意——反向属性

无所谓——无差异属性

满意——期望属性

非常满意——魅力属性

ps：当然，问题的设置你不仅可以问某个【功能】是否需要存在或者弱化，还可以问某个【功能的设计】如何，体验感觉如何。

在哪个阶段用kano模型更好呢？

在需求分析阶段用kano模型更好有利。这个阶段可以通过调研哪些功能需求需要优先做，哪些需求做还是不做的问题，就可以通过kano模型的问卷来解答

还有一种情况，当你觉得这个功能是反人性的反向属性的功能，可是你的领导想让你来做，你可以针对这个需求来发布一个调查问卷，借他人之口来证明这个需求的必要性。

可行性分析阶段

当到了可行性分析阶段的时候，往往用kano模型就没有特别大的意义了。因为这个阶段主要是视觉交互体验的时候，这个时候可能要用到眼动仪、或其它调研方法了，或者直接埋点看点击数据等方法来评判交互的好坏。

“不满意”三个大字赫赫然

当你看到满屏的“不满意”的时候，你就知道如果没有或者有某个功能，对于用户是有多么大的情绪反应，对于“不满意”的没有上线的功能，一定要上；对于“不满意”的已经上线提供的功能，一定要下掉！！！

还有满屏的“无所谓”，那这种功能的优先级可以排后，等空闲且有必要做的时候再说。优先级最低！！！这种功能是用户还无法感知的功能，也许在未来的时代会变得重要，但是对于目前来说，一定是不重要的！！！！