跨平台設計探討：如何為 Android 平台做好設計

最近在 Facebook 遇到一些年輕設計師，說在 Medium 上讀了我寫的關於 Android 設計文章，專門約時間和我討論。我這才突然想起 2 年前確實寫過一篇探討跨平台設計的文章，不禁倍感欣慰：沒想到在互聯網這麼快節奏的行業，這篇文章還沒有被時間淘汰。雖然已經很久沒有再做 Android 平台的設計工作，但看到現在 Android 平台愈加壯大，尤其是身邊一些挑剔的設計師朋友也開始用 Pixel 來替代 iPhone。於是萌生了把中文版本發布出來的想法，希望分享給更多國內做 Android 平台開發與設計的朋友。特別要感謝 UXCoffee 的 Hoka 和 Riceman 編輯。

原文：https://medium.com/@rujia/how-to-be-a-good-android-designer-7a6da3195331#.tlm1pxaop

為 Android 平台做設計是一件體力活。你可能案頭常備 4 台手機，來測試各種尺寸和解析度，還要畫連程序員都一知半解的 9-Patch（一種可以拉伸素材的切圖方式）。

除了解析度和技術上的挑戰，安卓設計簡直充滿驚(jīng)喜(xià)。你要隨時做好準備，不要被某個小眾手機上的界面效果嚇到。有時慘不忍睹的色差會讓本該是藍色的地方變成了綠色，有時在某個非典型設備上，界面會發生嚴重的位置偏移。

世界上有多於 18,796 種不同的 Android 設備（截至2014年8月）

這大概就是為什麼你很難找到處女座的 Android 設計師——因為你太難保證最終呈現的效果與你的設計一致了。

讓最終界面完全按照你的設計意願呈現，只是一名好的 Android 設計師的入門試煉（網上已經有很多資源告訴你如何通過這一關）。通過入門考試之後，你會發現接下來的考驗，卻比入門考核還要難得多。最大的難點，不在於設計技法，而在於……

妥協的藝術

如果你在一個 20-30 人的的中型團隊，你可能會和產品經理、程序員、用戶研究員、文案等人密切合作。如果你是專註做 Android 的設計師，那麼很有可能你還要和至少一名 iOS（或者其他平台）設計師合作。

在這樣一個團隊中，就像一個成熟的人會漸漸徹悟人生一樣，漸漸地，你就會明白：

設計是一種妥協的藝術。

設計是一個不斷探索的過程。在一開始，你可能會沉浸於某一個方向上的探索，比如從創意開始，但你很快會發現，設計的探索是有邊界的。定義這個邊界的因素可能會有所不同，但幾種比較常見的因素有：產品目標，技術資源，用戶體驗和創新性。如下圖所示：

設計出創新的體驗固然好，但也要考慮是不是易於大眾接受；工程師資源永遠是有限的；產品目標和進度的實現需要設計的配合。如何在探索的過程進行取捨，是一種藝術。

在幾個月的探索之後，如果你足夠幸運，你將最終發現一個平衡點，可以讓這幾個因素都得到比較大的滿足。我們把這個點稱為完美平衡點（上圖中的紅色圓點）。往往一個好的設計就這樣誕生了。

但如果你是一個 Android 設計師，情況很可能會更複雜。一方面，在美國，因為 iOS 的市場佔有率略高，iOS 平台往往有更多的工程師資源和更快的開發速度。而 Android 因為設備的多元化、需要兼容適配等原因，往往會拖慢進度。另一方面，隨著近年 Google 不斷優化提升 Android 的體驗，兩個平台的體驗已經越來越相似，彼此也更加依賴。

它會對你的設計產生什麼影響呢？

我們在圖上加上 iOS 的設計探索範圍（藍色邊框）後，你的 Android 設計將受限於 Android 和 iOS 的設計探索範圍，也就是下圖中藍色填充的區域：

而且，當你開始在 Android 平台進行設計時，如果一個功能已經在 iOS 上實現了，而解決方案又恰好落在 iOS 設計的滿意平衡點，那麼留給 Android 的探索邊界就大大減小——除非資源很充足，否則團隊會盡量避免用兩種截然不同的方式實現同一應用上的同一功能。所以，你的設計探索會圍繞著 iOS 的滿意平衡點（下圖中的藍點）。這時，下圖中藍色填充的圓形區域才是你真正可以探索的邊界：

並沒有剩下太多空間，是么？

