企业官网建设流程全解析

做产品这几年，我越来越认同一个观点：需求分析做得糙，后面所有的努力都是在给错误的方向加班。功能排期排得满满当当，上线后用户却无感，或者刚上线就差评一片，说自己不用了，这种情况太常见了。问题的根源往往不在执行力，而在需求分析环节——你根本没有区分这个需求是“用户嘴上想要的”还是“心里真正需要的”，也没搞清楚这个需求到底能带来多少满意度增量。如果你也有类似的困惑，我建议你把Kano模型这套需求分析方法论认真跑一遍。它不复杂，不玄学，就是一套非常落地的分类和优先级判断工具，适合产品经理、需求分析师、项目经理，也适合独立开发者自己做产品决策。今天我就把这套方法论从原理、问卷设计、数据处理到实际避坑，一次性讲透。

1. 先搞清楚Kano模型到底在解决什么

1.1 一个二维的需求认知框架

传统做需求，我们习惯性地一维思考：这个功能重要，那个功能不重要；用户想要这个，不想要那个。但Kano模型告诉我们，需求和满意度之间根本不是简单的线性关系。它的核心逻辑是：不同类型的需求，对用户满意度的影响路径完全不同。有些需求做了，用户觉得理所当然，不做就炸毛；有些需求做了，用户会很惊喜，不做也没什么抱怨；还有些需求，做不做都无所谓，纯属浪费资源。

这个概念来自一位名叫Kano的质量管理学者在1979年提出的理论，他最早是在产品开发和质量管理场景下研究用户满意度如何受产品特性影响的。后来这套模型被广泛采用到互联网产品、服务设计等领域。我一直觉得它是“被名字耽误的好方法”——听起来像学术名词，其实用起来非常朴素，核心就一句话：帮你判断每个功能在用户心里的“身份”是什么。

有了这个身份判断，你就知道自己手里的需求，到底是保命需求、加分需求、还是自嗨需求。

1.2 五大需求类型：必备、期望、兴奋、无差异、反向

Kano模型把需求分成五类，这是整个方法论的基石。我结合一个实际场景来解释，比如你现在做一个网盘类产品：

第一类是必备型需求，也叫基本型需求、理所当然需求。这类需求是用户的底线，你没做，用户直接走人；你做了，用户也没感觉，因为他们认为这是应该的。网盘的上传下载功能就是典型。用户不会因为你上传速度快就到处夸你，但上传功能要是坏了，客服会被骂惨。

第二类是期望型需求，用户非常在意，你的表现越好，用户满意度越高，做得越差，满意度越低，是线性的。比如文件传输速度、断点续传的稳定性，这类需求做得好是口碑点，做得差是投诉点。

第三类是兴奋型需求，也叫魅力型需求。用户根本没预期，你做了之后他会“哇”一声，惊喜感拉满。比如网盘里的“智能分类”，自动把用户上传的图片按场景、地点归类生成回忆视频，这种需求不做没有负面影响，没人会因为这个骂你，但做了之后容易形成自传播。

第四类是无差异型需求，做与不做对用户满意度几乎零影响。比如网盘的个性化图标皮肤、高级会员标牌样式。这类需求特别容易出现在“功能灵感收集会”上，大家讨论得很热闹，但上线后数据毫无波澜。

第五类是反向型需求，做了反而让用户反感。比如强制引导下载桌面端才能看视频、无休止的会员弹窗、限速提醒连续插屏，都属于这类。

五类需求各有各的脾气，优先级逻辑也完全不同。我需要提醒一点：需求类型是会随时间和市场成熟度发生变化，同一个需求今天可能是兴奋型，两年后就变成必备型了。这种迁移现象是Kano模型最有价值的一个洞察，后文我会专门讲。

2. 从设计问卷到跑出分类：一步步实操

2.1 成对问题设计：正向和反向缺一不可

