petstore-docs/宠主端预约体验优化-产品说明.md
2026-04-18 21:39:26 +08:00

5.6 KiB
Raw Blame History

宠主端(客户版)预约体验优化 — 产品说明

目标:围绕「想给宠物做洗护/美容」的真实动机,缩短从打开小程序到提交预约的路径,降低决策与操作成本。
现状对齐:宠主角色首页为「服务预约」列表 + 状态 Tab + 右下角「+」 进入 CustAppointmentCreate(门店、宠物、类型、服务、时段、备注)。


1. 典型进入场景(先对齐人怎么来)

场景 用户心智 当前易卡点 优化方向(产品层)
A. 主动搜小程序 记得店名/品牌,想约服务 首屏是列表,「+」在角落,新用户未必第一眼发现 首屏强化主行动:大按钮「预约服务」与 FAB 二选一或主次分明
B. 微信聊天里点小程序卡片/分享 被朋友或店员推荐 若落在首页,路径同 A无登录态需先登录 明确分享落地页:能否直达「新建预约」或带默认门店
C. 扫门店码 / 桌贴 人在店附近或已到店 期望默认就是本店,少选一步 扫码参数带 storeId → 预约页预填门店且可折叠展示「本店」
D. 看完服务报告 / 海报再来 信任已建立,想复购 从报告链路过来的深链若只到首页,打断情绪 报告页 CTA「为 TA 再约一次」 → 带宠物名/门店进预约(字段能预填则预填)
E. 老客复约 同宠、同店、同类服务 每次重填信息易烦 默认选中上次门店+宠物档案+常用服务;一键改时间即可提交

结论:优化不是单页微调,而是 入口(怎么进)+ 首屏(第一眼干什么)+ 表单(填什么、默认什么) 三条线一起收紧。


2. 首屏信息架构(宠主首页)

问题:列表 + Tab 偏「管理已有订单」,新用户动机是先下单,容易感到「还没约就要先看列表」。

建议

  1. 分区:上区 「我要预约」主按钮(或保留 FAB 但配一句固定文案「点这里新建预约」首次引导);下区才是「我的预约」与 Tab。
  2. 文案:副标题从纯说明型改为价值型一句,例如「在线选时段,到店不排队」(需与门店真实规则一致,若未做排队逻辑则弱化)。
  3. 空列表:空态时 主按钮置顶,避免「空白 + 小加号」的冷启动挫败。

3. 新建预约表单(CustAppointmentCreate)— 减少步数与记忆负担

字段逻辑(保持业务真实):门店、宠物、类型、服务、时段为核心;备注可选。

优化建议

方向 说明
门店 若仅一家合作店或扫码带店:默认选中且可折叠(「预约门店:××店 [更换]」),减少首屏高度。多店时保留选择器。
宠物 已有「我的宠物」时:默认最近使用的一只;单宠自动填名。无档案时仍手动输入,但可提示「保存后可下次一键选」。
服务类型 常用服务前置(根据上次预约或门店热门 Top3其余进「更多」。
时段 保持日期 + 时段联动;无可用时段时明确文案(「当日已满,试试明天」)+ 快捷切日,避免空白不知所措。
提交 主按钮固定底部或表单末;防重复提交与 loading 已有则保持;成功页 一行确认(时间、店名、宠物)+ 「查看预约」+ 「再约一单」可选。

4. 登录与身份(体验关键)

  • 规则需产品拍板:未登录是否允许浏览首页 / 是否必须登录后才能预约。
  • 推荐:允许浏览空首页或极简介绍,点击「预约」再调起登录(减少第一步就挡人)。若业务强制登录,则首屏主按钮下直接说明「登录后即可预约」。
  • 登录后 回到预约页并保留已填内容(避免白填)。

5. 与 Tab /「我的」的关系

  • 首页 Tab(待开始/服务中/已完成):适合老客查进度;新客可弱化认知成本,用文案「下面可查看已提交的预约」。
  • 我的:宠物档案、历史报告(若已开放)与预约形成闭环;产品上可规划 「从档案一键预约」,减少重复录入。

6. 分期建议(便于研发排期)

阶段 内容 价值
P0 首屏主按钮 + 空列表强引导;扫码/参数 storeId 预填门店;登录时机与返回栈 最快降低「找不到入口」和「多店选错」
P1 默认最近宠物/最近服务;时段不可用时的引导 提升复购与填单效率
P2 报告/海报深链「再约一次」;常用服务排序 与增长、留资主线联动

7. 验收关注点(非功能清单)

  • 新用户:首次打开 → 能在 2 次有效点击内到达可提交的预约表单(含必要登录)。
  • 老用户:复约场景下,门店+宠物默认正确率主观可用(可后续用数据验证)。
  • 异常:无时段、未登录、网络失败均有可理解提示,不出现静默失败。

8. 相关文档

  • 《产品设计文档》§5.2 预约、第二章闭环。
  • 《产品改进建议》「宠主端缺失」「自助预约 + 门店确认」中长期方向。
  • 实现以当前 Home.vue / CustAppointmentCreate.vue 为基线迭代,具体路由与参数名由研发定

本文为产品侧交互与信息架构建议,定稿后与研发评审可行性(尤其小程序分享落地、扫码参数、登录态)。