信息分散 Fragmented Information
旅行灵感、地点、攻略链接和成员意见分布在多个平台中,组织者需要反复复制、转发和整理。
概念与高保真原型 · Concept & High-fidelity Prototype
昆士兰大学 · 五人团队课程项目 · 2026.03—2026.05
让多人旅行规划,
从反复沟通变成共同决策。
From fragmented discussions to shared travel decisions.
Together 是一个面向多人旅行场景的协作规划平台。它将分散在社交媒体、群聊、地图和备忘录中的旅行信息集中到同一空间,帮助成员共同收集灵感、讨论方案、完成决策并维护统一行程。

本页依据项目书整理。项目仍处于概念与高保真原型阶段,研究和测试用于验证方向与发现交互问题,不代表真实市场表现。
多人旅行中,真正困难的通常不是找到景点,而是让不同成员围绕时间、预算、兴趣和路线形成一致方案。旅行成员往往需要在社交媒体、群聊、地图、攻略平台、备忘录和行程工具之间反复切换。信息虽然丰富,却缺少统一的组织方式;讨论虽然频繁,却难以沉淀为明确结果。Together 希望将这些分散的信息与协作行为集中到同一个旅行空间中,让多人旅行规划从一场难以追踪的群聊,转化为清晰、透明且可共同维护的决策过程。
核心挑战:如何在不增加额外协作负担的前提下,让不同成员都能够参与旅行规划,并将分散的建议、讨论和分歧转化为一份所有人都能理解和确认的 统一行程?
我在项目中担任项目负责人、概念发起人和产品设计角色,主要负责:
多人旅行真正困难的并不是找到更多攻略。当不同成员分别在社交媒体、群聊、地图、备忘录或文档之间切换时,信息会不断增加,但规划过程却越来越难以追踪。
旅行灵感、地点、攻略链接和成员意见分布在多个平台中,组织者需要反复复制、转发和整理。
当内容离开原始讨论场景后,成员很难判断是谁提出、为什么加入、是否已经确认,以及它与哪一天的行程有关。
群聊能够产生大量意见,却缺少明确的状态、负责人和最终结果,讨论很容易停留在“大家觉得怎么样”。
计划发生变化后,旧截图、旧文档和历史消息仍然继续流通,成员难以判断哪一份才是当前有效版本。
我们重新定义了问题:用户缺少的不是更多旅行信息,而是一套能够帮助多人共同形成决策并维护统一行程的规划机制。

