核心挑战
资源、时间和价格必须在一次判断中被看懂
用户需要横向比较多个场地与时段，同时理解哪些已经被占用、哪些处于峰值价格、连续选择后会形成多长的预约，以及最终费用如何变化。 如果把这些信息拆成过多步骤，效率会下降；全部堆在一张表里，又容易产生信息过载。
- 羽毛球与匹克球是不同 SKU，但需要在同一页面比较。
- 工作日、周末和不同时段对应不同价格。
- 已预订、少量余位、售罄、选中等状态必须明确区分。
- 连续时段要合并为可理解的预约段，并受数量与总时长限制。
6+
场地资源管理（羽毛球 + 匹克球）
30min
最小预约时段与连续时段组合
3-Step
选择场地、增值项目、订单确认
Real
真实客户 · 正式上线 · Pisell 平台
01 · Context & Scope
先把“选一个时间”还原成真实业务问题
对用户而言，这是一次简单预约；对系统而言，它同时涉及项目 SKU、可用场地、日期、30 分钟库存、峰谷价格、连续时段、附加项目与订单规则。 我的工作是把这些规则整理到同一条路径中，让用户能够理解、选择并及时收到校验结果。
我的角色与边界
产品设计、UX 与可运行原型验证
我负责梳理前台预约路径、对象关系、页面结构、交互状态与响应式策略，并通过 React Demo 验证复杂表格、选择反馈和购物车汇总是否成立。
- 定义用户在日期、场地、时段和价格之间的决策顺序。
- 把业务规则转译为可交互状态和前端数据映射。
- 用 Demo 与产品、研发核对边界，而不是只交付静态稿。
本页重点展示用户端预约与报价体验；商品、库存、订单、支付及后台管理能力由 Pisell 平台承接。
02 · Product Model
先统一对象语义，再设计页面
预约页面不是孤立界面。只有先明确 SKU、资源、库存、预约和订单之间的关系，价格与状态才不会在设计和研发之间产生不同解释。
运动项目
羽毛球、匹克球作为不同商品与价格规则存在。
场地资源
每个 SKU 绑定可被预约的具体场地。
日期与时段
以 30 分钟为最小选择与计价单位。
库存状态
可用、少量余位、已预订、售罄分层表达。
预约段
相邻时段合并成一条可管理的预约记录。
附加项与订单
预约、增值项目、备注和优惠共同进入报价。
03 · Key Decisions
四个关键设计决定
用 Resource × Time 棋盘完成横向比较
日期先确定可售范围，场地作为行、时段作为列。用户无需逐个打开场地详情，就能同时比较资源、时间、库存和价格。
固定资源列 · 小时分组 · 周切换 · 月份选择把“库存状态”和“价格状态”拆开判断
售罄由可用库存决定，Peak、Off-Peak、Promo 由定价规则决定。两个维度分别计算，避免把“便宜”误解成“有余位”，也避免从历史订单反推未来价格。
Booked / Sold out / Few left 与价格分别表达相邻时段自动合并，但保留可撤销控制
多个连续 30 分钟时段在购物车中合并成一条预约段，降低信息噪音；用户仍可按场地清除或删除预约段，并获得最多 4 条预约或 8 小时的限制反馈。
连续时段分组 · 上限提示 · 按预约段删除桌面强调扫描效率，移动端强调分步控制
桌面端保留完整时间棋盘；移动端允许横向浏览并固定资源列，同时把订单汇总收进可展开购物车，避免表格与结算信息争夺同一屏幕。
触控滑动 · 固定列 · 移动购物车 · 分步状态条| 状态 | 触发条件 | 界面表达 | 设计目的 |
|---|---|---|---|
| Available | 资源在该时段没有冲突预约 | 显示实际价格并允许选择 | 让用户直接比较成本与可用性 |
| Selected | 用户选择可用时段 | 高对比选中态，同步更新购物车 | 建立即时反馈，减少误选 |
| Booked / Sold out | 单场地冲突或该时段全部资源不可用 | 禁用单元格，并在日期或时间层给出售罄信息 | 区分局部不可用与整体不可用 |
| Few left | 可用资源比例低于设定阈值 | 在场地、时段或日期层提示余量有限 | 帮助用户提前调整选择 |
| Peak / Off-Peak | SKU、日期类型和时间段共同决定 | 价格与标签同时呈现 | 解释价格差异，避免只显示一个孤立数字 |
| Limit reached | 超过 4 条预约或累计 8 小时 | 阻止继续添加并给出明确处理方式 | 把业务限制转化为可恢复的交互反馈 |
04 · AI Collaboration
原型实现中的分工
在可运行 Demo 中验证选场、附加项与费用同步反馈；用 Cursor / Claude 加速交互说明与异常态补齐。涉及业务语义、价格、库存与预约限制的内容，仍由我和产品、研发逐项确认。
工具辅助
整理、生成与重复性实现
- 把初始需求扩展成页面清单、角色问题和异常状态检查项。
- 生成信息架构、交互文案和组件拆解的候选草稿。
- 快速搭建 React + Tailwind 原型并辅助调试重复代码。
- 在评审前检查空状态、禁用态、响应式与文案一致性。
我的职责
业务语义、设计取舍与验收
- 确认羽毛球与匹克球是不同 SKU，而不是同一资源的标签。
- 确认价格来自 SKU 定价、报价和可用性数据，不能由历史销售记录推断。
- 决定棋盘结构、信息优先级、预约上限和移动端交互策略。
- 核对冲突、连续时段、售罄和失败反馈，并对上线质量负责。
涉及业务规则、数据字段、价格、权限和正式环境的内容，都需要经过产品、设计与研发确认后再进入交付。
05 · Delivery Workflow
从需求到上线
DISCOVERY
需求拆解
扩展业务问题、角色、对象和异常状态检查项
INTERACTION
交互方案
生成流程与状态候选，再由业务语义逐项校准
PROTOTYPE
UI 原型
快速生成 React + Tailwind 组件用于可行性验证
IMPLEMENTATION
代码精修
补全选择、冲突、计价、响应式与恢复逻辑
DELIVERY
正式上线
人工验收业务规则后集成平台并进入正式运营
06 · Interactive Prototype
预约流程 Demo
Demo 使用模拟数据，可选择日期、场地和时间段，并继续完成附加项、优惠和确认流程。
DEMO ENVIRONMENT · 数据模拟
07 · Outcome & Reflection
项目结果与复盘
进入真实营业环境
预约体验接入 Pisell 平台，并服务 Rainbow Town 场馆的羽毛球与匹克球业务。
复杂规则形成统一模型
把 SKU、资源、时段、价格、库存、预约与订单关系转化为一致的页面和状态语言。
用可运行 Demo 检查流程
通过实际操作检查选择、冲突、连续时段、附加项目、报价和移动端表现。
复盘：生成速度提高后，更需要认真验收
AI 工具可以帮助扩展场景、生成组件和调试代码，但 SKU 与资源的业务含义、价格来源、库存冲突、预约限制和异常恢复仍需要人工确认。后续会继续补充接口失败、库存变化、支付返回与无障碍测试。
技术实现
AI 工具
ChatGPT — 需求 & 架构
Claude — 交互 & 文档
v0.dev — UI 生成
Cursor — 代码精修
前端技术
React 18
Tailwind CSS
JavaScript (JSX)
响应式布局
核心功能
周历时间轴预约
多场地资源管理
动态定价（峰 / 非峰）
附加项目选购
平台 & 交付
Pisell SaaS 平台
真实客户上线运营
Rainbow Town 场馆
在线支付 & 订单