Kano模型的问卷设计是整个流程里最体现功力的地方。它不是简单地问“你需不需要某个功能”，而是围绕同一个功能问两个方向的问题：如果产品具备这个功能，你的感受是什么；如果产品不具备这个功能，你的感受是什么。

这两个问题必须一一配对出现，这是精髓。举个我实际用过的例子，假设你在调研“自动备份手机相册”这个功能：

正向问题：如果产品提供“自动备份手机相册”功能，你会觉得？ 反向问题：如果产品不提供“自动备份手机相册”功能，你会觉得？

选项方面，不要用常规的“满意、一般、不满意”这种满意度量表，Kano模型有自己的专属五级表述，分别是：我喜欢这样、它理应如此、我无所谓、我可以忍受、我不喜欢这样。这五个选项是有讲究的，它测量的不是满意度体验的好坏，而是用户的预期落差感。必须原样使用，不要自作主张替换词汇。

设计问卷时有几个老坑必须提前说：首先，正反两个问题不要隔太远，尽量放在同一屏或者连续几题，否则用户的评价维度会漂移。其次，不要只对单独功能这样问，要覆盖你的候选功能池。我一贯的做法是一次问卷放10到15个功能点，每个功能两问，总共20到30道题，答题时间控制在8到10分钟以内，否则用户填到最后全是随手选，数据全废。

2.2 发放对象与样本量控制

Kano模型对样本量的要求不低，但也没有传说中那么高不可攀。从我实操的经验来看，单个用户群样本至少要有50到100份有效问卷，低于30份数据波动会很大，分类结果经常会出现同一归属来回跳的情况。

更关键的是样本配额，理想的调研对象应该是当前目标用户、轻度用户、重度用户、竞品用户各占一定比例。很多人容易犯的错是只找一批最活跃的老用户来填，结果数据里“兴奋型需求”的比例虚高。因为老用户对产品已经有了感情和适应度，他们会把很多功能理解成“理应如此”或者“很喜欢”，这会导致你的分类失真。

发放渠道也要注意，尽量用产品内触达加社群结合的方式。纯社群拿回来的样本容易偏年轻化，纯产品内弹窗拿回来的样本又容易过度集中在高频用户身上。两者互为补充比较好。

3. 一张评估表，把答案变成判断

3.1 如何把两个答案映射到需求类别

问卷回收之后，关键一步来了：数据处理。你要把每个用户对每个功能的正向回答和反向回答组合到一起，对照Kano评估表，确定这个功能属于哪个类型。下表就是标准的评估分类表，这里的“M”代表必备型，“O”代表期望型，“A”代表兴奋型，“I”代表无差异型，“R”代表反向型，“Q”代表可疑结果。

这表怎么读懂？对照两个坐标就能锁定结果。比如用户对“自动备份相册”的正向回答是“我喜欢”，反向回答是“我可以忍受”，查表交叉就是A，也就是兴奋型需求，说明普通用户觉得这个功能属于超预期亮点。再比如正向回答是“理应如此”，反向回答是“我不喜欢”，查到的是M，也就是必备型需求，说明用户觉得这个功能就是产品的基本义务，不做就要翻脸。

看到“Q”和“R”也要心里有数。Q表示可疑结果，一般是用户胡乱填的，正反都选“我喜欢”之类的自相矛盾，这类样本要单独标记出来，不代表任何需求意义。R表示反向结果，说明用户希望遇到相反场景才满意，这种情况下可以考虑剔除或者单独分析。

我还想强调一点：不要把AA、O、M的频次表简单相加。比如某功能统计下来，A有20人、O有15人、M有10人，并不能直接说它是兴奋型。正确的做法是先看M的占比，再看O的占比，最后才看A的占比。一个功能只要M的比例很高，基本上就是保命功能，哪怕A的绝对数更大也要先让位于M。

3.2 Better-Worse系数：用两个数字量化优先级

