发现问题
梳理预订全链路与角色诉求，识别信息缺口与体验断点。
查看调研与边界Rainbow Town · Venue booking
场馆预约
与资源调度
化解多场馆、多资源、动态定价下的预约复杂性
从资源与规则建模，到横向比较、连续时段选择、异常恢复和订单复核；用可运行原型验证完整路径，再与产品和研发共同确认交付边界。
Demo 使用模拟数据，不会创建真实订单或发起支付。
打开同一套交互 Demo ↗
01 · Project overview
不是“选一个时间”，而是协调一组互相影响的对象。
用户只想尽快找到合适场地；系统必须同时处理 SKU、资源、30 分钟库存、峰谷价格、连续时段、附加项、优惠与订单。我的工作是让这些规则在一个可理解、可恢复的路径中成立。
负责范围、对象关系、任务顺序、状态与响应式策略。
不同运动 SKU，共享场馆资源与订单能力。
以模拟数据验证选择、计价、错误恢复和完成路径。
只陈述已实现的体验与交付证据，不虚构业务指标。
02 · Problem framing
先把预订失败的原因讲清楚，再决定页面长什么样。
如果先画界面，资源、库存和价格很容易被混成同一个状态。前期先围绕用户任务和系统对象建立共同语言，明确“不做什么”，再把复杂规则压缩进一次可扫描的决策。
找不到合适的时间，或不知道为什么不能选
- 需要来回打开场地查看空档
- 峰谷价格缺少上下文
- 错误发生后容易丢失已选内容
同一份库存被多个项目、规则和订单共同影响
- 场地与运动 SKU 不是同一个对象
- 连续时段要合并但仍可撤销
- 价格和可用性必须分开计算
比较、选择、计价和恢复在同一条路径完成
- 先看资源与时间，再进入附加项
- 每次选择都同步订单摘要
- 错误保留上下文并给出下一步
03 · Resource model
先统一对象语义，再让页面和研发说同一种语言。
预约不是一张孤立的日历。用一条可追踪的对象链把商品、场地、库存、预约段与订单关联起来，状态和价格才不会在不同角色之间失真。
- 01 · SKU运动项目
羽毛球、匹克球及其定价规则。
- 02 · Resource场地资源
可被预约的具体场地与位置。
- 03 · Slot日期与时段
以 30 分钟作为选择与计价单位。
- 04 · Booking预约段
相邻时段合并为可管理记录。
- 05 · Order报价与订单
场地、附加项、优惠和联系人汇总。
这是当前 Demo 的真实界面截图，不是另一套后台素材或概念重绘。完整的附加项、优惠、表单修正和确认状态可在下方 Demo 中操作。
04 · Key decisions
四个决定，把密集规则变成可操作的选择。
决策不是视觉偏好，而是为了让用户在最少跳转中比较资源、理解价格、控制连续时段，并在桌面与移动端都能完成任务。
用 Resource × Time 棋盘横向比较
场地为行、时段为列，让可用性与价格在同一个阅读面中出现。
固定资源列 · 时间分组 · 日期切换库存状态与价格状态分开判断
“有余位”不等于“低价”，两套规则分别计算、同屏解释。
Available / Full · Peak / Off-Peak相邻时段合并，同时保留撤销
连续 30 分钟时段形成一条预约段，减少噪音，但允许随时删除或修改。
即时汇总 · 上限反馈 · 返回编辑桌面强调扫描，移动端强调分步
桌面保留完整棋盘；移动端固定资源信息，并把订单摘要收进分步路径。
横向浏览 · 固定信息 · 响应式摘要| 状态 | 触发条件 | 界面反馈 | 恢复方式 |
|---|---|---|---|
| 可用 / 已选 | 资源无冲突，用户完成选择 | 价格可见，高对比选中态，摘要同步 | 再次点击或在摘要中删除 |
| 紧张 / 已满 | 余量低或全部资源冲突 | 提前警示；不可选状态不隐藏原因 | 切换日期、场地或运动类型 |
| 优惠无效 | 代码不存在、过期或不适用 | 保留预约内容，只标记优惠字段 | 修改或移除优惠码后继续 |
| 联系人错误 | 必填项缺失或格式不完整 | 定位到字段，订单与价格不清空 | 修正字段后重新确认 |
05 · AI collaboration
AI 提供“放大镜”和“检查表”，我负责方向盘。
AI 参与材料整理、候选生成和重复性检查；涉及业务语义、价格、库存、权限和交付范围的判断，仍由我与产品、研发逐项确认。
把散落材料聚成问题簇
归纳用户任务、角色诉求和竞品流程，帮助定位需要进一步验证的断点，而不是直接生成结论。
扩大异常与恢复场景覆盖
从主路径反推售罄、冲突、无效优惠、字段错误与返回修改，再由业务规则筛选。
生成候选，再人工取舍
辅助拆解组件、准备文案备选和重复代码；页面结构与交互优先级由我决定。
寻找遗漏，而不是替代验收
检查空状态、禁用态、响应式、键盘与文案一致性，最终以人工走查和业务确认收口。
责任边界
AI 输出视为候选材料，不作为业务事实。没有真实数据支撑的指标不进入案例结果；正式环境的规则与实现，以产品和研发验收为准。
06 · Interactive prototype
亲自完成一次从选时段到确认的预约。
Demo 环境 · 模拟数据全屏体验 Demo
- 01选择日期与运动项目
- 02选择相邻场地时段
- 03添加器材并尝试优惠码
- 04复核信息并完成确认
07 · Delivery evidence
结果不写漂亮数字，写清楚交付了什么。
本案例的可信结果来自已经形成的产品逻辑、可操作原型、状态覆盖和协作方式。正式产品事实与 Demo 模拟数据分开表达，不用测试订单推导运营表现。
一套可被产品与研发共同理解的资源模型
SKU、场地、时段、库存、预约段与订单形成统一对象链。
一个从选择到确认可完成的 Demo
覆盖连续时段、附加项、优惠、校验、返回编辑、确认与再次预约。
状态、响应式与组件约束进入交付
不仅交付默认界面，也说明异常恢复、移动端策略与验收边界。
Reflection
生成速度提高后，验收反而要更严格。
AI 能更快扩展场景和搭建原型，但如果没有对象模型与责任边界，错误也会被更快放大。下一步仍值得继续验证库存临时变化、支付返回和网络失败等需要真实接口配合的状态。
Try the complete flow
先在安全的 Demo 环境里完成一次预约。
所有主要体验入口都指向模拟环境，不会接触真实商家订单或支付。