UI/UX｜跳脫 iOS/Android 的限制，為「使用者」做設計吧
「你熟悉 iOS 與 Android 的設計規範嗎？你了解這兩個平台在 UX 上的差異與限制嗎？你能針對兩個平台的使用者做出相應的 UI 設計嗎？」
如果看看求職網、職缺簡介，會發現業界很喜歡把以上這些問題當作篩選 UI/UX 人才的條件之一。而許多新手教學的文章也很喜歡把兩者區分開來，強調 iOS/Android 平台的差異和使用習慣的不同。無形中，這也形成了一種「針對平台做出不同的設計才是正確做法」的觀念。
這種觀念的強化自然有好處：會促使年輕的設計師更用心研究雙平台的差異，了解兩個系統的習慣與優缺點。 但是這樣的觀念也會帶來可怕的後果：設計師們開始糾結於做出平台差異，在元件與介面上不斷地討論這「有沒有符合設計規範」。
現在，我想要邀請你，和我一起暫且丟掉一切 iOS 與 Android 的包袱。我會告訴你：
- 為什麼刻意強調平台差異是一件不必要的事情
- 在雙平台上用同樣的 UI 有什麼好處
- 什麼時候適合做出平台差異
- 以及最後，什麼是為「使用者」做設計？
關於平台差異這件事情
我們都知道，iOS 有 Human Interface Guidelines (HIG)，而 Android 也有 Material Guidelines。這些設計規範會隨著不同平台有不同的作法或習慣，可能是元件、互動的設計或者是 icon 的樣式。
由於這些 guideline 上的差異，我們經常會誤以為 UI/UX 有分「符合 iOS 規範」以及「符合 Android 規範」的正確作法，而在任何一種平台上套用另一種平台的元件都會造成使用者的混亂，是錯誤的設計。但是很奇特的是，這些觀念和差異都只有在 App 上才會突然地適用。
想像使用者正在用手機看一個網站：使用者用手機打開瀏覽器看網站的時候，無論 dialog 怎麼顯示、navigation 怎麼設計、icon 長什麼樣子……他們都用得好好的，對吧？網站並不會偵測使用者的系統，顯示不同的網頁 UI。
但只要一涉及到 App，我們就很容易開始把使用者想得特別複雜。我們會想要為不同系統的 App 設計不同的介面和操作流程，因為我們認定不同平台的使用者理解的介面、圖示或 UX 是不同的。但實際上呢？
設計規範也是彼此學習、模仿出來的
會強調「按照設計規範」的前提，就是預設規範都不會改變，或者兩個平台的設計規範是無法通用的。但如果我們實際來看看大部分的 app：
1. 常見的 Bottom Navigation
iOS 使用 Tab Bars（註一）的歷史已經非常悠久，一直沒有變過。而過去 Android 的架構大致上都是利用由「漢堡」（三條橫線）叫出來的 Navigation Drawer 做導航。如果沒有用漢堡，也會用畫面上方的 Tabs 做導航。
但是由於行動裝置的普及，易用性也愈發被看重，比起漢堡或 Tabs，符合拇指原則（thumb rule）的 Bottom Navigation 顯得更加合理。2016 年的時候， Material Guidelines 也正式將 Bottom Navigation bar 加入設計規範。
註一：Tab Bars 為 iOS 放置在畫面底部的最高層級導航，是 iOS 官方名稱，不可與 Android 的 Tabs 混淆
2. 靈活、有彈性的 Chips 和 Tabs
Chips 是 Material Guidelines 中一個很好用的小東西，基本樣式為多個圓角矩形並排，可以當作選單、標籤、動作選項或是篩選條件等等。
雖然 Chips 在 HIG 裡面目前（貌似）還沒有出現，但在各大產品中已經廣泛使用，不管是 Uber Eats 篩選餐廳、 Instagram 的探索頁標籤、Google Maps 的 action 列……都可以見到它的蹤跡。
Tabs 也是一個 HIG 裡面沒有涵蓋的元件，和 Material 的 tabs 相應的元件在 HIG 中叫做 Segmented Control。這類元件會因為裝置寬度的關係而被大幅限縮使用範圍，在選項超過三、四個以上時，就失去了作用。
這時候使用 Scrollable Tabs，就可以靈活呈現更多不同選項了。所以雖然不符合 HIG 規範，iOS 平台上的產品大多都還是使用 tabs 的設計。
3. 確認和取消，誰在左邊？
在 Apple 出來鬧場之前，設計師一直都是遵循著 Windows 的規範：將 primary action 放在左邊，secondary action 放在右邊。
Windows 的邏輯是，人的閱讀方向為左到右，因此左方按鈕的位階比右方按鈕高。這時候自然應該將 primary action（如：確認）放在左邊，這樣使用者看完內文敘述之後，向下看，第一個看見的按鈕就會是主要的選項。
而 Apple 認為，由於人的閱讀方向為左到右，因此目光掃過所有選項以後，視線必定會停留在最右方的按鈕，這時候這個按鈕便應該是 primary action。同時，右方的按鈕帶有「前進」、「下一步」的意思，而左方按鈕則是「後退」、「上一步」的意思，因此將「取消」這一類的 secondary action 放在左邊是更為合理的位置。
而 Android 系統原先並沒有特別規定究竟哪一個按鈕放在哪一邊，因此當時的開發者大部分都遵循常見的 Windows 規範，將 primary action 放在左邊。一直到 Android 4.X 版本以後，才和 Apple 一樣開始將 primary action 放在右邊（因年代久遠，此為考古資料，如有錯誤請告知作者）。
現在，在 app 上 Cancel / OK 的規則已經是佔大多數，而受到 app 影響，許多網頁 UI 也都採用 Cancel / OK 的邏輯。至於 Windows 什麼時候會跟進呢？也許會是在不久的將來吧（笑）。
既然平台差異經常在改變，那麼刻意強調平台差異就成了一件不必要的事情。
我們該做的並不是為單一平台的用戶設計，而是為持有行動裝置的「使用者」設計。
在本質上，iOS 和 Android 是一樣的
是的，無論退一步或退一百步看，不管你的使用者屬於哪一個平台，他們最終都是單純的「產品使用者」。只要是使用者，UX 概念都是通用的。如果拋開設計規範上的諸多細節，你會發現 HIG 和 Material 要表達的核心概念——或者說基本原則——都是一樣的：
- 可以執行的動作或選項，應清晰、使人不易混淆
- 按鈕、選項的觸控範圍應符合人體工學，並讓人清楚知道可以點擊
- Icon 應清晰、容易辨識，且對應的功能應符合使用者預期的行為
- 同位階的物件應產生同位階的結果
- UI 樣式應兼顧美感與易用性，視覺的美觀應建立在良好的 usability 之上
- （…可以無限寫下去，所以下略…）
那就像是每一國的法律不一樣，但大致上會符合一些基本的道德觀，例如不要殺人、不要傷害、不要偷竊、不要破壞……等等。當我們將不同平台的使用者一視同仁地視為「使用者」，就會發現我們要解決的問題很簡單：如何讓所有人都能更容易使用這個產品。
既然目標是讓「所有人」更容易使用，那麼，為何不採用同一份設計稿呢？
▍共用設計稿的好處 1：為使用者減少學習成本
如果你的設計稿針對 iOS 和 Android 平台做了不同的設計，代表每一次你的用戶換手機、換平台，就要重新學習一次產品使用的方法，重新培養一次使用習慣。
這是我在簡單用戶訪談時蒐集的紀錄：
iOS → Android 的用戶 A：
「我換手機之後，用__(某產品 X)__的時候習慣的手勢都不見了！而且原本左滑右滑就可以叫出的功能，變成一定要點下 icon，真的很不方便。」
Android → iOS 的用戶 B：
「換手機之後真的很多東西要重新學，不過至少打開__(某產品 Y)__的時候介面是一樣的，所以還是知道怎麼用。」
另外如果你的產品除了手機之外也適合平板操作，那麼你的用戶有可能是跨平台的使用者，例如：使用 Android 手機+iPad。對於這樣的使用者來說，兩邊的操作邏輯或使用方式不同，也是徒增困擾、增加學習成本的作法。
▍共用設計稿的好處 2：為 Product Team 節省設計與溝通成本
當我們不需要去維護兩份不同架構或流程的設計稿時，Product Team 可以花更多時間優化體驗、做 A/B Testing、研究產品使用者真正想要的是什麼。溝通新 feature 時，我們就不再需要分成兩條路線討論，而是專注於滿足人性和本能。
▍共用設計稿的好處 3：維護品牌意識和產品形象
最經典的範例或許就是手遊介面了吧！手遊的 UI/UX 設計都會遵循自己的一套規則，並不會去刻意符合任何一個平台的設計規範。這樣做的好處就是用戶對遊戲介面會有一定程度上的既定印象和期待。
如果我現在說「Instagram」，你的腦海中必定會浮現出跟我想像中差不多的畫面，即便我是 iOS 用戶，而你是 Android 使用者。統一的產品形象，讓產品外的人際互動變得更容易。「你不會發限時動態？我教你，在這裡～」「只要點這個，然後按發布，就可以了！」
可是 iOS 和 Android 真的可以完全一樣嗎？不要騙我沒讀規範喔！還是要區別吧？
需要做出平台差異的狀況
▍如果沒有文字輔助，不要挑戰慣用的抽象圖示
大部分的 icons 都是用常見的物體或既定印象做圖示，所以不管是哪一個平台的用戶，都可以輕鬆地理解。但是總有一些特例，比方說「分享」，在兩個平台上的系統 icon 就是完全不同的：
像「分享」這一類的圖示在兩個平台上有完全不同的設計，而表達的概念又是抽象的動作，不像具象的物體那般容易理解，因此在沒有文字輔助說明的情況下，就不適合共用同一個設計囉～
▍在不影響產品風格和體驗的情況下，如果可以節省開發成本當然也很好
理想中，設計師當然都希望能夠將產品客製化，但回歸現實來看，有時候不一定有時間將所有元件客製化。舉例來說，現在我們要做一個 switch 元件，應該客製化還是用原生的呢？
如果產品 UI 有強烈的視覺風格需要遵循，當然可以考慮客製化，因為不管 switch 長什麼樣子，使用者並不會因為長得跟系統不同就不懂得如何使用。但如果對產品風格的塑造或是體驗的優化沒有太大影響的話，那麼使用原生的元件也是節省開發成本的好方法。
▍以及一些例外，像是實驗性質的產品或預算不足的團隊
當然到底要不要遵循設計規範或是大量使用原生套件，還是要看每一間公司每一個團隊自身的能力和策略走向。
如果是小步快跑的實驗性質快速開發，或是時間金錢預算很緊的小公司，就要自己斟酌。原生套件也很適合還不確定市場反應，想要快速做出 MVP 試水溫的新創團隊。（不過這種算是特例，也不是設計師本身工作的範疇，這邊暫且不討論～）
拋開平台包袱，為「使用者」設計
如同前面有提到的，為什麼用當我們用手機看網站，網站的 UI/UX 都沒有考量任何平台差異或是設計規範，但我們從來都不會覺得有什麼重大問題？
因為 RWD 網站的邏輯就是為使用者設計、為行動裝置設計、為不同的螢幕寬度設計。無論使用者用哪一種手機，只要使用方式符合直覺、能在行動裝置上順暢使用，並根據不同裝置寬度顯示出最佳化的介面，就是好設計。
就像 Airbnb，單看介面其實分不太出來現在究竟是在 iOS、Android 還是 web 上。我們可以發現不管是 UI 的視覺風格、使用流程或是整體的操作方法，他們都沒有明顯地刻意遵循哪一個設計規範。
他們的策略，就是將所有的使用者——不管在 web 上還是 app 上——都視為單純的「行動裝置使用者」。他們的設計，就是以「在行動裝置上能有良好的操作和體驗」為目的，所規劃出來的 UI/UX。
將使用者區分出所謂的 iOS 或 Android 用戶其實沒有意義，我們真正該做的是將他們通通視為「行動裝置使用者」，並針對行動裝置做出最適合、最容易操作且最流暢的產品設計。
與其區分 iOS 解法和 Android 解法，我們更應該致力於尋找一個適用於行動裝置，符合人性和直覺的解法。因為符合人性和直覺的產品，才是使用者真正想要的產品。
↓↓ 如果喜歡這篇文章，請幫我掌聲鼓勵鼓勵～也歡迎追蹤，我會不定時發布新文章！