光有分类标签还不够，Kano模型还有一个更深层的用途，就是计算Better-Worse系数，把需求的管理从定性推进到定量。这两个系数在行业里也被称为满意度增量和满意度减量，计算公式如下：

Better系数 = (A + O) / (A + O + M + I)，这个值介于0和1之间，越大说明该功能对用户满意度的提升作用越明显。

Worse系数 = -1 * (O + M) / (A + O + M + I)，这个值介于-1和0之间，越接近-1说明该功能缺失时对用户满意度的损害越大。

这里要注意，公式里的A、O、M、I指的都是把这一期问卷所有样本数加总后的数量。分母中去掉了Q和R，因为这两类不属于正常判定范围。

系数算出来后，我会建议按功能维度把这些值录入到一张表里，形成四象限图。横轴是Worse系数的绝对值，纵轴是Better系数，平均水平或者中位数作为分割线，四个象限的含义非常清晰：

• 右上角：Better高、Worse高，属于期望型需求，代表进行优先级最高。
• 左上角：Better高、Worse低，属于兴奋型需求，代表用来打造亮点，锦上添花。
• 右下角：Better低、Worse高，属于必备型需求，代表痛点和刚需，不做就会出问题。
• 左下角：Better低、Worse低，属于无差异型需求，代表可以直接砍掉。

用一个模拟案例来演示一下。某内容社区App候选功能池里有“深色模式”“评论点赞动效”“直播功能”“离线阅读”“个性化推荐”“访客记录”“字体皮肤”这几个点。表单整理后得到的分类结果如下：

这张表一出来，资源分配就很清楚了：首要工作是优化离线阅读，这是刚需；核心发力点是个性化推荐，这是最值得投入竞争的区间；深色模式和直播功能可以做，但要看资源余量；其余的直接砍掉都不带犹豫的。

4. 需求分类之后，如何制定科学的需求策略

4.1 分清轻重缓急：必备型优先、期望型提效、兴奋型超预期

分类不是目的，分类后的行动才见真章。我的排序逻辑一般是，必备型需求优先级永远排第一，这些是用户说不出口但你做了他会觉得理所当然、不做他会咬牙切齿的。如果你发现自家必备型需求还有硬伤，比如网盘的上传不稳定、视频播放卡顿，那无论如何先把这些问题修完，再谈其他花活。必备需求做扎实了目标不是好评，而是“零差评”。

其次是期望型需求，这是产品之间真正拉开差距的地方。这类需求与满意度呈正相关关系，投入越大收益越大。资源充足时，期望型需求做深做透能带来非常直接的体验提升，成为竞争优势。

然后是兴奋型需求，这属于“杠杆点”。它不用做很多，但一旦做对就能引发口碑效应。要控制投入的量级，毕竟兴奋型需求一旦被用户习惯，很快就会降级成期望型甚至必备型，你要持续寻找新的兴奋点。

最后是无差异型和反向型。这两类要严格控制投入，尽量不要做。反向型需求尤其危险，比如强制点赞引导、诱导分享，短期数据好看但长期一定会伤用户情绪。

4.2 用Kano结果指导迭代排期和版本规划

把Kano模型的分析结果结合到版本规划里，我有一个很顺手的操作模式：由必备型需求兜底，保证单版本的体验底线；用期望型需求作为主线，锁定本版本的核心突破方向；然后额外挑一到两个兴奋型需求作为彩蛋，给用户制造惊喜感。一个版本如果能把这三者均匀配齐，在数据表现和用户口碑上会比较平衡。

举个做某跨平台工具类产品的例子，我们当时手头有大量用户反馈，看起来都是需求，但没法全部做。后来组织了30人次的定向访谈，又线上回收了上百份有效问卷，用Kano跑了一遍分析。有一组需求一直有用户在各种渠道提，实际上分类下来是I型无差异，频率高不代表重要性高。而真正高频反馈“导出功能要稳定”这个点，表面看起来平平无奇，分类结果是M型。策略一下子清晰了：导出问题优先修，稳定大于一切；被提了多次的花哨功能统统排在低优先级。

