相信大多數設計師都有過這樣的經歷：在產品設計過程中，設計師和產品經理不斷pk，各抒己見，甚至鬧得臉紅耳赤、拍桌翻臉，最后項目總結時又因達不到“理想目標“雙方深深自責，紛紛表示”缺少交流“。彼此不斷pk，交流絕對足夠，只是我們缺少有效溝通的工具。如果能在早期建立共識，口水仗爆發的頻率就會越少，真正花在產品上的時間也就越多。這一次，我們決定更早地切入，在最開始的產品規劃層面，引入“產品定義描述”（關于ap-plication definition statement，請參考《iPhone Human Interface Guidelines》）。

產品定義描述（product definition statement），著重解決三大問題：解決方案、目標受眾、產品優勢。針對And-roid QQ music，我們與產品經理建立了一個統一的認知：
· 解決方案：移動場景聽歌
· 目標用戶：android平臺用戶，大部分是上班族
· 產品優勢：隨身攜帶的歌曲列表（收藏夾）和豐富的運營歌曲庫

從源頭的戰略層面上建立了統一的認知，我們接下來開展的工作就有根據了。既然核心是解決“移動場景聽歌“的問題，我們必須首先弄清楚什么是”移動場景“？移動環境和PC環境差異甚大，碎片時間的使用更為突出。用戶一天是怎么活動的呢？每次拿起手機聽音樂都是什么時間？上班的公車上、走路、晚上睡覺前？在這些點上用戶都會做些什么？簡單的腦暴可以羅列各個可能的使用場景，但還比較粗糙。場景的構想需要建立在高度的認知上，這時候用研的切入顯得相當關鍵，用戶特征、喜好、使用習慣…對用戶越了解，場景就越能貼近真實、越能發現更多的細節。這些都為后續的設計決策提供了有力的依據。

客觀構建的場景有很多有意思的發現：
　　1. 在播放本地歌曲時，用戶挑選第一首歌往往比較猶豫，但對后續播放的歌曲卻不太在意；
　　2. 對播放模式，中國的用戶會認為這是一種單選的模式選擇，而非“開關”組合之意；
　　3. 抖動換歌很有趣，但是用戶幾乎不會用到，“誰會在逛街走路時搖手機呢？”
　　
　　從場景仔細分析和推敲，很容易就可以明確產品的需求，對應上述三個發現，需求如下：
　　1. 提供“馬上聽歌”引導用戶直接聽歌；
　　2. 三態按鈕實現“列表循環、單曲循環、隨機播放”三種模式切換；
　　3. 忽略抖動換歌這種華而不實的特性。
三、敏捷原型設計，適應與借鑒并行
　　用研的輸出以及前面的ADS定義為功能篩選和設計取舍提供了強有力的決策依據。在需求框架大致決定的時候，我們接下來就進行方案設計了。正所謂“一圖勝千言”，原型有時候會比面面俱到的文檔更直觀。

在原型迭代的過程中，需要注意android平臺的UI尷尬。與其他平臺（iPhone、symbian、windows mobile）不同，an-droid更加開放，不同的廠商不同的ROM版本界面規范并不統一。如果簡單地將其他平臺的設計規范移植過來，產品體驗可能會和整個系統“格格不入”。借鑒了android平臺的一些優秀app（比如twitter和new york times）的設計策略，我們決定“適應與借鑒并行“：在大的基礎體驗上，保證與系統體驗一致，尊重平臺使用習慣；在細節體驗上，盡量克服系統的操作困難，保證局部體驗的流暢。