用户研究：场景驱动的需求定义实战方法

可视化演示

动态演示用户研究的核心机制，通过入门/进阶/实战/优化四种模式展示关键概念与交互流程。

场景驱动概念

小明是位美食评论员，早年推餐厅全靠读者问卷。读者留言想吃辣，他就推荐重庆火锅，结果评论区炸了锅：有人嫌太辣，有人说不够味，还有人问有没有“不辣的辣”。小明委屈坏了：你们明明说要吃辣啊？后来他不再发问卷，而是揣着笔记本蹲在餐厅门口，看真食客怎么点菜、怎么动筷、剩了什么菜。这才发现：加班午餐的“想吃辣”是提神驱困，朋友聚餐的“想吃辣”是热闹分享，感冒初愈的“想吃辣”只是开胃。同一个“辣”字，放进不同场景，根本是三件完全不同的事。

AI 产品经理每天都在遭遇小明的尴尬。问卷里用户勾选“希望体验更智能”，但这个愿望放进“通勤地铁单手刷手机”和“深夜卧室躺在被窝”两个场景，含义截然不同。用户说出口的是想象中的自己，真实需求藏在具体场景的行为里。场景驱动需求定义，就是不再把用户的回答直接当成需求，而是回到行为发生的现场，用“场景”这个放大镜重新解读每一个动作。

在用户研究中，场景（Scenario）指用户在特定时间、特定地点、特定情绪状态下，为达成某个目标而展开行动的完整过程。场景驱动可以写成一条简洁的公式：需求等于场景函数作用于“用户、行为、目标”三个变量。同一个“反复滑动商品页”行为，在通勤场景里解读为“想快速找到目标商品”，在睡前场景里解读为“随便逛逛想种草”，在大促场景里则解读为“犹豫比价想抄底”。用户、行为、目标三个变量本身不足以定义需求，真正起决定作用的是那个“场景函数”。

$$\displaystyle \text{需求} = f_{\text{场景}}(\text{用户}, \text{行为}, \text{目标})$$

1. 用户（行动主体）：需求总是属于某个具体的人，先明确“谁”在行动。

$$\text{用户}$$

2. 行为（表面动作）：用户在场景中实际做了什么，是可观察到的行为证据。

$$\text{行为}$$

3. 目标（深层意图）：用户做这件事想达成什么，通常隐藏在行为背后。

$$\text{目标}$$

4. 场景函数（解释框架）：把行为与目标放进情境中重新翻译，输出真实需求。

$$f_{\text{场景}}(\text{用户}, \text{行为}, \text{目标}) \rightarrow \text{需求}$$

后来小明的推荐语全变了，先写“适合周五加班后一个人吃”，再写“适合朋友聚会人多热闹”。读者照着场景选，居然很少再翻车。场景驱动让产品经理也拥有了同样的“换位镜头”：不再问用户想要什么，而是看见用户在什么情境下卡住了。需求，就藏在那一个个“卡住”的瞬间里。

场景框架搭建

探店之前，小明先摊开城市地图画圈：写字楼片区是工作日午餐圈，老小区外围是宵夜圈，商场顶楼是周末聚餐圈。每个圈里标注最常见的食客类型。这张“美食地图”让他的探店不是随机撞运气，而是按图索骥。产品研究也要先搭地图，这张地图就是场景框架。

场景框架的起点是用户画像。小明知道“加班码农”“全职宝妈”“退休大爷”的吃饭逻辑完全不同，产品也一样：先界定核心用户是通勤白领还是小镇青年，他们的作息、设备、情绪状态决定了场景的上限。画像不是年龄收入标签墙，而是“这个人在哪些时刻会想起产品”的行动主体。

有了画像之后，拆解场景要素：时间（工作日/周末、早/中/晚）、地点（家/公司/路上）、设备（手机/电脑/手表）、任务状态（进行中/被打断/刚结束）、情绪（焦虑/放松/急切）。把要素组合成典型场景，例如“通勤地铁上单手刷购物 App”“深夜被窝里刷短视频助眠”。高频、典型、痛点深的场景沉淀进场景池，后续所有研究都从池中取样，保证证据可比。研究覆盖得够不够全面，可以用场景覆盖率来衡量。

$$\displaystyle C_{\text{场景}} = \frac{N_{\text{已覆盖}}}{N_{\text{典型}}}$$

1. 已覆盖场景数：当前场景池中已完成调研或采集场景的数量。

$$N_{\text{已覆盖}}$$

2. 典型场景总数：依据用户画像与要素拆解确定的全部典型场景数量。

$$N_{\text{典型}}$$

3. 场景覆盖率：研究覆盖面大小的量化指标，衡量研究是否全面。

$$C_{\text{场景}}$$

4. 覆盖率应用：覆盖率偏低时补充典型场景研究，避免需求盲区。

$$C_{\text{场景}} < 1 \Rightarrow \text{补充研究}$$

