卡诺分析实操：判断功能怎样影响满意度

客户门户要新增订单进度、资料导出、邮件提醒和自定义首页，团队很难决定先做哪项。只问“想不想要”，这些功能可能都得高分。但查不到订单状态带来的不满，与少一个个性化首页带来的遗憾，分量未必相同。

卡诺分析（Kano Analysis）通过配对提问，了解一项功能存在与不存在时的感受，判断它怎样影响满意度。它让团队看见基础需求、性能期待和吸引型功能之间的差别，也提醒人们留意无差异与反向关系。

先说清功能，再谈它属于哪类

假设一家设备企业规划客户门户，想了解采购与维护人员对这些功能的期待。研究者不能只写“订单管理更好”，应拆成明确属性，例如“能看到订单当前处理阶段”。

提醒也要讲清条件。“每天通过邮件提醒”与“关键状态变化时可选择提醒”，对用户的影响可能不同。把它们合成一题，分类便无法指导设计。

一项功能一题，不把速度、外观、权限和通知一起打包；“能下载资料”与“下载内容保持最新”也可分别询问。必要时用简单情境或粗糙原型说明，避免宣传语让参与者觉得应该喜欢。

基础需求常被视为理应存在，缺少容易不满；性能需求的表现变化会影响满意程度；吸引型需求能带来额外价值，缺少却未必令人不满意。无差异表示对某些人的满意程度影响不大，反向则提示有人更希望这项功能不存在。

这些类别依赖人和任务，也会随时间变化。采购需要追踪交付，维护人员可能不负责订单，同样的邮件提醒就可能得到不同反应。因此不要给功能贴一个永久标签。

研究者应先选有相关使用经历的人，记录职责与任务。没有经历的人可能只能凭想象作答，应与实际使用者区分。只在最活跃客户群里发问，也不能据此推广到全部客户。

对每项属性，分别询问存在与不存在时的感受，措辞和情境保持一致，只改变这个条件。以“订单状态变化时发送邮件提醒”为教学示例，可以准备：

两题都使用三个选项：“满意”，表示对题目描述的情况感到满意；“没有区别”，表示没有明显影响；“不满意”，表示对题目描述的情况感到不满。另允许“不了解／不适用”，单独记录，不按“没有区别”编码。

参与者在安静接待区回答成对的通用功能情境

下面是三选项的简化教学版，不是标准完整问卷模板。正式研究采用其他量表时，要核对对应规则，不能把不同版本的选项和分类表混用。

查表时，第一题“有功能”的回答对应列，第二题“无功能”的回答对应行，交叉格给出初步类别：

第二题：无该功能时的感受／第一题：有该功能时的感受	满意	没有区别	不满意
满意	待确认	反向	反向
没有区别	吸引型	无差异	反向
不满意	性能型	基础型	待确认

假设参与者甲回答“有提醒时满意、无提醒时没有区别”，对应吸引型；乙回答“有提醒时没有区别、无提醒时不满意”，对应基础型。两人的类别不同，说明提醒对他们的作用可能不同。以上只是演示，不是实际用户结果。

“待确认”不增加一种需求类别。研究者先检查是否误读题目、条件是否一致；仍无法解释，就保留待确认，不强行归类。双方满意和双方不满意这两个格，尤其需要回查。

正式发出前，请相关参与者复述属性、题目和选项。有人把“不提供提醒”理解成系统暂时故障，有人把“没有区别”理解成不知道该选什么，这些都要先修正。

研究者还要检查参与者是否假定了题目没有说明的能力，例如将邮件提醒理解为自动催办。如果含义不一致，先改描述，不应让困惑的回答进入正常分类。

每人每项功能都保存两题答案与配对类别，再按同一功能汇总。待确认、不了解、不适用和缺失分开列。展示比例时写清分母和处理方式，避免悄悄删掉异常答案，或把它们当无差异。

然后检查采购、维护等任务群体的差异。某类回答较多，只能提示本次样本的方向；数量有限或招募范围窄时，不要用精确比例给全部客户定性。

分类能够说明功能为什么不能一视同仁。规划时仍要结合成本、依赖、风险和服务能力，安全、可访问性、必要责任及明确业务约束不能交给满意度投票。