企业官网建设流程全解析

做需求分析这么多年，我最大的感受是：需求池里的需求不是不够多，而是吵不清楚。有人按用户投票排序，有人按开发成本拍板，更有人直接拿竞品功能清单当需求池，每个人都有道理，最后出来的优先级却经常被用户打脸。真正让我把需求分门别类想明白的，是 Kano 模型。这个模型不是用来给需求打分排名的，而是帮你先回答一个更基础的问题：不同需求在用户心中的价值，到底属于哪个类别。把这层分清楚，后面再做优先级排序，方向才能立得住。

这篇文章不打算复述教科书。我想从实际使用的角度，把模型框架、问卷设计、数据判读、案例复盘以及常见误区都摊开讲。适合的产品经理、需求分析师、项目经理，还有需要自己做功能取舍的独立开发者，应该都能从中找到可以立刻拿去用的东西。

1. Kano模型到底在解决什么？从一场需求优先级争论说起

1.1 常见需求排序方法为什么失灵

很多团队在排需求时，习惯性用这几招：用户呼声最高就做、问卷投票靠前就做、老板拍板就做、竞品有而我们没有就做。这些做法有一个共同的隐蔽假设：需求对用户满意度的影响，是一条单调上升的直线——做得越多越好，用户越满意；缺得越多越惨，用户越不满。

但真实情况远不是这样。比如手机里的手电筒功能，现在的手机没几个人会为一个手电筒功能去换品牌，甚至很多系统里默认功能都有它。可是如果哪一天系统更新后手电筒打不开了，你会非常恼火，觉得这个系统烂透了。反过来，手电筒做得再好、能变颜色能闪灯，也基本不会成为你购买手机的决定性理由。

这就是问题所在。像"手电筒"这类需求，做得差是灾难，做得好却没人感谢。它和"处理器性能更强""屏幕更清晰"完全是两种逻辑：后者是真的做得越好越满意，前者只是"别给我掉链子"。

所以常规的单调排序思路，从一开始就把需求的性质搞混了。把不同性质的需求放在同一把尺子上量，当然会吵个不停。

1.2 Kano模型的回答：把满意度拆成两个独立的维度

上世纪八十年代，质量管理学界一位学者在分析"用户满意"和"用户不满意"这两个概念时注意到一件事：它们并不是一根轴的两端。让用户觉得"满意"的因素，和防止用户"不满意"的因素，很可能是两套不同的东西。

这个观察后来发展成了 Kano 模型。它的核心是采用二维认知：一维是"功能实现程度"——做还是没做、做得好还是差；另一维是"用户的主观感受"——是惊喜、是理所当然，还是无所谓。把这两个维度组合起来，需求就不再是一条线上的高和低，而是分成了几种性质完全不同的类别。

用生活化的比喻来说：去酒店住一晚，房间里有毛巾是基本要求，你几乎不会因为"有毛巾"而表扬酒店；但如果没有毛巾，你立刻会给出差评。而前台送了一句"生日快乐"或者免费升级了房型，你会心情大好，甚至愿意拍照发朋友圈。可就算酒店不送这声祝福，你也不会因此生气。毛巾和生日祝福，都属于需求，但它们的价值逻辑天差地别。

1.3 引入Kano模型之后，团队工作流发生了什么变化

我是在一次功能取舍失败后，才正式把 Kano 模型引到团队的。那次我们花大精力做了一个用户调研中"呼声很高"的可视化配置面板，上线后数据却难看得很。后来回访才发现，真实用户只是嘴上觉得"这个功能听起来不错"，实际使用中他们根本不想花时间配置，甚至有用户觉得这功能把界面搞复杂了。

引入 Kano 模型之后，团队的需求梳理流程多了一个前置步骤：在谈排期之前，先做需求分类。分类完，再谈哪个优先。这个前置步骤看起来不起眼，但带来了两个明显变化：第一，争论的对象从"我觉得这个重要"变成了"我们拿数据看它的属性是什么"；第二，不再有人拿"竞品有所以我们必须有"来说服团队——竞品有的功能，可能是对方的基本型需求，也可能是对方的兴奋型需求，照抄之前必须先判断它属于哪一类。

2. 五类需求的底层逻辑：为什么同一功能在不同人眼里天差地别

Kano 模型把需求分成五类。理解这五类内部的血肉关系，比死记硬背定义重要得多。

2.1 基本型需求：做好是应该，做砸是灾难

基本型需求，又称必备质量。它的典型特征表现为不对称：用户默认你有这个功能，从不对它表示满意；一旦缺失或者做砸了，用户的不满情绪会非常高。

