一、太过熟悉的设计起点
很多设计师的项目，都是这样开始的。这次要做一个会员中心，功能大概有这些：会员等级、积分、优惠券、消息通知、任务中心，再加个成长值体系。你拿到一份洋洋洒洒的功能列表，心里既踏实又有点发虚。
踏实的是PM看起来已经想得很清楚；发虚的是你并不知道用户在什么时刻会打开它、希望在几秒钟内完成什么、又最怕遇到什么麻烦。
于是，你开始像搭积木一样往上叠：首屏排一个会员卡、大字写等级，下面放积分、优惠券入口，再放几个运营位，给活动留点空间，右上角加个消息中心图标，左上角加个返回按钮……
每一块都说得过去，但当你把页面串成一个整体，心里经常会冒出一个小疑问：“用户真会在现实生活中这样用吗？”
如果你也常常有这种隐隐的不安，那很可能是因为你一直在 围绕“功能”设计一个界面，而不是 围绕“场景”支撑一段真实的行为。而这一篇文章，我们就是想先把这个“转折点”讲透：
- 为什么单靠功能清单不够？
- 为什么场景分析，是更成熟设计方法真正的起点？
二、只有功能，会把产品带向哪里
先抛开任何方法论，我们只看结果。当一个产品只按照“功能列表”来设计，通常会出现三个肉眼可见的问题。
1. 功能丰富，但路径支离破碎
想象一个叫车 App，如果所有需求只是这样写：
- 叫车
- 选择车型
- 费用预估
- 优惠券
- 行程记录
- 投诉与反馈
你完全可以做出一个功能完备的产品：首页给一个大大的“立即叫车”按钮，周围再放几个入口，点进详情页，可以看到车型、费用、优惠券……看起来都在。但用户真实的使用情境是什么呢？
- 有人是在早高峰，手里还拎着早餐，电梯门刚打开；
- 有人是深夜在陌生城市，下了高铁，只想尽快坐上车；
- 有人是带着小孩出门，需要确认儿童座椅、后备箱空间……
当这些具体的场景没有被写出来时，所有“入口”都是同等重要的：你很难坚定地说：哪一个才该是首屏的主角？于是页面上每个功能都有，又每个都不够贴心。
2. 体验问题被藏在空白处
再看外卖点餐。如果需求只有一条：“提供下单和支付功能”，你会很自然地设计：选餐 → 加购物车 → 填地址 → 支付。但真实生活中的空白处，它往往长这样：
- 用户已经饿得有点烦躁，容忍不了复杂操作
- 他可能一只手拿着手机，另一只手在做饭或抱小孩
- 网络可能不是很好，页面加载稍微慢一点就会被关掉
- 他可能记不清上次点的是哪家，只记得“上次那家很不错”
这些看似不属于功能范围的东西，一旦没有被翻上台面，就会变成体验上的“暗伤，表单多一个输入项，用户就更容易放弃；页面多一秒加载，饿到发脾气的人就直接关掉；没有“最近常点”的入口，他每次都要从头搜索。功能没问题，流程也能跑通，但真实场景下，用户就是“不想用、用不下去”。
3. 团队讨论永远停留在要不要做
当产品文档只是一堆功能清单，评审现场很容易变成一种熟悉的画风：
- “我觉得这个入口也要有，竞品都有。”
- “这个分支太复杂了，干脆先不做。”
- “这个需求用户到底会不会用啊？”
你会发现，大家争来争去，主要是围绕着“做不做、放不放”在辩论。至于：用户在什么情况下会来到这里？他此刻的心理状态是什么？这一步对他是“核心任务”还是“顺手附带”？这些本该决定设计优先级的东西，从头到尾都没被看见。
当场景缺席时，所有人都只能靠“感觉”和“经验”做判断，而所谓经验，很多时候只是“上一个项目的做法”，至于这次是否适用，谁也说不清。
三、同一个产品，换一个镜头会怎样
为了更清楚地感受“功能视角”和“场景视角”的差异，我们用一个简单例子对比。
1. 功能视角：一个在线课程产品
功能清单可能长这样：
- 课程列表
- 搜索与筛选
- 课程详情页
- 视频播放
- 章节列表
- 收藏与继续学习
如果只看这张表，你也能做出一个规规矩矩的学习产品。
2. 场景视角：一个具体的学习片段
我们把镜头拉到一个非常具体的时刻：
“工作日的晚上，阿杰坐地铁回家，大概有 30 分钟的通勤时间。他已经订了一门‘产品运营入门’课程，想利用这段零碎的时间学两节课，为下周的转岗面试做准备。 地铁很挤，网络时好时坏，他一只手抓着扶手，另一只手拿着手机。 他最希望的是：打开 App，直接看到‘继续学习’的入口，一键进入上次停下来的章节； 他最怕的是：每次都要重新找课程、找章节，还要看一大段介绍，甚至等待长时间缓冲。”
你可以感受一下，这段场景描述给设计提出了怎样完全不同的问题：
- 首屏是否应该把“继续学习”放在最显眼位置？
- 视频列表是否要默认按“最近学习”排序，而不是纯学科分类？
- 播放页里，是不是应该支持网络不佳时的小窗口播放、自动降清晰度？
- 横竖屏切换、亮度、倍速这些控件该如何排布，才能在拥挤环境下也容易点击？
这些决策，在“功能清单”里是看不到的； 却在“场景描述”里变得一清二楚。下面我们再换一个例子
3. 记笔记 App：功能 vs 场景
记笔记 App 功能清单式的需求：
- 创建笔记
- 笔记分类与标签
- 搜索
- 回收站
- 多端同步
看上去都很合理。但如果我们把场景写出来：
“开项目会议时，小萱一边听，一边用电脑记要点。 会后她走出会议室，站在茶水间，突然想起一个灵感。 她没带电脑，手里只有手机，希望能立刻把这个想法记下来—— 最好是打开 App 就能直接开始输入，而不是先面对一堆分类和模板的选择。”
这时你会意识到：也许首页最重要的，不是“完整的分类结构”，而是一颗醒目的快速记一笔；搜索再强大，如果用户连想写的时候能马上写都做不到，留存也难提升；多端同步是基础，但满足灵感捕捉场景的轻便，是更直接的价值。
同样一组功能，当它被放回真实生活的片段里，它的优先顺序会被彻底改写。
四、场景分析真正改变的是思考方式
看到这里，你大概已经感觉到，场景分析并不是多了一项“额外工作”，而是在悄悄改变你思考问题的方式。从“我有什么”到“他此刻需要什么”。功能清单关注的是：“我们能提供哪些能力？”，场景分析逼你去问：“在这个具体时刻，这个人真正需要的是什么？”前者容易让产品不断“加东西”，后者则帮你发现：很多东西可以不做，但有些细节必须做到极致。
从“界面好不好看”到“这一步顺不顺手”，你依然会关心布局、色彩、对齐这些视觉问题，但你比以前更容易问出这样的问题：
- 用户手上是否空闲，可以双手操作？
- 他有多少注意力可以“分给你”？
- 他是在赶时间，还是在慢慢探索？
这些问题一旦被摆在桌面上，很多“到底要不要加这个按钮”的争论，都会自动有了答案。
五、场景分析在方法论中的位置
很多读者可能已经在用其他方法：用户画像、旅程地图、用例、故事板……那场景分析在其中到底是个什么角色？这里我们只做一个“站位感”的梳理，不展开细节（关于场景分析，我们是规划了系列课程，后面几篇再拆开讲）。
你可以这么理解：
- 用户画像像是在建“角色档案室” 里面记录的是“这类人是谁、长期在追求什么”。
- 用户旅程地图像是在画“全局路线图” 从第一次听说产品，到使用、流失、回访，是一条跨阶段的长线。
- 用例（Use Case）更偏向“系统视角的逻辑” 在什么前置条件下，用户和系统之间会发生哪几步交互。
- 故事板（Storyboard）更注重“可视化的故事” 把某个关键片段画成一帧一帧的画面，让团队共享一个直观印象。
而场景分析更像是你在所有这些方法之间的“关键枢纽”，它从画像里拿到“这个人是怎样的”，从旅程里选中某一个关键阶段；写成一段足够具体的生活片段；这段片段，既可以继续被抽象为用例，也能被画成故事板；最终落回到流程图、界面、交互细节里。
如果说画像是“横向看人群”，旅程是“纵向看时间”， 那场景就是“在一个具体交点上，把人、时间、目标、环境揉成一小块真实生活”。
有了这个“站位感”，你在后面学习和使用场景分析时，就不会迷路：你知道它不是来替代这些方法的，而是帮它们更落地、更有温度。
六、小结
在这一篇里，我们没有教你任何操作步骤，也没有分解“场景要写哪几个要素”，我们只做了一件事：邀请你把设计的默认起点，从“功能清单”， 慢慢挪到“具体的使用场景”。
因为一旦这个起点改变了，你后面的很多决策都会跟着变，你会更自然地问：“他此刻在哪里、在干什么？”你会更容易看到：为什么这个环节总是卡住人？你会在评审时，改用“故事”而不是“模块名称”去说服别人。
接下来的几篇，我们会在这个基础上往下走，比如下一篇，我们会回答一个看似简单但其实很关键的问题： “一个完整的场景，最少要写清楚哪些部分？”再往后，我们会聊，场景从哪里来、怎么从访谈和数据里挖掘、 又如何从一段场景文本推导出需求、流程和界面。你可以把这篇文章，理解为整套“场景分析”系列的开场白。
从今天起，当你再拿到一份需求时，不妨先在心里多问一句：“这些功能，落到用户的一天里，到底是哪一幕？”
有0人收藏了本文
