同好发现
通过城市、标签和活跃度找到适合自己的群体。
0→1 GAME UX · SOCIAL SYSTEM · MOBILE
从一次跳舞
到持续归属
从 0 到 1 设计 JDM 舞团系统
通过同好发现、组织身份、成员连接与共同目标， 将碎片化的体感游戏体验延伸为持续参与。
UX & Interaction Design: Jay Liu
Final Visual Design: UI Artist
30 秒速览 · 我的责任与关键判断
从玩家问题、设计取舍到实现过程
- 玩家问题
- 有了成员身份与共同进度，仍不一定感到“正在一起参与”。
- 我的责任
- 18 人子团队中唯一 UX，负责舞团系统从 0 到 1 的体验设计；与策划、UI、动效及工程协作。
- 关键取舍
- 实时反馈不锁操作；离线用摘要而非逐条回放；统一教学、升阶与领取的表现时序。
- 项目进展
- 舞团基建于 2026 年 7 月 2 日上线；存钱罐于 2026 年 9 月 23 日上线。
主动提出的3个体验方案
02 / CONTEXT
JDM 为什么需要舞团？
Just Dance Mobile（JDM）是一款娱乐化的移动体感游戏：跳舞是形式，运动与燃脂是结果， 快乐、轻松和低门槛是核心优势。
用户可能为了 IP、跳舞、燃脂、放松或新鲜内容而来。 他们的社交意愿也不同：有人主动寻找同好，有人只接受轻互动， 也有人不希望社交成为跳舞前的必要条件。
舞团的目标不是把 JDM 变成社交 App，而是为核心体验增加一层 非强迫、可持续的群体关系。
CORE EXPERIENCE
轻松跳一跳
低门槛移动体感
→
USER TENSION
缺少搭子与动力
碎片体验难以持续
→
GUILD OPPORTUNITY
同好与共同参与
关系 · 归属 · 回访
身份归属
用组织信息、成员角色和荣誉建立稳定认同。
共同目标
让不主动聊天的玩家也能通过贡献参与协作。
玩法连接
将成员关系导向好友、家园、邀请与多人玩法。
03 / MY ROLE
作为子团队中唯一的 UX，
我负责了什么？
我负责舞团基建的 0→1 UX 设计，并为 OB3 版本设计存钱罐共同玩法。 与 UI Artist、Game Designer、工程、QA、PM 和 Producer 协作推进落地。
OB · 2026.07.02舞团基建查找与加入、创建、成员管理、邀请等。后文复盘数据来自这一版本的基建埋点。
OB3 · 2026.09.23舞团存钱罐共同玩法、协同领取、分层 FTUE 与动效设计。
1 / 18
唯一 UX Designer
嵌入 18 人跨职能团队；JDM 整体项目规模 140 余人。
- 将产品和玩法需求整理为完整信息架构
- 建立未加入与已加入玩家的整体旅程
- 设计发现、创建、申请、邀请和管理流程
- 梳理多角色权限与大量边界状态
- 输出低保真原型、交互规则及 UX Specification
- 主动提出 Coin Bank 协同领取、FTUE 与动效方案
- 上线后分析 OB 数据并进行体验复盘
04 / CHALLENGE
设计问题不止“做一个舞团页面”
如何为社交意愿不同的玩家，建立一个低压力但可持续的组织体验？
用户不是都为了社交而来
舞团不能要求玩家先成为“社交型用户”才能获得价值，而应允许玩家选择参与深度。
USER RESEARCH SYNTHESIS
IP跳舞燃脂放松游戏内容
独自体验
轻互动
主动社交
加入背后是复杂组织规则
直接加入、申请、邀请、容量和多角色权限需要形成可预期的统一状态体系。
GDD RULE MAPPING
直接加入申请审核好友邀请
团员管理员团长
容量 · 数量上限 · 审核 · 退出 · 转让 · 解散
成员身份不等于共同参与
组织需要关系入口、共同目标与持续循环，让不聊天的玩家也能感受到其他成员。
EXPERIENCE GAP ANALYSIS
加入舞团获得成员身份
≠
共同参与产生回访理由
成员关系→共同目标→持续回访
05 / SYSTEM THINKING
从功能清单到参与深度
我没有按页面逐项设计，而是把入口、规则和共同玩法重新组织为一条完整的社交生命周期。
- 01看见入口 · 资料 · 邀请
- 02判断推荐 · 搜索 · 详情
- 03加入直接 · 申请 · 创建
- 04归属主页 · 身份 · 角色
- 05轻量参与浏览 · 贡献 · 领取
- 06主动互动聊天 · 好友 · 多人玩法
核心判断
系统价值不只发生在“成功加入”，而发生在玩家能够逐步加深参与的过程中。06 / DESIGN DECISION 1
加入舞团之前，
先看是否适合自己
PROBLEM
单纯的名称列表不足以建立信任，逐个打开详情又会提高判断成本。
SOLUTION
把关键判断信息前置
推荐承担默认发现；搜索与筛选服务明确目标；好友邀请为已有关系提供最低摩擦路径。
I surfaced the information players need before asking them to commit.
07 / DESIGN DECISION 2
在加入效率与
组织控制之间取得平衡
直接加入
服务开放舞团，减少等待和操作成本。
申请审核
为管理者提供成员构成的必要控制权。
好友邀请
利用已有关系缩短发现、判断和信任过程。
ONE SYSTEM, MANY STATES
把边界状态变成可执行规则
- 舞团满员与玩家数量上限
- 重复申请与等待审核
- 拒绝、失效与权限差异
- 退出、转让与解散
明确的规则不仅服务玩家，也让工程和 QA 能够共同覆盖复杂状态。
08 / DESIGN DECISION 3
OB3 · 舞团存钱罐
用共同目标把成员身份
转化为持续参与
Coin Bank 不是独立的领奖页面，而是舞团从“组织容器”变成“共同参与空间”的关键机制。
1个人行为完成活动与贡献
→
2舞团进度成员价值变得可见
→
3阶段成长共同目标被推进
→
4奖励领取阶段成长对应奖励
设计稿通过评审、进入开发后，我在程序演示的功能占位版本中发现：虽然数值由全团共同推进，界面却很难让玩家感受到其他成员。这成为我重新检查体验、主动补充方案的起点。
我主动提出三个体验方案
方案经 Producer 与 Game Designer 评审认可后进入 UI、Motion 和 Engineering 执行。
协同领取
让他人的领取可见，让进度变化有解释
不改变奖励规则，也不要求多人同时操作；只补充他人领取的实时反馈与离线期间的变化摘要。
- 让共同参与有可感知的线索
- 解释进度跳动与阶段变化
- 提示播放期间仍可正常操作
FTUE
首次理解循环，升阶再学奖励
第一层解释金币来源、领取价值与日常行动；第二层在升阶后解释当前奖励状态。
- 不把点击简单等同于理解容易
- 不提前灌输整套结算规则
- 教学随实际阶段切换分支
动效与包装
让共同成长被真正感知
定义贡献进入、阶段成长和领取的反馈目标与播放优先级，让强包装同时服务情绪和状态理解。
- 数值变化转化为可感知成长
- 提升共同达成的情绪强度
- 避免多重反馈互相打断
DEEP DIVE / 01 · 协同领取反馈
让共同参与，
从数值变成可见的体验
不改奖励规则，不要求多人同时操作。补足的是他人参与的线索，以及进度变化的解释。
发现问题
有全团进度，却像在独自领奖
设计评审通过后，我在开发占位演示中发现两个体验缺口。
看得到金币，看不到其他成员
流程能跑通“活跃—攒钱—领奖”，但共同参与缺少可见的线索。
进度变了，原因却不可见
他人领取可能推动进度甚至升阶，需要解释“谁带来了变化”。
原始低保真用于标示问题位置；体验缺口来自开发演示中的观察。
实时反馈
把“谁领取了多少”带回界面
关键反馈 · 高保真局部
谁参与了做了什么贡献多少
只提示他人自己的领取不重复提示
每条 3 秒多条领取依次展示
不锁操作玩家仍可继续交互
查看中断与退出规则
界面出现新的动效演示时打断提示队列；离开功能则结束展示。不把“提示先后顺序”解释为必须等队列播完才能操作。
离线反馈的取舍
回来先看摘要，而不是补看一串提示
原设想 / 未采用
逐条补播离线记录
讨论后采用
变化摘要＋攒钱簿入口
先了解共同进展，需要时再查记录。
后端存储负担前端长队列处理同人多条记录合并成本
图示为 UI 设计稿与局部细节，数值均为设计示例；流程图概括了从逐条回放到摘要呈现的取舍。
为什么不逐条回放？
支撑离线回放的后端存储负担较高，前端还需处理长队列。同一玩家可单个或多个领取，合并多条记录又增加实现复杂度。因此采用变化摘要与记录入口，玩家需要时仍可查阅领取记录。
DEEP DIVE / 02 · 渐进式 FTUE
不是一次教完，
而是在需要时，让规则变得有意义
领取只需一次点击，理解却跨越了“今天的行为、次日的金币和之后的阶段奖励”。我把首次引导拆成两层：先建立参与理由，再解释真实发生的成长。
体验风险
奖励后置，玩家可能会领金币，却说不清为什么要持续参与。
同事走查
不同游戏熟练度的同事参与了小规模走查，多数人未能迅速理解占位版本的玩法。这进一步支持了对理解门槛的判断。
首次进入 · 三步建立认知
顺着画面，从“这是什么”到“我能做什么”
01
是什么
先解释金币来源与领取时间，连接今天的行为和明天的回报。
02
为什么值得领
把领取与共同进度、礼盒升级联系起来，而不只教一个按钮。
03
接下来做什么
最后落到比赛、社交、登录与在线，让参与理由对应具体行动。
顺序取舍：先说明价值，再给出行动；焦点按界面上—中—下移动。点击任意位置推进，完成三步后结束第一层。
查看 UX 低保真过程稿与设计分工
低保真用于说明信息分层、引导位置和顺序；最终视觉采用 JDM 的 FTUE 组件。UX 与交互规则：Jay Liu；UI 高保真：UI Artist。
升阶后 · 单步解释当前状态
让奖励规则，接在玩家看见的变化之后
不提前讲还没发生的事
第一层只建立“领取会推动成长”。升阶发生后，再结合演出解释奖励变化，避免首次进入就记住整套结算规则。
升阶演出→对应阶段的单步说明
第二层仅在尚未完成时触发，并根据玩家到达的阶段选择对应说明。
常规升阶 · 阶段 2
直达阶段 3 · 文案分支
如果首次进入已是阶段 2／3，或恰逢结算？
- 首次已到阶段 2／3
- 保留第一层基础认知，阶段描述匹配当前状态；随后衔接对应升阶演出及第二层分支，不把玩家当作仍处于阶段 1。
- 首次进入遇到周结算
- 先走正常结算流程；第二层教学留到下一个满足条件的阶段，不强插到结算中。
- 第一层期间他人领取触发升阶
- 先完成当前引导，再衔接升阶演出与第二层说明，避免教学中途切换玩家正在理解的状态。
DEEP DIVE / 03 · 动效与时序
不只是让存钱罐动起来，
而是让变化有顺序、可理解
先判断每项动效对玩家体验的作用，再处理教学、升阶和他人领取同时发生时的顺序。前者决定为什么做，后者决定如何衔接。
让主链路成立
承担领取、进度、升阶与结算的核心表现，保证玩法预期体验的基础。
例如：阶段升阶
把进度达标呈现为存钱罐成长，连接新的奖励阶段。
缺少这层表现，玩家可能只看到数值变化，难以感知共同目标已经达成。
P0 · 13 项让体验更完整
不是主链路成立的绝对前提，但明显增强玩法的表现完成度。
例如：金币生成出现
让新金币的出现有可感知的过程，而不只是静态增加一个对象。
缺少这层表现，领取流程仍能继续，但金币出现的变化感会更弱。
P1 · 3 项让等待也有反馈
在玩法主链路之外，服务界面活跃、情绪表达与交互流畅度。
例如：未生成金币倒计时提示
在等待期间提供轻量的动态线索，不与领取和升阶争夺注意力。
缺少这层表现，核心领取与结算仍成立，但等待状态会更静态。
P3 · 3 项19 项动效均已实现。三类说明解释各项动效的体验作用；P0 / P1 / P3 是制作优先级，实际播放顺序见下方时序设计。
一个真实需要处理的冲突
玩家还在学阶段 1，舞团已经升到阶段 2
首次进入时已看到阶段 1；第一层 FTUE 尚未结束，另一位成员领取金币，触发了升阶。
服务器真实状态玩家看到的表现按事件顺序示意 · 非等比例时间轴
-
01 / 进入并同步
数据阶段 1记录进入时的阶段与进度表现第一层 FTUE先建立玩法认知
-
02 / 他人领取
数据阶段 1 → 2真实数据持续更新表现继续完成 FTUE暂不刷新进度，不插入 Toast
-
03 / 完成第一层
数据读取最新状态本例最终到达阶段 2表现升阶 → 第二层 FTUE先感知成长，再理解新奖励
-
04 / 释放累计反馈
数据对齐最终进度结算独占流程期间的累计变化表现累计进度 → 协同提示不重复播放已经表达的跨阶增长
延后的是表现，不是真实数据。连续的 FTUE 与升阶演出之间不释放协同队列；进入协同提示后，玩家仍然可以操作。
把状态衔接落到画面
先理解玩法，
再感知成长，
最后解释新奖励
用三个真实设计画面，对照上面的表现顺序。
以下以静态 UI 设计稿说明三个关键状态；画面数值为示例，三图不对应同一次游戏会话。
结算正确 ＞ 动画完整
连续领取时，数字和进度可直接追到最新目标，不必逐次补播微小变化。
本人反馈 ＞ 远端表现
他人领取引起的进度动效更轻；本地操作覆盖远端动画，从更新后的进度继续。
协同提示不锁操作
实时提示每条 3 秒；新动效打断队列，离开功能则结束展示。
查看播放顺序与 4 种特殊情况
第一层 FTUE → 升阶演出 → 第二层 FTUE → 升阶后界面 → 延迟的累计进度 → 协同提示
- 进入时已跨过多个阶段
- 非首次返回，从阶段 1 跨至阶段 3，只播放最终到达阶段 3 的演出，不逐阶补播。
- 周期重置：阶段 3 → 1
- 直接呈现新周期阶段 1，不当作升阶处理。
- 离线期间发生多次领取
- 通过攒钱簿入口和气泡摘要表达增长与新增记录数，不回放离线 Toast 长队列。查看协同领取取舍 ↗
- 协同提示被新动效打断
- 新动效会打断协同提示队列；离开功能时结束展示。
查看 19 项动效的具体内容
P0 / 13 项核心体验
- 漂浮金币待领取提示
- 单金币领取
- 入罐数值增长
- 少量金币存入（<10）
- 较多金币存入（≥10）
- 本地领取进度增长
- 远端领取进度增长
- 阶段达标强调
- 阶段 1 → 2
- 阶段 2 → 3
- 结算入场
- 结算礼盒点击反馈
- 结算礼盒开盒
P1 / 3 项体验增强
- 金币生成出现
- 礼盒不可开启反馈
- 存钱罐点击趣味反馈
例如：点击趣味反馈在制作上属于 P1，但在运行中优先级最低，冲突时可随时打断。
P3 / 3 项氛围与弱提示
- 未生成金币倒计时提示
- 一键领取按钮按压
- 一键领取批量金币收集
我的工作：按玩家体验作用定义动效层级、目标与制作优先级，并梳理触发、打断、状态追赶和统一时序；与策划、程序及表现团队对齐实现。
实现与验证：19 项动效均已实现，时序初步走查未发现明显问题。存钱罐已于 2026 年 9 月 23 日上线，完整体验与参与表现仍待后续观察。
设计材料：动效需求与时序说明。UX 与交互规则：Jay Liu；高保真视觉：UI Artist。
UX concept, interaction model, FTUE structure & motion requirements: Jay Liu
Visual and implementation execution: UI, Motion & Engineering
IN-GAME WALKTHROUGH / 舞团基建
从界面方案，
走进真实操作
创建舞团、筛选同好，再进入成员列表。通过连续操作，查看入口、选择与状态反馈如何串联成完整体验。
本段仅演示舞团基建，暂不包含存钱罐功能。
09 / FINAL EXPERIENCE
最终体验：
从找到舞团，到共同成长
把前面的设计决策放回完整体验：先找到适合自己的舞团，再进入团内日常，最后通过存钱罐参与共同目标。
舞团基建 / OB · 2026.07.02
先判断适不适合，再决定加入
从列表的初步筛选，到详情里的进一步了解，再到清晰的申请状态。
- 发现舞团
- 了解成员与组织信息
- 发起申请并查看状态
舞团基建 / OB · 2026.07.02
同一个舞团，服务成员与管理者
成员从主页进入团内日常；管理者通过组织资料、成员列表与申请审核维护舞团。
成员日常 查看舞团信息 · 认识成员管理者工具 编辑资料 · 管理成员 · 审核申请
以上为角色与状态示例；管理主页稿中的存钱罐入口属于 OB3 扩展，非 OB 基建首发内容。
舞团存钱罐 / OB3 · 2026.09.23
把日常活跃，变成共同成长
个人领取推进舞团进度，他人参与变得可见，阶段达成连接到明确的奖励反馈。
- 积累与领取
- 看见他人参与
- 达成共同阶段
- 领取奖励
10 / POST-LAUNCH REVIEW
舞团基建上线后，
我们观察到了什么？
复盘对象：2026 年 7 月 2 日 OB 推出的舞团基建。
以下为 OB 舞团基建的行为观察，不包含 OB3 存钱罐。好友分组、加入尝试和加入后 24 小时社交三项统计截至 2026 年 8 月 5 日，分别按玩家或加入记录计算。
FRIEND GROUPS · 玩家分组
17.39%有好友玩家中的舞团加入比例
无好友玩家4.39%
在各自达到 Lv6 的玩家组内，计算曾成功加入舞团的人数占比。两组按玩家去重，展示的是分组差异，而非改版前后变化。
这让我更关注没有现成社交关系的玩家：在加入前，他们需要哪些信息来判断一个舞团是否适合自己？
JOIN ATTEMPTS · 加入记录
6.87%加入尝试中的成功记录占比
成功加入记录 ÷ 全部加入尝试记录，包含直接加入与申请审核。同一玩家多次尝试会重复计入。
这个比例提示我继续检查失败原因、审核等待与状态反馈，定位加入过程中可以改善的环节。
AFTER JOINING · 加入后的互动
6.56%加入后 24 小时内发生社交的记录占比
每条成功加入记录作为一次观察；随后 24 小时内发生舞团聊天、添加舞团好友或家园拜访，即计为有社交。同一玩家可有多条加入记录。
因此，我把新成员加入后的第一步互动列为后续设计重点，而不只关注是否成功加入。
11 / REFLECTION
组织结构只是容器，
关系发生才是目标
完成系统结构只是第一步
组织价值不来自成员数量，而来自成员是否拥有再次回来和共同参与的理由。
社交不应该只用聊天衡量
浏览成员、贡献共同目标、拜访家园、添加好友和多人玩法，都是更自然的关系起点。
下一步是新成员激活
欢迎与第一步引导、推荐可互动成员、共同活动、快捷回应，以及审核等待兜底。