最典型的是电商平台的订单支付流程。用户不会因为你支付时能正常扣款而特意写好评，但如果支付按钮点了没反应，或者扣了钱订单没生成，用户第一反应就是"这平台太不靠谱了"。这种需求不是你的亮点，而是你的入场券。连基本需求都没做到，用户连谈体验的资格都不给你。

识别基本型需求的标志：用户很少在访谈中说"我希望订单能正常支付"，他们默认这是理所当然的事。反而是当一个新平台缺少这个能力时，老用户会用"连这都没有"来评价。在做需求分析时，基本型需求的优先级不是"要不要做"，而是"必须做好"。它是负数，不做是负分，做了也只是从负分回到零分。

2.2 期望型需求：一分投入一分回报

期望型需求，又称一维质量。它的逻辑是最符合直觉的：做得越多、越好，用户满意度就越高；做得越差、越少，用户满意度就越低。功能和满意度之间呈明显的线性关系。

比如外卖App的配送时间预估。预估准确，用户觉得好用；预估偏差很大，用户就烦躁。这类需求的用户表达也比较主动，访谈时他们会明确说"我希望把配送时间预估做得更准一些"。

期望型需求通常是我们说的"核心需求池"主力。它适合投入资源做持续优化，因为每一分投入都能换来感知明显的满意度提升。但也正因如此，这个领域往往是竞争最激烈的——你能做，对手也能做，最后大家的期望型需求都卷成了标配，渐渐滑向基本型需求。

2.3 兴奋型需求：意料之外的好感

兴奋型需求，又称魅力质量。它的特点是：用户没有期待、不会主动提、做了之后却会带来强烈的积极反馈；不做也不会导致不满。

我印象很深的一个例子是某些支付工具的年度账单。用户没有哪个人会说"我希望年底App给我一份个人账单"，但当这份账单以精致的H5页面呈现出来时，用户会在社交平台主动传播。这就是兴奋型需求的典型表现——创造超出预期的体验，并且自带传播力。

做需求分析时，兴奋型需求容易被忽视，因为它藏在用户的"未表达需求"里。它往往不是靠问卷问出来的，而是靠对用户场景的洞察和产品创意"设计"出来的。识别兴奋型需求的判断标准是：如果功能上线后，用户明显表现出惊喜和主动分享的意愿，那它大概率属于这一类。

需要注意，兴奋型需求有一个残酷的宿命：它会随时间衰减。第一次见到人脸识别支付觉得酷炫，用久了之后就成了"这不就应该有吗"。这也是需求分析不能一劳永逸的原因。

2.4 无差异需求与反向需求：钱要花在刀刃上

无差异需求指无论做不做、做得好不好，用户都不太在意。这类需求最容易在"拍脑袋加功能"的过程中混进需求池。比如某些工具类App加了积分商城，用户是来完成任务或查阅信息的，对积分完全无感，功能上线后淹没无声。

反向需求则更要小心，它是"做了反而让用户不满"的需求。反向需求往往和一部分用户的价值认知相冲突。比如，一个以极简为卖点的应用，如果强行增加社区互动模块、消息红点、直播入口，一部分核心用户会产生强烈反感："当初用你就是为了清净，你现在整这些。"

识别无差异和反向需求，最有效的办法是看数据：功能上线后使用率极低、负面反馈集中在某一点上，就要及时做减法。需求分析不仅要决定做什么，还要决定不做什么。

2.5 需求是会迁移的：从兴奋型到基本型的宿命

五类需求不是静止的标签。同一个人在不同阶段，对同一类功能的态度会变化。

最典型的是手机指纹解锁。刚出的时候，它是明显的兴奋型需求："哇，按一下就能解锁"，很多人因此换手机。过了一两年，它成了期望型需求：新手机要是没有指纹解锁，用户会觉得缺失了什么。再往后，它变成了基本型需求：两千元以上的手机没有指纹解锁，都不好意思上架。

做需求分析时必须意识到，今天你辛苦做的兴奋型亮点，很可能在一年后只是用户眼中的标配。这意味着两点：第一，不能把兴奋型需求一劳永逸地当成"锦上添花"；第二，基本型需求的维护成本是在持续上升的，今天你在某个需求上前瞻性地投入，可能换来明天的入场券。

3. 问卷设计与数据判读：Kano模型真正落地的地方

理论讲完，关键是实操。Kano 模型的标准做法是通过一对配对问题来完成需求分类。