关键要明白，Kano模型不是用来直接决定“先做什么功能”，而是用来判断“哪些功能不该做什么、哪些功能该做到什么程度”。它和前期的用户访谈、数据分析形成互补。把Kano结论和业务目标结合，才能出一份支撑版本排期的完整需求分析报告。

5. 实操中最容易踩的坑与排查技巧

5.1 分类跳变：换个样本结果就变

我在实操中遇到最多的就是分类不稳定。上午回收完数据O型，晚上多跑十几个样本就变A型了。这个问题的根本原因是样本量太小或样本结构不均衡。排查思路也很直接：先拆解对比重度和轻度的用户群体，看分类是否一致；如果重度用户标A、轻度用户标I，那就说明这个功能存在明显的用户分层，不能一概而论。

这时候可以把数据拆开分别跑一次，不要合并处理。做内容社区和学生群体的功能，经常出现这种新旧用户理解差异很大的情况，老用户觉得某些功能理所当然，新用户却觉得是惊喜点。

5.2 用户答题时无法理解正反向场景怎么办

有些用户填问卷时会卡在“如果具备”和“如果不具备”这种反事实语境里。尤其是在功能体验还比较抽象时，问题就更明显。这时候光靠文字描述是不够的，最好配上功能原型图或界面示意。用户看到具象化的画面之后，才能做出有效的选项判断。

我早期跑一组调研时吃过亏，问卷里写了“全局手势返回”这个还没有界面的功能，用户基本都选了“我喜欢”，直接把它归成A型兴奋需求了。后来加了功能演示录屏，重新回收后才发现很多用户在没有演示时根本理解不了，实际归属变成了I型。这个教训我很深。

5.3 Q型结果占比过高，到底算不算数据异常

如果你的Kano问卷里Q型（可疑结果）占比超过10%到15%，那基本可以判断问卷有问题。常见原因有三个：题目太多导致疲劳乱答，正反问题配对太小用户没看到，或者题面语义有歧义。我的建议是优化格式，把正反问题视觉上用同色底纹合并；再给每个功能点配一句使用场景说明；最后看单独用户答题时长，低于平均作答时长的可以选择性剔除。

还有一个容易被忽略的细节：反向型R的结果不一定总是要删掉，有时它是在提示这个功能不适合目标用户群，也许该功能适合另一类细分人群。可以把这个发现记入洞察报告，作为后续用户分层的线索。

5.4 警惕“需求迁移”：不要吃老本

这一条值得单独拿出来强调，因为几乎所有团队都会在这里栽跟头。Kano模型分析出的分类结果是有时效性的。你今天测出来的兴奋型需求，过半年很可能就成了期望型需求；期望型需求过个一两年，也会慢慢往必备型迁移。

最简单的例子就是扫码支付的出现，当年是让人“哇”的兴奋型功能，如今在餐饮零售场景里已经成了必备型需求，没扫码工具商家反而会感到不便。再比如深色模式，前几年做出来是加分项，现在很多用户使用App的第一反应是找有没有深色模式，这已经倾向于必备型了。所以你上一次调研得到的结论只能作为分版本的参考，不要想着做一次管一年。

我建议每两个季度或者一个大版本前重新滚动一次Kano问卷。不用每次都发全量的大问卷，可以挑本轮涉及调整的核心功能点做小样本复测，反复滚动之后，你会形成一条属于自己的“需求迁徙曲线”，这对中期产品规划非常有价值。

5.5 将Kano模型与常见优先级排序方法互补

Kano模型不是包治百病，它也有自己的盲区。它不回答商业价值问题，不告诉你哪个功能能带来收入，也不考虑开发成本和维护成本。所以我常用的组合打法是这样的：

