完整案例：方块小岛的一次迭代
这是一份虚构的设计推演。它展示独立开发者如何把一个体验问题推进到可实现、可验收的需求；不包含真实用户研究、留存提升或微信实机验证结果。
1. 问题与首版边界
产品方向：微信轻度点选消除闯关游戏，方法不绑定引擎。
暂定情境：碎片时间、单手、静音、可能被消息打断。
本轮目标：玩家理解本局收集目标，完成首次消除；失败或中断后知道如何继续。
本轮不做：完整内容生产、排行榜、付费系统、账号体系与正式广告接入。站内实验用于验证局部交互，不构成完整可运营游戏。
2. 先补齐规则，防止各自理解
| 规则项 | 教学案例的完整关卡提案 |
|---|---|
| 基本操作 | 依次选择一对同色且上下或左右相邻的方块 |
| 取消与无效 | 再点已选项可取消；斜对角或异色无效，不扣步 |
| 初始资源 | 示例第 1 关为 12 步，目标收集 6 个蓝色 |
| 有效操作 | 消耗一步；蓝色消除按实际数量增加目标进度 |
| 棋盘补充 | 消除后按确定规则补充；生成和无解处理须继续细化 |
| 同时结束 | 最后一步同时达标时，先判成功 |
| 免费重试 | 保留关卡与已确认长期进度，新建本关的一局 |
| 可选奖励 | 正式条件满足后给原局增加 3 步，同一机会只发一次 |
站内首次引导实验为了聚焦学习，只要求匹配一对蓝色、收集 2 个；不补充棋盘、不计算完整关卡胜负。广告实验也只展示模拟状态与本地幂等。两者的简化均在实验旁标注。
3. 找到要验证的假设
| 假设 | 候选设计 | 如何验证 |
|---|---|---|
| 玩家不清楚只收集蓝色 | 目标用形状、颜色、文字和数量常驻 | 看能否解释并完成目标操作 |
| 玩家不理解相邻 | 第一次选择后给就地提示，无效时说明 | 看斜对角误选后的自我纠正 |
| 失败后没有方向 | 展示差距、建议与免费重试 | 看能否预测按钮目的地 |
| 中断后担心丢进度 | 检查点与恢复说明 | 热返回、冷启动后观察理解 |
这些都是待验证假设，不是“研究发现”。你可以先选最影响当前路径的一项做原型。
4. 主路径与异常一起写
图中“读取与准备”还要扩展失败、取消和版本冲突。不能因为图里画了一条成功线，就省略状态表。
5. 把需求拆成 AI 能评审的任务
任务一：检查规则冲突与缺口，明确棋盘生成和结束优先级。
任务二：比较两种首次引导，给低保真与状态表，暂不实现。
任务三：做一次局部交互原型，标注固定数据与模拟平台行为。
任务四：按确认规则实现，附重复、中断与恢复测试。
任务五：逐条回应验收，说明实机和玩家验证还缺什么。
每一步都能在投入更大成本前被纠正。例如第三步若发现玩家仍误解“蓝色才计目标”，先改信息表达，暂缓视觉细化和完整关卡内容。
6. 一组关键验收
- 第一次进入：目标、允许操作和反馈可见，不要求先记住全部道具规则。
- 无效选择：不扣步，知道怎样纠正；选中可取消。
- 重复与乱序：同一操作只处理一次，旧局结果不覆盖新局。
- 失败：解释差距，免费重试目的地明确。
- 奖励：条件明确，关闭或失败不发奖，同一机会不重复发。
- 中断：后台暂停；冷启动只使用校验通过的检查点。
- 保存失败：不显示已保存，当前可用状态受到保护。
正式存档还需要棋盘、随机状态等完整数据；本地资源校验也不能替代生产系统的权威记录。
7. 验证计划与下一步
先跑规则与状态测试，再做浏览器和目标微信设备检查。然后让符合情境的新人尝试首局，不给答案，记录求助、误触和规则解释。
若观察结果支持目标表达问题，就做小改动并复测；若目标已清楚而玩家觉得无聊，则转向选择空间、难度与节奏。不要用同一种“加提示”解决所有问题。
完成这一轮后，保留“问题—证据—改动—结果—待办”的决策卡。你得到的不是一套永远正确的界面，而是一种持续把需求说清楚、把假设验明白的方法。