小明的美食地图越画越细，最后变成一本“探店手册”：每个片区、每个时段、每类人群各占一页，每页留白处写满了观察记录。场景池就是产品团队的探店手册，它让需求研究从“这次该问谁”的随机，变成“先查手册再去现场”的章法。

用户行为分析

到了店里，小明从不急着问“好吃吗”，而是坐在角落观察邻桌：谁拿过菜单先翻哪一页、第一道菜多久动筷、最后哪盘剩最多、结账时是否打包。这些动作比任何推荐语都诚实。用户行为分析，就是产品世界里的“邻桌观察法”。

行为数据从哪里来？App 埋点日志、后台点击流、客服对话记录、用户访谈中的行为复盘。关键不在于数据量，而在于数据是否与场景配对——只有记下“在哪个场景、为了什么、做了什么动作”，行为才有解读的坐标。孤零零的一条“点击了搜索”，什么都说明不了。

拿到行为数据后先做两步：一是频次统计，找出每个场景下的高频行为；二是序列分析，还原完整的操作链条。然后结合场景推断动机。比如“加入购物车后离开”，在通勤场景八成是“没时间结算”，在睡前场景则可能是“还想再比一比”。行为是表象，动机才是通向需求的门。高频行为占比的公式如下。

$$\displaystyle P_i = \frac{n_i}{N}$$

1. 某行为出现次数：单个场景下行为 i 被记录到的总次数。

$$n_i$$

2. 全部行为总次数：同一场景下所有类型行为次数之和。

$$N$$

3. 行为占比：行为 i 占该场景总行为的比例，用于识别高频行为。

$$P_i$$

4. 占比的用途：占比越高的行为越值得优先进入动机推断环节。

$$P_i \uparrow \Rightarrow \text{优先推断动机}$$

小明在本子上画“动筷热力图”：哪道菜三分钟内就被伸筷子，哪道菜十分钟没人碰，哪道菜每次都被打包。食客嘴上说“都挺好吃”，热力图却把真相画得明明白白。产品经理手里的行为频次表，就是那幅热力图——数据不会说谎，但前提是你得知道该看什么。

需求发现提炼

观察结束后，小明开始写“菜色笔记”：为什么水煮鱼被吃个精光，毛血旺却剩了半盆？因为食客要的不是“辣”，而是“辣得超过瘾但别让花椒扎嘴”。顾客说不出口的，恰好是动筷节奏里藏着的真相。需求从来不是用户报出的菜名，而是行为留下的线索。

从行为到需求，中间隔着问题。每个场景里，用户为了达成目标都会遇到阻碍：找不到、等太久、输太烦、看不懂。把阻碍翻译成“未满足的期望”，需求就浮出水面。例如“反复滑动找不到想要的商品”，翻译成需求就是“希望快速缩小选择范围”。

需求提炼出来之后，要用规范句式表述，避免“提升体验”“更加智能”这类空话：“在[场景]下，作为[用户]，我希望[行动]，以便[目标]”。同时做场景关联分析：同一个需求如果在两三个典型场景中反复出现，需求置信度就越高；只在单一场景出现时，要重新审视它是真需求还是伪需求。结构化的需求条目可以写成四元组。

$$\displaystyle D = (S, U, M, E)$$

1. 场景 S：需求发生的具体情境，包括时间、地点、环境等要素。

$$S$$

2. 用户 U：需求的行动主体，结合用户画像明确目标角色。

$$U$$

3. 动机 M：用户面临场景阻碍时内心的真实渴望。

$$M$$

4. 期望结果 E：用户希望达成的目标状态，也是需求的验收标准。

$$E$$

小明的菜色笔记最终会沉淀成“招牌菜公式”：什么场景、什么客人、什么渴望、用什么方式满足。产品团队的需求条目也一样——场景、用户、动机、期望结果四个要素齐了，需求才能从“我觉得”升级为“证据表明”。

需求优先级判定

候选招牌菜有二十道，厨房却只有一口锅，先做哪道？小明只看两个数：这道菜被翻牌的频率，以及点过的人会不会成为回头客。需求排优先级也是同一个道理：菜单再长，灶眼有限。

需求清单永远比研发资源长。优先级判定的第一步是统计场景频次：高频场景里的每个需求，每次触发都在影响真实用户体验，解决一次就值回票价。第二步评估用户影响：这个需求解决的是不是核心痛点，改善幅度有多大。

第三步引入战略权重：符合产品当前阶段目标的需求加权计算。KANO 模型提供辅助视角：基础型需求（登录稳定、不崩溃）必须做；期望型需求（搜索结果准）做得越好越满意，应重点做；兴奋型需求（个性化惊喜）可以少量投入做差异化。优先级最高的，通常是“高频场景中的期望型需求”。

$$\displaystyle P_{\text{优先级}} = F_{\text{频次}} \times I_{\text{影响}} \times W_{\text{战略}}$$

