首页：旅行中控台
整合倒计时、天气、四天概览、景点亮点和快捷工具。用户打开首页即可获得“今天该关注什么”的全局感。
总览与期待感
微信小程序 · 个人项目 · 产品经理作品集
把一次情侣旅行，做成可执行的产品体验。
这是一个围绕黄山四天三晚自驾游设计的微信小程序。我从真实出游场景出发，把“计划分散、临场焦虑、攻略难执行”转化为行程、攻略、地图、清单和记账的一体化体验。
4 天完整旅行路径
6 类核心使用场景
1 个真实需求闭环
旅行计划的核心问题，不是信息不足，而是信息无法在路上被顺手执行。
普通攻略往往停留在“收藏”和“浏览”，但真实出行时，用户需要在时间、路线、天气、门票、物品、花费之间快速做判断。这个项目把一次真实情侣出游拆成可操作的产品任务。
攻略分散，临时查找成本高
景点介绍、路线距离、门票价格、住宿地址和行李清单散落在不同 App 或聊天记录中，旅行当天容易反复切换。
计划漂亮，但执行感弱
传统行程表只告诉用户“要去哪”，缺少进度、勾选、提醒、展开小贴士等真正帮助落地的交互。
情侣出游需要共同感
旅行不只是效率工具，也包含期待、纪念、共同决策和仪式感，所以产品不能只做成冷冰冰的表格。
自驾路线需要空间理解
四天多点位自驾游更关注“今天路径如何串起来”，而不仅是单个景点的百科信息。
围绕“行前准备、途中执行、旅行记录”构建一个轻量闭环。
我将产品定位为情侣黄山自驾游的私人旅行中控台。它不是通用旅游平台，而是服务一次具体出行的高完成度小工具。
行程执行
攻略决策
路线理解
旅行记录
目标用户
🚗
情侣自驾游客
希望行程浪漫，但过程不混乱。
希望行程浪漫，但过程不混乱。
🧭
计划主导者
需要一个清晰工具来承载所有安排。
需要一个清晰工具来承载所有安排。
📱
旅途中使用者
需要低学习成本和强即时性。
需要低学习成本和强即时性。
用户旅程拆解
1期待建立首页展示倒计时、天气、路线亮点，增强出发前确定感。
2行前准备行李清单分类勾选，避免证件、装备、充电器遗漏。
3途中执行按天时间轴推进，勾选完成度，展开小贴士。
4临场决策攻略页聚合景点、美食、贴士和费用，减少查找成本。
5旅行沉淀记录消费、住宿、备忘，为回顾和复盘留下数据。
不是堆功能，而是把关键旅行动作放到对应时刻。
行程：可执行时间轴
每个时间点都可以展开小贴士和勾选完成，顶部展示按天进度，让行程从静态计划变成可操作任务。
执行闭环攻略：决策信息聚合
景点、门票、美食、穿衣、装备和预算集中管理，并支持首页景点跳转高亮，降低信息检索成本。
减少切换地图：路线空间感
按 Day 展示路线 marker 和路段详情，帮助用户理解点位之间的关系，而不是只看文字列表。
路径理解清单与记账
行李清单解决行前遗漏，消费记录解决旅行中的轻量记账，补齐从准备到复盘的工具链。
旅行后勤用低饱和、轻层级和卡片化结构，让工具也有旅行的温度。
界面采用接近 iOS 的浅色系统：柔和 surface、圆角卡片、低饱和选中态、轻量动效。重点不是炫技，而是让旅途中快速扫读、快速点击、快速返回。
这个项目体现的不是“会做页面”，而是从真实需求到产品闭环的拆解能力。
我如何定义 MVP
- 先聚焦一次真实旅行，而不是做泛旅游平台。
- 优先保证高频场景：行程、攻略、地图、清单、记账。
- 数据以本地存储为主，降低开发成本并保证离线可用性。
- 天气采用缓存与降级策略，避免外部 API 失败影响核心流程。
我如何做体验取舍
- 首页不做复杂入口，而是突出旅行状态和快捷工具。
- 攻略不追求百科全量，而是保留会影响决策的信息。
- 地图不直接做导航，而是先解决“路线理解”。
- 视觉避免强刺激选中态，改用低饱和颜色保证长期使用舒适。
可量化的评估指标
- 行前清单完成率：衡量准备工具是否被使用。
- 行程勾选率：衡量时间轴是否支撑真实执行。
- 攻略页跳转/展开次数：衡量首页到决策信息的转化。
- 消费记录笔数：衡量旅行后勤功能是否有实际价值。
项目能力映射
- 需求洞察：从真实出游痛点抽象为产品任务。
- 信息架构：把复杂旅行内容组织成清晰 tab 和页面。
- 交互设计：用勾选、进度、展开、高亮降低操作成本。
- 技术理解：理解微信小程序、本地缓存、地图、天气 API 的实现边界。
从私人旅行工具，迭代为可复用的轻量旅行计划模板。
协同计划支持两人共同勾选、留言和确认关键事项。
真实导航接入路线规划 API，补齐自驾路线的实时性。
旅行回忆旅行结束后生成花费总结、路线回顾和照片纪念页。
模板复用将黄山计划抽象成“多日自驾游”模板能力。