3.1 双向问题的设计逻辑：同一个功能既要问"有"也要问"没有"

Kano 问卷的核心设计是：对同一个功能，分别询问"如果提供了这个功能，你的感受是？"和"如果没有提供这个功能，你的感受是？"两个配对问题。

每个问题的选项不是传统的"非常满意/满意/一般/不满意"，而是五个带具体含义的选项：

• 满意：我觉得这样很好，是我期望中的
• 理应如此：本来就该这样，没什么特别的
• 无所谓：有没有我都行
• 可以忍受：没有虽然难受，但还算不上不满足
• 不满意：有了或没了都让我很不舒服

比如问"如果产品提供网页剪藏功能"：

• 提供时你的感受？满意 / 理应如此 / 无所谓 / 可以忍受 / 不满意
• 不提供时你的感受？满意 / 理应如此 / 无所谓 / 可以忍受 / 不满意

通过这正反两个答案的组合，就能把功能分类到 M/O/A/I/R/Q 中。设计问卷时有个小技巧：问题要尽量贴近用户可理解的具体场景。不要说"如果产品引入AI能力"，而要说"如果笔记能自动生成内容摘要"。用户对抽象概念的回答往往不靠谱，对具体场景的回答才相对真实。

3.2 分类判定表与Q类型处理的细节

两个问题的五个选项组合出 25 种情况，采用以下判定表进行分类。这张表是 Kano 模型落地的关键工具：

表中字母的含义：

• M（基本型需求）：不提供时非常不满，提供时觉得理所当然
• O（期望型需求）：提供时满意，不提供时不满
• A（兴奋型需求）：提供时满意，不提供时不不满
• I（无差异需求）：提供不提供都无所谓
• R（反向需求）：提供后用户反而更不满
• Q（可疑结果）：出现了矛盾回答，需要特别留意

实际数据处理时，Q 是最容易忽略却又很重要的信号。如果某道题的 Q 比例偏高，通常说明题目表述误导了用户，或者这批用户根本没理解功能概念，应剔除此题或回访确认。Q 值不能简单地归为无效，它往往暴露了问卷设计本身的缺陷。

3.3 样本清洗和常见无效数据处理

Kano 问卷里最常见的无效情况是"全选理应如此"和"全选无所谓"。这种作答模式通常意味着用户对功能无感，或没有认真作答。我的处理原则是：

• 单张问卷 Q 类答案超过 20% 时，整份问卷标记为可疑。
• 对关键功能，最少回收 30 份以上有效样本再下结论；整体项目建议不低于 60 份，涉及用户分层时每层 30 份保底。
• R 类占比高的功能，优先看分层数据：很可能是一群用户喜欢、另一群用户反感，合并统计会互相抵消。

样本清洗的目的不是把数据刷得好看，而是还原用户的真实态度。如果问卷设计本身让用户困惑，那清洗多少份都是舍本逐末。

3.4 什么时候不要用Kano问卷

Kano 模型不是万能工具。有两类场景我基本不用：

第一类，用户完全没有认知的突破性功能。你问一个从未用过 AI 辅助功能的普通用户"如果提供AI写文案功能你满意吗"，他的回答极不稳定，因为他无法在脑中模拟真实使用感受。此时更适合的做法是先做原型、概念测试或可用性测试，让用户实际体验后再做问卷。

第二类，强合规或后台类需求。有些需求比如账号注销、隐私协议、后台日志系统，它们是部分基本型需求或合规需求，用户会填问卷但不具备真实的情绪反应。这类需求直接进入开发清单即可，无需走 Kano 分类流程。

4. Better-Worse系数与优先级排序：如何把分类变成决策

分出了 M、O、A、I，不等于能直接排排期。同一个类别内部还有强度差异：同样是兴奋型，一个功能让 60% 的人惊喜，另一个只让 15% 的人惊喜，处理方式完全不同。这时候就需要用 Better-Worse 系数来量化。

4.1 为什么单一分类不够，还需要系数

Kano 分类是定性标签，Better-Worse 则是把每个功能的分类数据压缩成两个数字，方便横向比较。

• Better 系数（满意度提升影响），计算公式为：

Better = (A + O) / (A + O + M + I)

它表示如果提供了这个功能，用户满意度提升的可能性。Better 值越高，说明这个功能越有潜力成为用户的兴奋点或期望点。

• Worse 系数（消除不满影响），计算公式为：

Worse = (O + M) / (A + O + M + I) * (-1)