为了理解多人旅行规划中信息如何流转、分歧如何产生,以及组织者为什么承担大量额外工作,我们围绕真实规划行为开展了用户研究。研究目的不是证明产品已经有效,而是识别反复出现的行为模式,并为产品方向和功能优先级提供依据。
本次研究主要用于识别行为模式、验证问题方向和发现交互问题,研究结果具有方向性,不代表统计意义上的广泛用户结论。
用户保存的地点和攻略往往只剩下一条链接,缺少推荐人、加入原因、适合日期、相关成员意见和当前状态。
设计影响每一条旅行内容都需要保留来源、贡献成员、相关日期、讨论记录和决策状态。
成员能够在群聊中表达意见,但随着消息增加,用户很难重新找到某个地点的讨论过程和最终结论。
设计影响讨论需要绑定具体地点、活动或行程项目,并能够进一步转化为投票、确认或加入行程等结果。
传统行程表能够呈现时间安排,却难以解释为什么做出某项选择、哪些成员仍有异议,以及最近发生了什么变化。
设计影响评论、投票、变更记录和成员状态需要与具体行程对象保持关联。
如果创建旅行时一次要求填写预算、饮食、兴趣、住宿和节奏等大量信息,用户容易在真正开始规划前退出。
设计影响首个创建步骤只保留目的地、日期和成员等必要信息,其余偏好可在后续逐步补充。
核心 Persona 是一位正在组织毕业旅行的大学生。她需要与四位朋友共同确定地点、路线和活动,但大部分信息整理、进度确认和成员提醒最终都落在她一个人身上。她真正需要的不是另一个攻略平台,而是一个能够让所有成员参与、理解并确认规划结果的共享空间。
通过访谈、问卷和规划行为观察,理解多人旅行规划中的信息、沟通与决策问题。
“We discussed many options, but never made a final plan.”
讨论很多,却迟迟无法形成最终计划。
“I saved places in different apps and could not find them later.”
旅行灵感分散在不同平台,后续很难找回。
“After every itinerary update, I was unsure which version was latest.”
行程修改后,成员难以判断最新版本。
“Some members rarely replied, so the organiser made most decisions.”
成员参与度不同,组织者承担大量协调工作。
信息分散
沟通反复
偏好难统一
版本混乱
用户真正需要的不是更多旅行信息,而是一套能保留上下文、沉淀讨论并形成统一结果的共同规划机制。
Users need a shared planning mechanism — not more travel content.
将研究洞察转化为典型用户画像,明确其目标、行为、痛点和核心任务。
当我和朋友一起规划旅行时,我希望所有建议、讨论和最终决定都集中在同一个空间,这样我们可以更快形成一致方案,而不需要反复翻找聊天记录。
When planning a trip with friends, I want all suggestions, discussions and final decisions to stay in one shared space, so that we can reach an agreement faster without repeatedly searching through chat history.
项目早期,团队曾围绕 AR 地点发现、旅行打卡、游戏化挑战和互动地图等方向展开探索。这些方案能够让旅行体验更有趣,却没有直接解决多人旅行中反复出现的核心问题:信息分散、意见难以对齐,以及讨论无法转化为统一结果。
有趣,但没有回答信息分散、意见难对齐和讨论难沉淀的问题。
围绕多人旅行中的协作与决策层建立 MVP 闭环。
为了收敛方向,我们重新评估每个概念:它是否解决了高频且真实的问题?它是产品核心价值,还是体验层功能?用户是否愿意为它改变现有规划习惯?它是否能够形成清晰、可验证的 MVP?最终方向从“让旅行更有趣”转向“让旅行更容易一起规划”。
我们没有继续把 Together 设计成一个功能更丰富的旅行平台,而是将产品聚焦为多人旅行中的协作与决策层。
Together 的产品策略并不是将所有旅行功能集中到一个 App 中,而是围绕多人协作中最关键的四个动作建立闭环:Collect → Discuss → Decide → Sync。
成员可以将候选地点、餐厅、活动、住宿和攻略链接保存到同一个旅行空间,避免信息散落在不同平台。
评论直接绑定具体地点、活动、路线或行程项目,确保讨论始终保留语境。
当成员存在分歧时,可以针对具体方案发起投票、表达选择和理由,并将讨论转化为可追踪的结果。
确认后的地点和方案会进入共同维护的行程中,所有成员看到同一版本,并能够理解最近发生的更新。
Together 的地图用于帮助成员理解地点分布、每日路线和行程距离,而不是替代专业地图工具的实时导航能力。
只有当评论与地点、活动和行程项目保持关联时,讨论才能被重新理解和转化为下一步动作。
投票的价值不在于提升互动数量,而在于帮助团队确认结果,并将决定同步到统一行程中。
团队偏好和智能推荐属于辅助能力,不是 Together 的核心差异化。系统可以帮助降低搜索和筛选成本,但最终安排仍然需要由旅行成员共同确认。
我们围绕“信息如何进入旅行空间、成员如何参与讨论,以及决定如何进入统一行程”组织产品结构。Together 的信息架构包含五个主要模块:首页 Home、旅行空间 Trip Space、灵感 Inspiration、行程 Plan、我的 Profile。其中 Plan 是顶层模块,Map 是 Plan 内部的空间规划能力,包含日程时间线、协作编辑、地图与路线、评论与投票、版本更新。
Information Architecture & Key User Flows
展示 Together 的产品模块结构,以及多人旅行规划的三条核心路径。
Information Architecture
Key User Flows
Product Logic · 产品逻辑
Together 将分散的旅行规划动作,组织为一条连续的多人协作工作流。
产品结构并不是按照单个旅行工具进行拆分,而是按照多人共同完成规划的过程组织。灵感进入旅行空间后,需要经过讨论、决策和同步,最终成为统一行程的一部分。

