分镜图
Storyboard
用连续画面或文字场景描述用户体验或方案流程。
需要把一个使用过程按顺序讲清楚,检查用户动作和信息衔接时使用。逐帧记录情境、动作、结果和疑问。
具体使用任务、起止条件、用户行为依据、拟议体验和失败情境。
文字故事板、过程缺口和待验证的体验问题。
先理解,再动手
使用步骤
以用户经历的时间顺序展开场景,用文字分镜表达人物、地点、动作、对白或心理与反馈。每行一幕,检查前后衔接。
- 01
确定主角和目标
- 02
按时间顺序拆成关键场景
- 03
描述每个场景的行为、触点、情绪和结果
- 04
检查流程是否顺畅并补充关键细节
顺畅故事不证明可用性;拟议功能、成功结果与已观察行为要区分。
看清框架结构
从一份空白提纲开始
复制到你的文档,填入真实的业务事实与判断。
查看空白提纲
分镜图 · 空白提纲 什么时候用:需要把一个使用过程按顺序讲清楚,检查用户动作和信息衔接时使用。逐帧记录情境、动作、结果和疑问。 需要准备:具体使用任务、起止条件、用户行为依据、拟议体验和失败情境。 预期产出:文字故事板、过程缺口和待验证的体验问题。 使用边界:顺畅故事不证明可用性;拟议功能、成功结果与已观察行为要区分。 工作问题: 期望结果: 已有证据与假设: 未知项与下一项核查: 填写说明:谁在什么情境下要完成什么任务? 1. 故事主题与人物: 填写说明:每行:场景 | 人物动作 | 对白或心理 | 结果与反馈,用 | 分隔。 2. 分镜画面: 填写说明:哪一幕存在阻力,准备如何测试? 3. 体验验证: 检查清单 □ 场景顺序清楚。 □ 每一幕都推动理解或决策。 □ 能暴露体验漏洞或沟通盲点。 考虑下一个框架 产品策划书: 故事板暴露了具体体验缺口,需要约定方案范围和资源时,用产品提案整理证据、约束及试验请求。 https://bizthinkframe.com/zh/frameworks/product-proposal BizThinkFrame · https://bizthinkframe.com/zh/frameworks/storyboard
跟着案例走一遍
虚构教学案例用分镜解释免注册审稿
组织、人物、数据和结果均为虚构,仅用于说明框架用法。
背景与问题
云桥需要向研发和客户说明新审稿体验。
长篇需求文档无法让大家快速理解用户看到什么、做什么。
手头有哪些材料
- 场景为客户通过手机首次查看设计稿
- 目标是在四个画面内讲清一次反馈
如何使用这个框架
- 每格只表达一个关键时刻,配一句用户想法或动作。
- 检查从第二格到第三格是否需要登录,发现这会打断流程。
- 补上出错与重新提交提示,再供研发评估。
形成四格体验分镜,明确免注册与反馈确认两个关键要求。
故事顺畅之前,先找三种被省略的困难
第一,格子之间偷偷换主角、目标或起点时,先重看。客户审稿与项目负责人分派任务,拥有的信息和权限不同。悄悄换人会让流程看似轻松,因为困难被别人解决了。保留同一视角,重要交接明确画出。
第二,从意图直接跳到成功时,先补状态。点击提交、系统收到请求、本人看见确认,是不同事件。链接过期、版本错误、连接中断都可能打断过程。不必写完整规格,但应指出足以推翻体验设想的失败。
第三,想象对白不能标成研究引语。拟定场景中的心理活动只是写作表达,除非有人实际报告或观察。插图漂亮也不证明理解、权限或技术可行。本页工具产出可编辑文字分镜,画草图或演示流程是另外的讨论方式。
分清拟定经历、观察旅程、流程和概念
分镜让关键时刻便于讨论,也能在实现前暴露跳步。需要其他证据或工作视角时,再换相应方法。
| 输入与问题 | 方法 | 产出及边界 |
|---|---|---|
| 概念需要按时间展示用户经历 | 分镜图 | 拟定时刻、行动与反馈;不是实际旅程。 |
| 已有客户观察,需要按触点组织 | 客户旅程图 | 分阶段证据与缺口;想象行为继续标明。 |
| 需明确角色、条件与异常路径 | 业务流程图 | 带分支的流程;不证明实现有效。 |
| 点子还缺对象、机制或试验 | 创意单 | 有限概念;不证明需求。 |
四格审稿案例:把画面当需求,不当已经发生
完整虚构材料是:云桥客户在手机上打开审稿链接,四格依次为收到链接、查看变更、留下反馈、确认完成。概念拟免注册,意见绑定版本;计划三名未见方案者复述说明,另请五位试用者检查体验,还需检查出错与重新提交提示。两组都没有结果,也没有证明功能已经实现。
第一格提供项目、发送者和截止;第二格拟呈现变更摘要。在转向图片反馈时,团队发现插入注册会打断预期流程。这是需要解决的设计冲突,不是所有真实用户都会放弃注册的证据。最后一格则要区分本人动作与系统确认收到。
下表保留四个原时刻,并为各格提出核查。想象提问属于虚构场景,不是客户引语。增加界面前,先看过渡是否让主角有足够信息行动;成功提示必须对应实际状态,故事不能代替核对这一关系。
| 时刻 | 拟定行动与疑问 | 预期反馈及核查 |
|---|---|---|
| 收到链接 | 打开消息:需要何时反馈? | 项目、发送者、截止可见;核对收件人与链接状态。 |
| 查看变更 | 读摘要:这版改了哪里? | 找到重点;确认目标版本与必要上下文。 |
| 留下反馈 | 标注图片:这里需要调整 | 意见绑定版本;核对手机定位与出错后的保留。 |
| 确认完成 | 提交:是否已经发出? | 确认与下一步;区分等待、失败与已收到。 |
两种检查分开做,保留恢复失败
结论是拟定体验更清楚,但免注册与确认要求仍待评估。表达检查拟请三名未见方案者无提示复述,记录误解的角色、过渡或状态。先约定怎样算说明充分;会复述故事,不代表能在手机上完成任务。
五位用户的试用另约任务、参与、设备条件与原型限制,观察入口、反馈位置、版本理解、提交状态和出错恢复。三名复述者与五位试用者不能合并成八人可用性成功率;是否重叠没有给定,两项问题也不同。
保留中断、求助和重复提交。无法确认反馈是否收到的人可能重发,需要约定恢复行为,而不是再画一格成功画面。可靠重提和批注保留,都要等相应行为实现并核查后才能承诺。
复查分清说明改稿、需求变化、可工作的原型与完成的技术测试,记录哪些过渡改善、哪些未解决、是否值得再迭代。即使发现概念要改,完整四格仍有设计价值。本例没有理解率、完成率或访问控制成功结果。
检查你的思考
再问自己几个问题
- 用户第一步如何接触到方案?
- 哪个瞬间最能体现价值?
- 整个流程中哪里可能中断或产生困惑?
完成前的检查清单
- 场景顺序清楚。
- 每一幕都推动理解或决策。
- 能暴露体验漏洞或沟通盲点。