相信大多數(shù)設(shè)計(jì)師都有過這樣的經(jīng)歷：在產(chǎn)品設(shè)計(jì)過程中，設(shè)計(jì)師和產(chǎn)品經(jīng)理不斷pk，各抒己見，甚至鬧得臉紅耳赤、拍桌翻臉，最后項(xiàng)目總結(jié)時(shí)又因達(dá)不到“理想目標(biāo)“雙方深深自責(zé)，紛紛表示”缺少交流“。彼此不斷pk，交流絕對足夠，只是我們?nèi)鄙儆行贤ǖ墓ぞ摺Ｈ绻茉谠缙诮⒐沧R，口水仗爆發(fā)的頻率就會越少，真正花在產(chǎn)品上的時(shí)間也就越多。這一次，我們決定更早地切入，在最開始的產(chǎn)品規(guī)劃層面，引入“產(chǎn)品定義描述”（關(guān)于ap-plication definition statement，請參考《iPhone Human Interface Guidelines》）。

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

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

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

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