Together 的核心体验围绕多人共同完成旅行规划展开。产品并不试图替代社交媒体、群聊或专业地图,而是将候选信息、成员讨论、决策状态和统一行程连接在同一协作空间中。以下界面展示了用户如何创建并进入共同旅行、收集候选灵感、查看协作进度、围绕具体地点展开讨论、通过投票处理分歧,并将确认结果同步到统一行程与地图路线中。

先填写目的地、日期和成员等必要信息,让用户能够快速开始,再逐步完善团队偏好。

统一保存候选地点、攻略链接、餐厅和活动,并保留内容来源与贡献成员。

以时间线组织每日计划,让所有成员共同查看和调整统一行程。

将评论和成员意见绑定到具体地点或方案,帮助讨论形成明确结果。

针对存在分歧的方案发起投票,并将结果同步至统一行程。

结合日期和地图查看地点分布与每日路线,支持空间层面的方案比较。

收集成员的预算、饮食、兴趣和旅行节奏,为候选方案筛选提供辅助参考。

集中展示当前旅行、待处理决策和最近更新,帮助用户快速进入正在进行的规划任务。

将旅行成员、当前进度、候选内容和最近动态集中在同一个协作空间中。
当旅行信息、成员讨论和决策结果集中在同一个空间时,多人旅行中的重复沟通和版本确认负担有机会被降低。
这是需要通过可用 MVP 与真实旅行团队任务测试进一步验证的设计假设,当前项目资料尚不足以证明该结果。问题早期首页同时展示推荐、行程、地图、动态和社交信息,导致页面重点不清,用户难以判断下一步应该处理什么。
调整将首页重新定义为旅行入口和行动中心,优先展示当前旅行、待处理决策和最近更新,减少与当前任务无关的信息。
设计价值帮助用户更快理解当前规划状态,并进入需要处理的协作任务。
问题早期创建流程要求用户一次填写预算、饮食、兴趣、住宿和旅行节奏等大量偏好,增加了开始规划前的操作负担。
调整首个步骤只保留目的地、日期和成员,其余偏好在加入旅行后逐步补充。
设计价值降低首次创建门槛,同时保留后续个性化规划所需的信息。
问题用户能够看到地图地点和日程内容,却不容易理解某个地点对应哪一天,以及路线变化如何影响行程。
调整选择某一天时,地图同步展示当天路线;选择地图地点时,对应的行程项目同步高亮。
设计价值帮助用户同时理解时间安排与空间关系,降低路线规划过程中的认知负担。
问题独立讨论区容易再次变成一个缺少语境的群聊,用户很难判断某条意见对应哪个地点或方案。
调整评论和讨论直接绑定地点、活动、路线或行程项目。
设计价值让讨论保留完整语境,并能够继续转化为投票、确认或行程更新。
问题用户能够看到成员意见,却无法判断讨论是否已经结束,以及当前方案是否已经进入行程。
调整为旅行内容增加待讨论、投票中、已确认、已加入行程、已取消等状态。
设计价值让成员快速理解当前进展,减少重复询问和版本确认。
通过这个项目,我对协作产品的理解从“让所有人都能编辑”,转变为:真正有效的协作,需要统一的信息对象、清晰的成员状态、可追踪的讨论语境,以及将不同意见转化为共同结果的决策机制。
项目早期探索了 AR、游戏化和旅行打卡等方向,但更丰富的功能并不意味着更完整的产品。明确核心问题、主动放弃非必要方向,并围绕关键场景建立最小闭环,是本项目中最重要的产品决策。
Together 最大的使用门槛可能不是功能,而是用户已经习惯使用群聊、地图和备忘录。因此,产品未来不应强行替代已有工具,而应通过链接快速保存、邀请加入、内容导入和行程导出等方式降低迁移成本。
Together 的目标不是替用户自动完成一份旅行计划,而是让每一位旅行成员都能够参与、理解并确认这份计划。