设计冲刺（Design Sprint）是在限定时间内，把一个重要产品问题变成可测试方案的团队工作方法。它把问题收敛、方案探索、决策、原型制作与用户验证连在一起，适合团队争论较多、直接开发代价较高，但可以用一条关键体验验证的选择。冲刺结束时应得到“下一步该改什么、继续验证什么”的依据，而不只是几张精美页面。
常见的五天安排来自GV 的设计冲刺方法：先理解问题，再探索与选择方案，随后制作原型、让目标用户尝试。用墨刀原型连接关键页面，可以让讨论中的方案变成可体验的流程；计划里的大部分时间仍应花在选对问题、做出取舍和理解反馈上。
什么时候值得做设计冲刺
设计冲刺适合“方向重要但尚不清楚”的问题。例如售后团队发现，用户预约了上门维修后，仍频繁打电话修改时间。产品、客服与研发各有解释：入口难找、可约时段看不懂，或用户担心改完后旧预约还在。团队若直接开发完整改约系统，可能把真正的障碍留到上线之后。
可以将挑战收敛为：“已有预约的用户，能否独立选定新时段，并正确理解改约结果？”这比“全面升级售后平台”更适合一次冲刺。后者同时牵涉派单、计费、师傅排班、用户消息等大量问题，一周内很难用同一份原型判断清楚。
如果只是确定的按钮错字、已有明确解法的布局缺陷，直接修改即可。若关键业务规则完全未知、用户无法招募、真正拍板的人不能参加，也应先准备这些条件。把五天填满，不会自动补齐决策资料。
设计冲刺与研发迭代也不同。研发迭代组织实现与交付工作；设计冲刺主要组织学习与方案决策。冲刺原型可能只覆盖产品的一小段，并不要求完成生产接口、真实支付或全部权限。两种活动可以衔接，但不能把冲刺原型直接算成上线版本。
开始前，把人、材料和测试对象准备好
不要到制作原型当天才问谁能决定规则。最小参与组合应能覆盖业务判断、用户信息、设计表达和技术约束：产品负责人明确范围，设计师负责方案与原型，研发判断依赖，业务或客服提供实际问题。安排一位主持人控制议题和节奏，并明确谁有权在分歧无法消除时决定本轮测试哪个方案。
用户测试也要提前安排。上门维修改约的测试对象应有相关预约经历或相近任务经验；只让熟悉后台规则的同事扮演用户，容易忽略用户真正不理解的地方。招募说明围绕经历与情境，不提前教对方产品里的入口名称。
| 准备项 | 改约任务需要的材料 | 缺少时怎么处理 |
|---|---|---|
| 现有过程 | 用户怎样预约、从哪里查询、目前怎样改约 | 访谈业务人员并整理实际过程，暂不猜页面 |
| 规则 | 哪些预约可修改、剩余时段来源、确认后旧时段如何处理 | 把未知项列给责任人；未明确规则不能画成确定成功 |
| 问题材料 | 脱敏咨询记录、退回原因、已有用户反馈 | 区分已发生问题与团队猜测，不编造数量 |
| 决策与分工 | 范围负责人、原型负责人、测试主持人与记录人 | 确认能参与关键环节的人，再排日程 |
| 测试准备 | 目标用户、任务文字、可用设备与安静环境 | 尽早招募，避免最后只能让同组互测 |
材料不必厚。先把一个典型预约及其规则整理到共享页面：原预约为周三14:00—16:00；用户想改到周五10:00—12:00；提交前旧预约仍有效，确认成功后替换为新预约。这里是一份可用于演练的业务设定，实际项目应替换成团队已确认的规则。
五天怎么安排：每天让下一步有材料可用
下面把五天节奏落实到这个改约任务。日期用于组织时间，真正要保持的是产物之间的依赖。远程团队可以拆分时段，但不要跳过决策就直接让设计师赶图。
| 阶段 | 这一天解决什么 | 留下的产物 |
|---|---|---|
| 第一天：理解 | 改约中哪一步最需要验证 | 现有任务图、一句挑战、待确认规则 |
| 第二天：探索 | 有哪些不同的入口和时间选择方案 | 能独立读懂的方案草图及差异说明 |
| 第三天：决定 | 本轮选哪条路径，哪些分歧暂不做 | 选定方案、逐步故事板、测试问题 |
| 第四天：原型 | 用户能否体验到关键判断和反馈 | 可点击流程、必要异常、测试脚本 |
| 第五天：验证 | 哪里理解一致，哪里需要改变 | 观察记录、问题归因、下一轮行动 |
第一天：在任务图上选目标，不急着讨论界面样式
画出“查看预约—提出改约—选择时段—确认变更—查询结果”，并标出用户、客服与派单系统各自做什么。请业务同事指出哪些状态确实存在，研发指出哪些数据需要等待外部响应。把事实、假设和未决规则分开，避免把一位同事的经验直接当作所有用户的行为。
随后选一个最有价值的目标：例如用户是否能在不联系客服的情况下确认新旧预约关系。如果真正的问题是可约资源不足，换一种界面也不能创造师傅空档；这类结论会改变冲刺重点，应当在第一天就暴露。
第二天：比较不同解法，而不是同一页面换三种颜色
可分别探索从“预约详情”进入、从“日历”进入，以及从“售后消息”进入的方案。每份草图需要讲清起点、主要操作和结果；视觉粗糙可以接受，但不能只有一个漂亮的首屏。
先让成员独立画，再一起阅读。只用口头讨论，表达强势的人容易提前决定方向；让草图独立说明内容，团队更容易比较具体差异。记录意见时写“日历入口难以关联当前工单”，比“我不喜欢这个方案”更能帮助后续决策。
第三天：确定故事板，停止无限加需求
围绕挑战比较方案：哪个入口最符合用户当前所处位置，哪个方案更清楚地表达替换关系，关键数据是否实际可得。确定本轮测试路径后，列出每一幕用户看到什么、会做什么、接着发生什么。
如果两个方案仍难以取舍，可以保留两个明确不同的方向，但要评估制作和测试成本。不能把方案A的入口、方案B的日历和方案C的结果页直接拼在一起，却没有人负责整个逻辑。决策者应说明本轮选择及理由，未选方案保留为后续备选。
第四天如何把故事板做成可测试原型
按故事板分工比按页面数量分工更可靠。一人梳理预约资料与文案，一人制作页面，一人连接流程并检查规则；这些角色可由较小团队兼任。指定一位整合负责人，确保相同时间、订单号和状态没有在不同页面变成不同内容。
| 画面 | 必须表达的信息 | 需要连接的操作 |
|---|---|---|
| 预约详情 | 原时段周三14:00—16:00，当前预约状态 | 修改时间进入时段选择；返回保留原预约 |
| 选择时段 | 可选日期、时段、当前选择 | 选择周五10:00—12:00后进入确认 |
| 确认变更 | 旧时段、新时段、确认后替换的说明 | 返回仍保留选择；确认后进入处理结果 |
| 结果 | 修改成功及新时段，查询预约入口 | 回详情看到新预约；不得仍展示旧时间 |
| 时段不可用 | 该时段刚被占用，原预约仍保留 | 回到可选时段，不让用户从首页重来 |
在墨刀中先建立这几个页面或状态，使用相同的预约资料，再连接主按钮、返回与取消路径。把“提交前旧预约保留”“确认成功后替换”写在对应页面附近，让原型制作者和测试主持人用同一套规则。
测试界面理解时，示例数据可以是预先准备的；但反馈必须足够可信，不能所有按钮都无条件跳成功。若本轮要判断提交等待是否让人误以为失败，就需要补处理中与查询结果路径。若要测真实系统延迟、资源竞争或发送成功率，静态预设就不够，需另安排技术验证。
AI可用于生成页面初稿或整理文案，提示里应带上已经选定的故事板、时间和规则。不要在这个阶段让AI扩展会员、商城、积分等无关模块。原型完成后，由没有负责连线的人从同一入口走一遍，检查误触、返回、取消与结果页数据，而不是只看首页截图。
第五天怎样听到有用反馈
给用户任务，不给答案。可以说：“你已经预约了周三下午上门维修，但那天临时有事。你希望改到周五上午，请按自己的理解处理。”不要说“请点击修改时间按钮，再选星期五”，否则最需要验证的入口发现问题被主持人替用户完成了。
完成后再问：“现在预约的是哪个时间？”“如果你停在刚才的确认页，没有提交，会保留哪一次预约？”通过回述了解用户的理解。口头说“挺好用”，但仍认为旧预约需要另行取消，是比满意度表态更重要的发现。
| 记录 | 怎么写 | 下一步用途 |
|---|---|---|
| 观察到的行为 | 用户反复返回详情核对旧预约是否还在 | 定位结果理解或信息缺失，不先归咎用户 |
| 用户的原话 | 按实际录入的表达记录，不编造成统一评价 | 保留推断依据，与主持人解释分开 |
| 团队判断 | 可能未理解替换关系，需要修改确认摘要 | 这是待检验解释，不是已证明因果 |
| 下一次改动 | 显示新旧时段对照，再用同一任务验证 | 让修改与发现一一对应 |
组织测试时，每位参与者独立留记录，再归纳跨人出现的问题。小样本可以帮助发现误解与操作障碍，但不能据此宣称全体用户转化率或商业效果已经得到证明。更细的主持与观察方法可继续阅读原型可用性测试教程。
冲刺结束后，怎样把结果接到真实工作中
将结果分为三类即可：可以继续推进的部分、需要改动再测的部分、仍缺业务或技术资料的部分。每类对应具体范围，避免用“整体通过”覆盖某个关键未决问题。
如果用户能找到入口，却误解新旧预约关系，先修确认和结果反馈，不必重做全部页面；如果用户根本不认为线上改约能解决问题，就回到挑战和替代方案；如果规则无法确定，例如是否允许临近上门时间修改，则先由业务确认，再让设计与研发继续。不同发现应回到不同阶段。
进入研发前，把已选方案、原型版本、状态规则和仍需确认的依赖放在同一份交付记录里。随后可通过产品原型评审确认实现范围。用户验证回答的是体验理解与任务问题，研发评审还要处理接口、权限、数据和异常；两者相互补充。
真正有用的设计冲刺，会留下一个更清楚的决定，以及可以继续修改的原型。下一次组织时，从一个有价值的挑战和一条完整路径开始，比为凑齐五天安排大量会议更容易得到可执行的结果。