其實上圖已經是一種比較幸運的情況，畢竟 Android 的完美平衡點（上圖中的紅點）還在你的探索範圍內。如果你沒有這麼幸運，你的探索範圍甚至可能遠離 Android 的最佳設計點，如下圖：

很遺憾，邊界變小可能讓你不得不錯過本來在 Android 平台上的滿意平衡點。

另外一個問題是，現在很多團隊喜歡快速迭代的 Scrum 開發模式，它會讓情況變得更加複雜，你的 Android 設計可能需要隨著 iOS 的設計改變，就像這樣：

這種開發模式在大多數情況下可以達到還比較滿意的效果，但也是柄雙刃劍。 Scrum 的設計初衷是，鼓勵你節省做決定的時間，並把節約的時間投入在真正的開發上。 但久而久之，它會讓你在做決定時，不想投入太多時間進行充分考慮，因為你知道如果出現問題，隨時可以再做修改。但矛盾的是，缺乏充分考慮做出的決定，往往會帶來新的問題。 這種惡性循環帶來的後果，就是在迭代中成堆的被拋棄的代碼或者設計稿。而在一個現實的團隊中，這種結果無論對資源利用，還是團隊士氣，都是有弊而無利的。 更糟糕的是，iOS 的設計師可能已經知道，當自己做出決定時，這其實只是無盡探索中的其中一站，但 Android 設計師可能已經開始設計並將它考慮在內，「決定」聽起來應該是不會輕易改變的，不是么？ （如果你是 Scrum 的粉絲，我想說，Scrum 對於目標比較明確的產品是一種很好的開發方法，但對於一個沒有很清晰解答方案的問題，它可能並不是最合適的方法。）

這些都是在真實的產品設計開發中，Android 設計師可能遇到的挑戰。

如何為 Android 平台做好設計

隨著我努力了 8 個月的新產品順利發布，我想和大家分享一些自己的經驗——關於如何為 Android 平台（或者非主優先順序的平台）做好設計。這些經驗也許不適用於所有的產品、團隊，但也許會對你有所啟發。

1. 永遠不要只局限於一個平台

就像之前提到的，設計是做妥協的藝術。而做妥協，首先需要收集足夠多的信息，以便理解所受的限制和各方的需求。

我之前提到過，由於近年來平台設計有逐漸接近的趨勢，Android 的設計邊界越來越受 iOS 所影響。iOS 的設計師可能只需要考慮 iOS，而 Android 則永遠不能只考慮 Android。只有對兩個平台有同樣深入的理解，才可以讓你更方便地進行設計。

如果沒有對 iOS 平台的深入理解，那麼你將很難理解每一個 iOS 設計背後的原因。比如，這個菜單之所以放在這裡，多大程度上是因為它真的對用戶體驗有幫助（將會影響到設計邊界中的用戶體驗因素），還是只是因為它是 iOS 的系統慣例（能夠減少工程師的工作量）？

理解這些，能夠讓你更好地理解你所面臨的設計邊界，而理解設計邊界則是你進行設計的基礎。 而且，如果你可以理解 iOS 平台做設計決定時的種種考慮因素，你會得到一些意外的驚喜。比如，大家都知道 iOS 的系統限制會相對嚴格。很多時候，因為系統上的限制，一個 iOS 上的設計並不能達到最好的效果，而 Android 則不一定有同樣的系統限制，自由發揮的空間更大。不要輕易因為 iOS 的設計已經先入為主，而放棄這些 Android 上的「特權」。 一個例子是由 Joey Flynn 設計的 Facebook Messenger（臉信） 的 Chatheads （快聊），它是一個浮動在桌面上的快捷入口，讓 Android 用戶可以在使用其他應用時，也收到消息提醒，並且不用離開正在使用的應用，就能回復 Facebook Messenger 內的消息。這個功能在 iOS 上因為平台限制，所以無法實現，但是在 Android 平台上極大提升了用戶活躍度。

（Android 版 Facebook Messenger 的快聊功能 - 一個浮動在桌面上的快捷聊天入口。圖片來源：http://www.ethicalhackx.com/wp-content/uploads/facebook-massenger-chat-head-1-681x1210.png）

2. 儘早參與討論，讓你的想法產生影響

在思考如何把一個 iOS 上的設計移植到 Android 設備時，有時在你重新拆解、探索要解決的問題後，你會發現一個非常完美的、新的解決方法，它不僅可以達到一個新的平衡點，還可以對現有的解決方案本身有極大提升。

