文章為作者根據自身工作經驗所做的總結分享， 希望可以給你帶來啟發，
設計背景用戶在使用協力廠商應用聽音樂時， 協力廠商的音樂鎖屏會覆蓋在手機的鎖屏之上，
在設計方案前， 筆者對競品的音樂鎖屏介面進行了分析：
通過競品分析發現， 蘋果， 小米， 魅族等手機廠商已經對協力廠商音樂鎖屏進行了適配。
在功能方面， 音樂鎖屏的基礎功能包括：播放/暫停， 上一首， 下一首， 其餘的， 小米和蘋果做了收藏功能， 蘋果做了調節進度和調節音量的功能。
在資訊顯示方面， 適配協力廠商的音樂鎖屏會顯示歌曲名， 歌手名， 專輯名稱， 專輯封面， 歌詞資訊， 未做適配的音樂鎖屏只顯示了歌曲名， 歌手名和專輯名稱。
接著， 筆者對主流的協力廠商音樂軟體的鎖屏進行了分析：
協力廠商音樂鎖屏包含的功能與手機音樂鎖屏的功能基本類似，
根據競品的情況和協力廠商鎖屏音樂的顯示內容， 產品經理， 交互， 研發進行了一輪功能討論， 產品希望在鎖屏上提供給用戶盡可能全面的功能， 形成我們產品的特色， 研發方面， 根據我們現有的技術能力， 只能夠將協力廠商音樂鎖屏上的資訊進行提取和整合， 最終， 我們決定做的功能和顯示的資訊包括：
功能：播放/暫停， 上一首， 下一首
資訊顯示：歌曲名， 歌手名， 專輯名稱， 專輯封面， 歌詞
2.介面佈局根據資訊的類別， 我們將介面元素進行了分類， 在進行介面佈局設計時，
（1）專輯封面設計成圓形還是方形？
圓形在視覺效果方面會比較美觀， 但與研發進行討論， 目前我們能做到的只能講協力廠商鎖屏音樂的背景圖片和裡面的歌詞進行縮放， 然後顯示在我們規定的視窗裡， 顯示成圓形會導致圖片和歌詞顯示不全的問題。
（2）按鈕是放在專輯封面的上方還是下方？
考慮到使用者使用音樂鎖屏的場景， 公車上， 跑步時， 走路時等等， 在這些場景下， 用戶有單手使用手機的需求， 為了方便用戶能夠便捷的使用這些按鍵， 我們最終將控制按鈕設計在了下方。
3.操作規則
包括常規操作， 解鎖規則， 暫停機制， 絲印鍵操作規則， 通知中心和控制中心在此時的操作；
特殊狀態：無封面狀態/無歌詞狀態/無歌曲名/無歌手/無專輯名稱狀態/無網路狀態等特殊情況的處理機制；
併發情況：來通知， 來電， 來鬧鐘， 來紅包時的併發規則
設計跟進在設計方案實現的過程中， 遇到了一系列原來沒有考慮到的問題， 包括
1.專輯封面顯示不全的問題在我們的實現過程中， 發現很多專輯封面顯示的是人物，而在我們的顯示框中，很多人物臉部被切割，非常影響視覺效果，我們對現象和實現方案進行了研究，大多數的協力廠商音樂人物顯示的位置相似，但是我們的實現方案是只顯示專輯封面在我們框中位置的部分，而這個位置正好將人臉進行了切割，最終我們將專輯封面進行了下移處理。
2.歌詞位置的顯示問題由於協力廠商音樂的歌詞顯示方式各不相同，很難用一種方式將鎖屏歌詞顯示完美，最終我們根據協力廠商鎖屏音樂各自的歌詞顯示方式，設定了每個應用各自的歌詞出現高度。
3.協力廠商應用升級問題我們通過一套演算法將協力廠商音樂鎖屏上的元素進行了提取，但是當協力廠商音樂鎖屏上元素位置發生改變，元素內容發生改變時，我們的演算法就會存在適配失效的問題，最終，我們評估了版本維護的工作量，並且加入了後臺維護的演算法。產品最終效果出來以後，我們根據使用者回饋，制定了下一期的相關的反覆運算優化方案。
通過這一次的設計，我的收穫是：1.在接到全新的需求時，要與軟體進行密切溝通，瞭解軟體預研的結果能夠避免輸出無法實現的方案；2.設計方案輸出只是設計的前期，後期的設計跟進也是設計中一個非常重要的環節，設計跟進中，要與軟體視效一起，及時調整和補充方案，這樣才能保證最後方案的效果。
補充我們重新審視這個項目，發現這個項目有兩個非常嚴重的問題：
作為平臺，需要對每個適配的協力廠商單獨進行精細調整，可拓展性和維護成本非常差；協力廠商一升級就會導致我們適配方案的失效。在專案開發完成後，我們就面臨著維護成本的問題。如果在初期就詳細評估維護成本，大家會重新考慮是否使用這個方案。本文由 @ 張宇希 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議
發現很多專輯封面顯示的是人物，而在我們的顯示框中，很多人物臉部被切割，非常影響視覺效果，我們對現象和實現方案進行了研究，大多數的協力廠商音樂人物顯示的位置相似，但是我們的實現方案是只顯示專輯封面在我們框中位置的部分，而這個位置正好將人臉進行了切割，最終我們將專輯封面進行了下移處理。2.歌詞位置的顯示問題由於協力廠商音樂的歌詞顯示方式各不相同，很難用一種方式將鎖屏歌詞顯示完美，最終我們根據協力廠商鎖屏音樂各自的歌詞顯示方式，設定了每個應用各自的歌詞出現高度。
3.協力廠商應用升級問題我們通過一套演算法將協力廠商音樂鎖屏上的元素進行了提取，但是當協力廠商音樂鎖屏上元素位置發生改變，元素內容發生改變時，我們的演算法就會存在適配失效的問題，最終，我們評估了版本維護的工作量，並且加入了後臺維護的演算法。產品最終效果出來以後，我們根據使用者回饋，制定了下一期的相關的反覆運算優化方案。
通過這一次的設計，我的收穫是：1.在接到全新的需求時，要與軟體進行密切溝通，瞭解軟體預研的結果能夠避免輸出無法實現的方案；2.設計方案輸出只是設計的前期，後期的設計跟進也是設計中一個非常重要的環節，設計跟進中，要與軟體視效一起，及時調整和補充方案，這樣才能保證最後方案的效果。
補充我們重新審視這個項目，發現這個項目有兩個非常嚴重的問題：
作為平臺，需要對每個適配的協力廠商單獨進行精細調整，可拓展性和維護成本非常差；協力廠商一升級就會導致我們適配方案的失效。在專案開發完成後，我們就面臨著維護成本的問題。如果在初期就詳細評估維護成本，大家會重新考慮是否使用這個方案。本文由 @ 張宇希 原創發佈于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議