它表示如果不提供这个功能，用户满意度下降的幅度。取负值只是为了表达"缺失时的负面影响"这个语义。实际绘图或比较时，通常会看绝对值，值越大说明缺失越不可接受。

需要注意，公式的分母采用 A+O+M+I，R 和 Q 不计入。如果统计口径不同，报告里一定要注明，否则横向对比时会产生误导。

4.2 一个完整计算示例

假设对"网页剪藏"功能，回收有效分类数据为：A=45，O=32，M=18，I=20，R=6，Q=5。

Better = (45 + 32) / (45 + 32 + 18 + 20) = 77 / 115 ≈ 0.67

Worse = (32 + 18) / 115 ≈ 0.43

这说明"网页剪藏"既存在显著提升满意度的潜力（Better 高），缺失时也会引发不少不满（Worse 中等偏高）。放在优先序列里，它属于值得投入的功能，但可能不是那种"不做就完蛋"的基础配置。

为了对比，再看一个"主题皮肤"功能，假设数据为 A=8，O=10，M=4，I=60，则：

Better = 18 / 82 ≈ 0.22，Worse = 14 / 82 ≈ 0.17

两个系数都低，明显属于无差异需求。它的优先级应当垫底，即使开发成本很低，也不是当务之急。

4.3 四象限思维：把数字变成排序

把每个功能的（Worse 绝对值，Better）标到一张图上，可以形成经典的优先级四象限：

• 第一象限（高 Better 高 Worse）：优先做。这些既是用户在意缺失的功能，又能带来明显满意度提升，一般是核心期望型需求。
• 第二象限（高 Better 低 Worse）：做亮点。它们是用户会感到惊喜的兴奋型需求，适合作为差异化特色，但要注意成本勿过度投入。
• 第三象限（低 Better 高 Worse）：必须做。它们是基本型需求，不做会挨骂，做了也不会有大功劳。这类需求要排在前面，但不用追求超预期，做扎实即可。
• 第四象限（低 Better 低 Worse）：不做或缓做。它们是无差异需求，投入产出比最低，砍掉也不可惜。

在实际使用中，我不能只看绝对坐标。我会把四个象限按总数量的中位数或均值把高、低切出来——这样在高需求爆炸的项目里，至少不会出现所有功能堆在第一象限的僵局。

5. 一次完整的Kano分析实战复现：某笔记工具的剪藏功能取舍

理论、公式都讲完了，用一次真实处理过的项目流程来展示完整链路。当时我在做一个笔记工具的需求梳理，那个项目让我对 Kano 模型的实战价值印象非常深刻。

5.1 背景：这个功能让开发团队分裂

背景很简单：用户访谈中有好几个用户提到"网页剪藏"功能。希望把网页内容保存进笔记。开发者内部对这个需求出现了截然不同的态度。一部分人认为这是笔记用户的高频刚需，必须尽快做。另一部分人则认为，现在浏览器自带的收藏夹足够用，花大量精力做剪藏是自嗨。

我发现两边都对，但从需求类别出发的话，关键其实是先回答：对目标用户来说，"网页剪藏"到底属于哪类需求？于是决定做一轮 Kano 调研。

5.2 问卷设计：8个功能，正反各一问，126份有效样本

问卷覆盖了 8 个候选需求：

• 网页剪藏
• 多端同步
• 离线阅读
• 标签管理
• 团队协作
• 界面主题皮肤
• AI 自动摘要
• 全文搜索

每个功能都按前文所述的正反成对问题设计。回收后剔除无效问卷：Q 类过多、全同等答案的 9 份；最后有效样本 126 份。受访用户中深度笔记用户（每周使用 4 次以上）约占 55%，轻度用户约 45%。

这里有一个经验：问卷发放渠道要尽量覆盖存量用户，而不是只在社群里放链接。社群里的人通常已经是重度用户，他们对功能的态度比平均用户更极端，样本会系统性偏差。

5.3 分类与系数结果：用一张表说清楚判断过程

对单条数据进行分类后，8 个功能的汇总结果如下：

从主分类能直观看到：多端同步是明显的基本型需求，缺失风险极高；网页剪藏则是典型的兴奋型需求，做了容易出惊喜；界面主题皮肤在样本中明显出现 R 类偏高的现象——相当一部分用户希望界面保持干净，不想换主题。

正是这张表结束了我印象最深的那场争论。说网页剪藏"必须尽快做"的同事，看到 A 类数据后冷静了下来；而说"不必要"的同事，看到 Better 值 0.67 也明白了，这个功能在独立性层面有作为兴奋型亮点去投入的价值。

