2. V流程基础
说实话，我见过太多团队把产品做出来才发现没人用。为什么？因为从一开始就没搞清楚用户到底要什么。用户调研和场景分析，就是帮你避免这种悲剧的。
这一章，我们聊聊怎么跟用户聊天、怎么设计问卷、怎么画用户画像、怎么写用户故事。全是实战经验，没有废话。
用户访谈技巧：别把天聊死
用户访谈是获取第一手需求的最佳方式。但很多人把它搞成了审问现场。
我曾经犯过的错：第一次做用户访谈时，我拿着问题清单一条条问，用户回答"是"或"不是"，半小时就结束了。结果啥也没挖出来。
后来我总结了一套方法：
- 开放式问题优先：别问"您觉得这个功能有用吗"，要问"您平时是怎么处理这个问题的"
- 追问到底：用户说"还行"，你就追问"能举个具体例子吗"
- 沉默是金：用户说完后，等3秒再问下一个问题。很多时候用户会补充关键信息
- 记录行为而非观点：用户说的不一定是他做的。观察他的实际操作更重要
我的小技巧：访谈时带个录音笔，但一定要征得同意。回头整理录音时，你会发现很多现场没注意到的细节。
问卷调查设计：别让用户填到一半放弃
问卷是量化调研的好工具，但设计不好就是垃圾数据。
我见过最离谱的问卷：50道题，全是必填，最后还有开放题"请详细描述您的使用场景"。结果回收率不到10%。
好的问卷设计原则：
| 原则 | 说明 | 我的经验 |
|---|---|---|
| 控制在10题以内 | 超过10题，用户就开始乱填 | 我一般控制在7-8题，完成率最高 |
| 先易后难 | 开头放基本信息，中间放核心问题，最后放开放题 | 上来就问敏感问题，用户直接关页面 |
| 选项互斥且穷尽 | 每个选项不能重叠，且覆盖所有可能 | 加个"其他（请注明）"兜底 |
| 避免引导性 | "您是否认为我们的产品很好"这种问题别出现 | 用中性表述，比如"您对产品的整体评价是" |
关键指标：问卷回收率低于30%说明设计有问题。我个人的目标是50%以上。
用户画像构建：给用户一个名字和故事
用户画像不是编故事，而是把调研数据变成活生生的人。
我习惯每个产品建3-5个画像。太多了记不住，太少了覆盖不全。
一个完整的用户画像包含：
- 基本信息：姓名、年龄、职业、收入范围
- 行为特征
- 痛点：现在用竞品时最烦什么
- 目标：用这个产品想达成什么
- 一句话描述：比如"忙碌的上班族，想快速搞定午餐"
避坑指南：我曾经把用户画像写成了"30岁、白领、月入1万"，结果团队讨论时发现这根本没法指导设计。后来我加了"每天早上挤地铁时刷手机，最烦加载慢"这种具体场景，设计方向一下子就清晰了。
下面这张图展示了用户画像的核心结构：
用户故事编写：让开发知道该做什么
用户故事是敏捷开发的核心工具。格式很简单：
作为<用户角色>
我想要<功能>
以便<价值>举个例子：
作为忙碌的上班族
我想要一键下单午餐
以便在5分钟内完成点餐但光有格式不够。我见过团队写出来的用户故事跟需求文档一样长，那就失去意义了。
好的用户故事有三个特点：
- 可讨论：不是最终方案，而是讨论的起点
- 可估算：开发能大致判断工作量
- 可测试：做完后能验证是否满足需求
我的经验：用户故事写完后，我会让团队读一遍。如果有人问"这个用户到底是谁"，说明画像没做好。如果有人问"怎么做"，说明故事太细了。如果有人问"为什么做"，说明价值没写清楚。
从调研到场景：把数据变成设计依据
调研完了，画像有了，故事写了。然后呢？
很多人卡在这一步。数据一堆，不知道怎么用。
我习惯做一件事：场景映射。把用户故事放到具体场景里，看看用户在什么时间、什么地点、什么情绪下使用产品。
举个例子：
| 用户故事 | 场景 | 设计影响 |
|---|---|---|
| 一键下单午餐 | 中午12:00，办公室，肚子饿，手机快没电 | 页面加载要快，操作步骤要少，支持低电量模式 |
| 查看订单状态 | 等餐时，频繁刷新，焦虑 | 推送通知比手动刷新更好，显示预计送达倒计时 |
| 评价菜品 | 吃完后，有空但懒得打字 | 提供星级评分+快捷标签，不要强制写评论 |
你看，同一个功能在不同场景下，设计是完全不同的。这就是场景分析的价值。
注意：别把所有场景都塞进第一个版本。我见过团队想一次满足所有场景，结果产品变得臃肿不堪。先做核心场景，其他的后面迭代。