一、引入产品定义描述（Application Definition Statement）
相信大多数设计师都有过这样的经历：在产品设计过程中，设计师和产品经理不断pk，各抒己见，甚至闹得脸红耳赤、拍桌翻脸，最后项目总结时又因达不到“理想目标“双方深深自责，纷纷表示”缺少交流“。彼此不断pk，交流绝对足够，只是我们缺少有效沟通的工具。如果能在早期建立共识，口水仗爆发的频率就会越少，真正花在产品上的时间也就越多。这一次，我们决定更早地切入，在最开始的产品规划层面，引入“产品定义描述”（关于ap-plication definition statement，请参考《iPhone Human Interface Guidelines》）。

产品定义描述（product definition statement），着重解决三大问题：解决方案、目标受众、产品优势。针对And-roid QQ music，我们与产品经理建立了一个统一的认知：
1、解决方案：移动场景听歌
2、目标用户：android平台用户，大部分是上班族
3、产品优势：随身携带的歌曲列表（收藏夹）和丰富的运营歌曲库
二、细分场景，从场景推导需求，从需求推导设计
从源头的战略层面上建立了统一的认知，我们接下来开展的工作就有根据了。既然核心是解决“移动场景听歌“的问题，我们必须首先弄清楚什么是”移动场景“？移动环境和PC环境差异甚大，碎片时间的使用更为突出。用户一天是怎么活动的呢？每次拿起手机听音乐都是什么时间？上班的公车上、走路、晚上睡觉前？在这些点上用户都会做些什么？简单的脑暴可以罗列各个可能的使用场景，但还比较粗糙。场景的构想需要建立在高度的认知上，这时候用研的切入显得相当关键，用户特征、喜好、使用习惯…对用户越了解，场景就越能贴近真实、越能发现更多的细节。这些都为后续的设计决策提供了有力的依据。
客观构建的场景有很多有意思的发现：
1. 在播放本地歌曲时，用户挑选第一首歌往往比较犹豫，但对后续播放的歌曲却不太在意；
2. 对播放模式，中国的用户会认为这是一种单选的模式选择，而非“开关”组合之意；
3. 抖动换歌很有趣，但是用户几乎不会用到，“谁会在逛街走路时摇手机呢？”
从场景仔细分析和推敲，很容易就可以明确产品的需求，对应上述三个发现，需求如下：
1. 提供“马上听歌”引导用户直接听歌；
2. 三态按钮实现“列表循环、单曲循环、随机播放”三种模式切换；
3. 忽略抖动换歌这种华而不实的特性。

三、敏捷原型设计，适应与借鉴并行
用研的输出以及前面的ADS定义为功能筛选和设计取舍提供了强有力的决策依据。在需求框架大致决定的时候，我们接下来就进行方案设计了。正所谓“一图胜千言”，原型有时候会比面面俱到的文档更直观。不同的阶段，我们会进行不同精度的原型设计：
在原型迭代的过程中，需要注意android平台的UI尴尬。与其他平台（iPhone、symbian、windows mobile）不同，an-droid更加开放，不同的厂商不同的ROM版本界面规范并不统一。如果简单地将其他平台的设计规范移植过来，产品体验可能会和整个系统“格格不入”。借鉴了android平台的一些优秀app（比如twitter和new york times）的设计策略，我们决定“适应与借鉴并行“：在大的基础体验上，保证与系统体验一致，尊重平台使用习惯；在细节体验上，尽量克服系统的操作困难，保证局部体验的流畅。