1. 场景频次 F：需求所在场景在单位时间内出现的次数，越高越值得做。

$$F_{\text{频次}}$$

2. 用户影响 I：需求满足后对目标用户痛点改善的程度。

$$I_{\text{影响}}$$

3. 战略权重 W：团队根据产品当前方向为该需求设置的权重系数。

$$W_{\text{战略}}$$

4. 优先级得分 P：三者相乘得到排序得分，从高到低排定迭代顺序。

$$\displaystyle P_{\text{优先级}} = F_{\text{频次}} \times I_{\text{影响}} \times W_{\text{战略}}$$

最后，小明的菜单首页只保留三道招牌菜：翻台率最高、回头客最多、毛利最好。产品团队的需求排期表，本质上是同一道算术题——在用户最常光顾的场景里，先把最疼的那个问题解决掉。

实战落地方法

探店观察员的最终产出不是日记，而是给老板的改造建议：把招牌菜放大挂上墙、给常客留一条免排队通道。场景驱动研究也一样，最后要落地成产品方案，而不是停留在厚厚一沓分析报告里。

完整实践流程分四步。第一步制定研究计划：从场景池中挑选 2-3 个关键场景，设计采集方案；第二步执行数据采集：埋点、访谈、实地观察三管齐下；第三步分析提炼：按前文方法收敛出需求条目；第四步验证闭环：用快速原型和小范围测试确认需求真实性，再进入开发。

AI 产品要额外注意场景化训练：模型效果本质上等于“场景适配度”，用通勤场景数据训练出的推荐模型，放到睡前场景必然失灵。因此数据采集要按场景打标签，评估指标要分场景看，需求定义直接决定了模型的场景边界。团队协作上，建议产品经理拉着算法和交互一起进现场，让“场景”成为团队共识语言。

小明把自己的观察法教给餐厅老板，老板从此学会了“第二眼顾客”——不看顾客嘴上说什么，只看他们怎么吃。AI 产品团队掌握场景驱动，同样拥有了这种“第二眼能力”：穿透用户的自述，看见场景里的真实需求。这正是所有好产品共同的起点。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""场景行为分析器: 从行为日志中提炼场景化需求""" from collections import Counter, defaultdict # 模拟用户行为日志: (用户ID, 场景, 时间, 行为类型)# 每一条日志都带着场景标签, 这是场景驱动分析的前提logs = [    ("U01", "通勤", "08:12", "反复滑动"),    ("U01", "通勤", "08:15", "加入购物车"),    ("U01", "睡前", "23:02", "反复滑动"),    ("U01", "睡前", "23:05", "收藏商品"),    ("U02", "通勤", "07:58", "快速滑动"),    ("U02", "囤货", "20:30", "切换商品页"),    ("U02", "囤货", "20:33", "查看历史低价"),    ("U03", "睡前", "22:40", "收藏商品"),    ("U03", "睡前", "22:42", "反复滑动"),] # 行为模式到场景化需求的映射规则RULE_MAP = {    "反复滑动": "需要减少决策成本",    "快速滑动": "需要快速定位信息",    "查看历史低价": "需要价格安全感",    "收藏商品": "需要种草清单",    "切换商品页": "需要横向比价",    "加入购物车": "需要集中结算",}  def analyze(logs):    """按场景聚合高频行为, 并映射出场景化需求"""    result = defaultdict(Counter)    for _uid, scene, _time, act in logs:        result[scene][act] += 1    for scene, counter in sorted(result.items()):        top = counter.most_common(3)        needs = set()        for act, _cnt in top:            if act in RULE_MAP:                needs.add(RULE_MAP[act])        print("【%s】高频行为: %s" % (            scene,            ", ".join("%s x%d" % (a, c) for a, c in top),        ))        print("    场景化需求: %s" % ("; ".join(needs) if needs else "暂无明显需求"))    return result  if __name__ == "__main__":    analyze(logs)

1. from collections import Counter, defaultdict引入计数工具，Counter 用来统计行为次数，defaultdict 用来按场景自动分组。
2. logs = [模拟真实埋点日志，每一条都带场景标签，这正是场景驱动分析与普通统计的关键差异。
3. RULE_MAP = {把高频行为模式翻译成需求关键词的专家规则表。
4. result = defaultdict(Counter)构建“场景 → 行为计数器”的分组容器。
5. for _uid, scene, _time, act in logs:逐条读取日志，拆出场景和行为两个关键字段。
6. result[scene][act] += 1同一个场景下的同一行为次数累加，形成频次统计。
7. top = counter.most_common(3)取出该场景下频次最高的 3 个行为，作为需求推断的证据。
8. if act in RULE_MAP:只有命中规则表的行为模式才被翻译为需求，避免没有依据的猜测。
9. analyze(logs)程序入口，完整执行从日志到场景化需求的转换。

常见误区

面试题