5.4 随后与用户访谈的交叉验证：表格之外的真相

表格只是数据层面，真正让我确认结论的是后续的补充访谈。对 12 名在问卷中把网页剪藏归为 A 的用户进行访谈时，我发现他们对"网页剪藏"的期待并不真是"当前要用"，而是"经常会碰到想存但忘了存的长文"——他们对保存后的整理、搜索流程更在意。也就是说，剪藏不是孤立功能，它和"全文搜索""标签管理"形成了链条。

团队协作功能的取舍则提醒我：问卷结果不能脱离用户画像。虽然部分用户在问卷里对团队协作选了"满意"，但访谈后发现样本中的活跃用户绝大多数是个人使用场景，团队协作只是"听起来不错"。最终决定把它定位为远期探索功能，不做入当期迭代。

这一次复盘让我深深体会到 Kano 模型的真正价值：它不会告诉你"做什么一定成功"，但它会在团队各执一词时，用数据把需求属性摊开来讨论，大幅压缩争论范围。

6. 越用越觉得需要注意的坑：Kano模型的适用边界和误用场景

账面功夫讲完，最后聊几个实际使用中踩过的坑。

6.1 "理应如此"的歧义让数据失真

Kano 选项里的"理应如此"是一个微妙的词。用户可能在两种完全不同的心理状态下选它：一是他真的觉得功能是本分；二是他对功能无所谓，觉得"你作为产品爱做不做"。前者对应 M 需求，后者其实更接近 I 需求。这两种心理落在同一个选项里，会让结果偏 M 或偏 I，从而影响判断。

我在实践中的缓解办法是在问卷里加一道追问：对每个"理应如此"的回答，紧接着问一句"如果产品没有这个功能，你会生气吗？会去找替代品吗？"用二次确认来区分"本分"和"无所谓"。

6.2 把五类需求当成固定标签，忽略了需求迁移

这是 Kano 模型最需要警惕的理论陷阱。不要以为做完一次分类，需求就一辈子是这个类别。兴奋型需求会因为竞争对手普及而变期望型，期望型会因用户习惯化而变基本型。比如 5G 手机刚出来时是兴奋型，现在很多用户觉得是基本门槛。

所以 Kano 调研不能是一次性的。关键功能最好每年复盘一次。有些团队在重大版本规划前固定跑一次 Kano 调研，把它当作"需求健康检查"，用连续数据观察需求类别的迁移轨迹，这样比只看一次快照更准确。

6.3 合并统计前必须先看用户分层

这是多次踩坑换来的教训。有一次对某工具做 Kano 调研，整体数据把"自定义快捷键"归到了无差异需求。但拆分数据后发现，重度用户里它是高期待的期望型需求，轻度用户里它才是无差异需求。合并统计把两群人完全不同的态度中和了。

从此以后，我在看 Kano 数据前一定会先做分层：按使用频率分、按用户角色分、按付费状态分。如果不同分层的分类结果差异很大，绝不合并汇报，而是单独呈现，再结合商业战略决定优先服务哪部分用户。

6.4 Kano不是拍板工具，是讨论框架

Kano 模型的一个危险倾向是把它当成唯一决策依据。它回答的核心问题是"需求对用户满意度的属性是什么"，不回答"这个功能的技术成本是多少""商业模式是否需要""资源够不够"。

我在团队里给 Kano 定的定位是"需求拆解与优先级讨论的共同语言"。具体排序时，我会把 Kano 分类和 RICE 评分（触达人数、影响程度、信心指数、努力成本）结合：先看 Kano 决定需求类别，再看 RICE 决定排期建议。先分 layer，再谈 sequence，模型之间的配合才叫完整。

6.5 团队落地Kano模型的最小粒度建议

如果你所在团队还没接触过 Kano，我的建议是从小处开始，不要一步到位。先选择 5-8 个待定功能发起一轮小规模问卷，跑通流程，把结论带回到团队里对照实际体验看是否符合直觉。如果结果和团队经验出现明显矛盾，优先排查问卷措辞和样本偏差，而不是急着否定模型。

等团队建立起"需求分五类"的讨论习惯后，再逐步扩大问卷范围，融入分层分析和 Better-Worse 排序。这个过程通常两三轮之后就能形成稳定打法。

最后说一句我自己常提醒团队的话：Kano 模型最宝贵的不是那张分类表，而是它强迫你在排期前先停下来想清楚——这个需求到底是用户的入场券、竞争力，还是惊喜彩蛋。想清楚了，需求池才真正变成可用资产，而不是吵架素材。