先用Kano模型把需求分类，筛掉无差异型之后，再对保留下来的需求做带权重的优先级评估。评估维度参考：用户影响面、营收潜力、开发成本、数据埋点难度、风险敞口。这本质上就是结合RICE（Reach、Impact、Confidence、Effort）或者加权排序方法去使用。

从这几年的实际体验来看，只用Kano模型会错失业务维度的判断，但完全抛弃Kano模型去纯按数据看板一堆指标来排期，也容易脱离真实用户心理。两者配合使用，效果远好于单一方法。

6. Kano模型的适用边界与面向未来的扩展

6.1 这款模型不太适合哪些场景

Kano模型在需求分析体系里地位很高，但有些场景确实不适合硬套。比如在全新的探索型产品里，目标用户画像不清晰，甚至用户自己都不知道要什么，问卷回收后的分类很容易全部堆在“无差异”或“兴奋”上，没有决策意义。这时候更适合的做法是先做深度访谈或者观察用户，而不是直接上问卷。

再比如偏底层平台或者B端企业内部系统，用户根本没有选择权，或者需求几乎全部属于必备型，Kano的兴奋型维度基本失效。这种场景下，我更推荐用业务目标拆解法或者任务分析去代替。

我的判断标准是，Kano模型最适合用在用户选择权充分、产品竞争充分、需求功能点比较具体的场景，同一产品分类越能拉开差距，这套方法论发挥的空间就越大。

6.2 结合用户体验地图做全流程需求清单

把Kano模型和数据体验地图结合起来，是我现在非常推荐的一种进阶用法。你先把用户从认知、下载、首次使用、日常使用到付费转化的一条完整路径画出来，在每个触点列出候选功能。然后给每一个触点下的功能各跑一轮Kano数据，这样你看到的不再是单一功能孤零零的分类，而是用户在整条路径上不同阶段的体验预期曲线。

举个例子，注册流程里的“第三方账号一键登录”基本是必备型；首次使用时的“新人引导进度条”可能是兴奋型；日常使用中的“数据导出”可能是期望型；付费环节的“发票申请”是必备型。动手做全流程的Kano分析，你会更容易判断自己的产品体验是否“上松下紧”——往往是获客环节特别顺，用户一进入正式使用环节就卡住，这种断裂感从单点功能上完全看不出来，像拆解拼图一样全部铺开才能看清。

6.3 持续建立一个动态的需求观

最后，我想聊聊Kano模型带给我最大的思维方式改变。以前我做需求分析，习惯把需求当成静态的任务清单，今天接收一批，排进迭代，做完清空。但Kano模型天生自带动态视角，它逼着你去想，这个需求在用户心里的位置何时会改变、什么条件下会改变。用户的需求观始终处于流动中，今天用户觉得惊喜的，明天会变得平淡，后天会变成理所当然。如果你能持续捕捉这种迁移信号，需求分析就从一个节点的行为，变成了一个连续观察的过程。

把这套“信息素养”变成团队共识后，你会发现自己不再那么容易被用户单次的反馈带偏，也不再因为竞品做了个新功能就焦虑。竞争中的“亮点功能”越来越多，但用户满意的关键，始终是那些不会说话的基础体验。

我个人在实际操作中的一个深刻体会是，Kano模型最有价值的产出并不是那个分类结果表，而是它逼着整个产品团队在二维空间里重新思考需求的“身份”，彻底摒弃那种“别人有我也要有”的无脑逻辑。每当我看到团队因为一份Kano数据放弃一个看起来“很不错”但实际属于无差异的炫技功能时，我都觉得这套方法论的投入完全值得。如果你正准备引入需求分析法，又不想搞得太重，我建议你从小范围启动，哪怕只有8到10个功能点、一百份有效问卷也行，关键是先把这份“分类视角”建立起来。等下一次需求评审会再出现争吵时，你会自然地问出那句极具力量的话：这个需求，在用户心里到底是必备、期望，还是兴奋？