你可能有非常充分的理由，但在這個時候，要推進你的解決方案，會很困難。在團隊做出決定之前，也許大家可以客觀地考慮設計的利弊、做出選擇，但當你們已經做出了決定，想要改變就會非常困難。 產品經理還要考慮 iOS 的進度，也許他們的工程師已經在開發，甚至開發完了這個功能，也許……這些都讓決定做出之後，很難被改變。

所以，盡量從一個設計問題開始浮現的時候就加入討論，開始思考，並讓你的想法產生影響——即使代價是它會大大增加你的時間投入。你最終會發現回報是值得的。畢竟，跨平台設計是一個互相協作、溝通的過程。

3. 溝通，溝通，主動溝通

重要的事情說三遍。在 iOS 平台做決定時， 可能不會有時間考慮 Android 的情況——這完全可以理解，畢竟只考慮 iOS 一個平台已經夠他們忙了。但對你來說，他們做出的決定有時卻會對 Android 產生極大的影響。這時候，主動溝通將是關鍵。

即便是做出決定後，這種溝通也要持續進行。還記得這幅圖么？

因為一個大的項目是由無數細節組成，即便是一個微小的細節變動，也需要花很多時間在跨平台協調上。最好的方法就是，時刻關注其他平台的動態。

換言之，不要害怕成為一個「好奇寶寶」。

如果有一天你驚訝地發現，一個其他平台上的變動，沒有及時通知你——即使你要因為這個變動而修改很多個相關的界面，也先請保持冷靜。不要首先責怪別人沒有告訴你，而要主動詢問並尋找相應的解決方法：試著理解這個改變背後的原因，是不是 Android 平台也存在相似的問題需要解決，還是沒有受到影響。如果有可能，想想看在未來如何更早參與這個決定。

畢竟，有的時候，可能你在 Android 做了一個界面上的改變，也會忘記通知其他的平台。有合作的地方就需要在溝通上投入精力，這是由人類的天性決定的。互相的理解與支持，就是跨平台合作的精神。

4. 維護統一性

有些時候，你可能會被一個 Android 平台量身定製的設計所吸引，它是你多天思考得出的精華，可以完美解決用戶遇到的問題，甚至帶來更好的體驗，而且又非常具有 Android 的平台特色。但仔細想想，它帶來的價值真的可以彌補平台統一性的損失嗎？

如果你沒辦法得到很確定的答案，那就適當妥協吧——讓這個解決方法腹死胎中。

也許有些設計師會開始對自己存在的意義產生質疑：公司付錢雇我當 Android 設計師，不就是因為想要具有 Android 特色的設計嗎？

雖然表面上是這樣，但無論是使用統一的設計，還是分開使用不同的設計，在這個做決定的過程中，你已經用自己對 Android 系統的了解與經驗，為團隊做出了貢獻。

維護界面在不同平台的統一性，可以幫助人們更好地識別 App 的品牌。而且，如果未來設計再次改變，比如 iOS 要在主屏很醒目的位置增加一個很棒的功能，而這個位置……不幸地在 Android 上已經別有他用，但又沒有其他地方比它更加合適。這種情況下，難道你要重新設計主屏？如果這樣，其他相關的界面又怎麼辦？

沒有人喜歡遇到這種的情況。所以相信我，保持統一性，有時會幫助你節省很多的時間和本可避免的爭論。

當然，更多時候，具有平台特色的設計還是可以帶來更多的價值。它可以讓這個平台的用戶感受到團隊對這個平台的用心，而且不會增加很多學習成本和未來開發設計過程中的「技術債」。那麼，就跟隨你的判斷與直覺吧。

最後

我寫下這些，是想讓更多人了解，跨平台合作的產品設計面臨著很多挑戰。這些是我希望自己在開始設計的時候就意識到的。希望能通過分享，幫助後來人繞過一些坑。

同時，我們還可以從組織結構上進行一些優化。比如，在計劃跨平台開發時，更多思考如何降低組間溝通的成本，避免重複的迭代工作量，從根本上降低合作的工作難度。

成為一個優秀的跨平台設計師，不僅要求更多的時間投入，還需要過人的溝通能力、對各平台同樣深入的了解。更重要的，還有永遠不嫌多的換位思考的合作精神。

這是一段充滿挑戰的旅途，當然，也充滿了收穫。
推薦閱讀：