听歌学外文
不是每一个好设计，都需要以最初的形态上线。
刚加入 QQ 音乐时，我一直在思考一件事：QQ 音乐拥有大量优质的全球音乐版权，除了“听”，这些内容还能创造什么新的价值？
小时候，我认为背单词是一件很枯燥的的事情，但我们的英语老师每天早上都会用一首英文歌开始课堂。那时候我并不会觉得自己在“学习”——只是跟着旋律听、唱，却不知不觉记住了单词、发音和表达。所以于是我产生了一个想法：如果一首歌本来就可以帮助人学习一门语言，为什么“学习”不能直接发生在听歌的过程中？
藏在歌里的机会
我把这个想法定义成了 「听歌学外文功能」。
它不是在 QQ 音乐里增加一套传统语言课程，而是把歌曲本身变成学习材料。用户依然是在听一首喜欢的外文歌，只是在播放过程中，可以顺手理解歌词、学习表达，并通过反复听歌加深记忆。对我来说，这个机会的核心不是“做一个学习功能”，而是让通过外文歌学语言的用户，更自然地留在 QQ 音乐的听歌场景里。
第一次提案是在我的转正答辩会上。我先自己完成了第一版概念设计，并基于 QQ 音乐现有播放器的使用习惯，根据线上已有的相近功能点位设计出了第一个版本。
方案被点头之后，现实开始提问
经过几轮讨论之后，整个方案得到了认可。产品经理也联系到了 Duolingo，想要推进下一步联动合作。我也进一步优化方案，我在QQ音乐乐馆功能增加一个学习页面，里面沉淀的是我们配置好的外文歌曲。
用户通过点击直接就进入音乐播放器模式，复杂的词汇支持标记和保存。对于有考学的用户，也可以直接根据词典，选择相对应的歌曲，进行巩固和加深记忆。
但当项目真正进入与 Duolingo 的合作讨论后，挑战开始变得具体。问题主要来自两层：
合作目标不完全一致。 我们希望把「听歌学外文」嵌入 QQ 音乐的核心听歌体验，让用户可以从播放器自然进入学习状态；但在合作讨论中，双方对学习入口的深度、以及学习链路应该承载在哪一侧，有着不同的判断。
内部开发资源不足。 虽然我们的独立学外文播放器可以自己上线。但项目进入落地评估后，需要和当时更核心的业务需求争夺排期。因此，「听歌学外文」并没有足够高的开发优先级。
这也是我第一次非常直接地意识到：
设计方案被认可，和产品真正上线，是两件完全不同的事情。
缩小，但不缩水：留下最不能丢的那一点
这个时候，我没有继续坚持一定要上线完整的「学外文播放器」，却重新拆解了整个方案。如果开发资源只能支持其中很小的一部分，那么这个 Idea 最核心的价值到底是什么？
答案并不是播放器本身，而是： 让用户在音乐场景里，用一种更轻、更有趣的方式接触和学习外文。
于是，我们开始寻找一个已经存在、开发成本更低，同时又适合承载这个体验的场景。最后，我们选择了 QQ 音乐端内已有的 猜歌玩法。
它没有按原样上线，但真的发生了
原本完整的深度学外文方案被缩小成一个更轻量的功能切口，并最终真正进入了线上产品。
我也很开心，我们和 Duolingo 的联动合作顺利进行。多儿作为“音乐人”入住了我们的音乐人页面，并且发了新歌；多儿也以陪伴小人的方式，在 QQ 音乐里陪伴很多外语学习者。
我最后守住的，不是一个播放器
如果只看最终上线的形态，它和我最初设计的「听歌学外文播放器」已经非常不同。
但这次经历让我开始重新理解“落地”。落地并不一定意味着让最终产品和设计稿一模一样。更多时候，它意味着在用户价值、产品目标、开发资源和业务优先级之间不断做选择。
一个设计师真正需要坚持的，也不一定是某一个界面或者某一种交互形式，而是知道什么是这个 Idea 最不能被牺牲的部分。
我最开始想推动的是一个播放器。最后真正上线的，只是其中一个小小的点位。
但它让我第一次完整经历了：发现机会 → 主动提出 Idea → 设计方案 → 推动产品 → 面对资源限制 → 缩小 Scope → 找到新的落地点。
更重要的是，让一个想法在现实的限制里，仍然有机会发生。