APP是否該遵照iOS與android的官方規範設計介面?

seven認為:

不僅是介面,包含從ios、android基礎系統操作角度,站在官方立場,個人認為會因品牌、使用族群而有所不同。ios封閉式系統特性帶來的優點是讓使用體驗一致,規範中希望設計者多使用系統原生控件,系統操作上保持統一,介面設計迎合系統;android開放式系統,設計者可於APP內自由設計控件,甚至不照規範而行(或介面外觀相似規範即可),遊戲、功能類型APP可見到更多不同操作模式,缺點是使用者經常需要學習。

因android介面設計彈性高,若兩大系統需求一致,更能迎合ios介面,考慮使用者層面,應先排除ios、android規範 (以下簡稱兩者)衝突,取其優點。app介面遵照規範的優點是增強使用者對系統、操作熟悉度,兩者介面一致可減少使用者學習時間、強化app品牌個性,兩者應取得平衡,並思考該類型app應遵照規範到什麼程度。

規範內容為使用體驗不斷做調整,ios強調介面適應性和佈局,不同型號裝置上的通用性,加上操作回饋、介面微互動產生視覺連接感,可視化使用者行為結果;android重視畫面中物件層次,在堆疊、移動等操作動態效果,必須合乎物理性邏輯,賦予物件光影深度、材質屬性,兩者規範在優化介面空間皆有相似之處。

ios於2013年走向扁平化,2014年各裝置與網頁陸續蔓延,趨勢是平衡所有平台一致性開端,拉近每個系統介面相似度(從手機的高使用率開始,到平板、電腦皆擁有一致視覺、使用者體驗),從APP來看ios、android介面與操作。

【invision】

首頁 左:android,右:ios(更多選項)

兩者首頁有各自規範風格,佈局排版差異大,操作邏輯、標題與選項名稱不同,可說是兩個不同APP。

ios首頁:

  • 依規範使用分段控件(Segmented Controls)區分主要功能,在原型項目(prototypes)中易用超大圖檔畫面來辨識,但“搜尋”功能會在畫面下滑移動後消失造成不便,應遵照規範將其固定於導航欄(navigation bar)。
  • 原型項目中更多選項,其中“刪除”與“取消”選項,應遵照規範將其調整位置、顏色。

android首頁:

  • 並沒有漢堡選單介面,而是採取與ios相同標籤欄(tab bar),在原型項目(documents)為條列式,在標題顯示可容納更多字元,單一畫面中顯示較多原型項目。
  • 點擊“+”可改為直接進入新增原型頁面,節省一次點擊,目前在app內無刪除原型選項。
提醒視窗_看更多icon 左1:android、左2:ios
提醒視窗_看更多選項 右2:android、右1:ios

於2019年二月兩者統同時發布更新,其實在android版本持續迭代,但下載標題總顯示“尚未發布”。進入APP原型總覽頁(第二層/如上圖左1、2),兩者提醒畫面長得差不多,badge同樣帶有波動效果,右上角加入更多選項用“點擊”,來取代原本原型預覽頁(第三層)“長按”才會顯示的功能;手勢操作“點擊”理應比“長按”優先考慮,“長按”適合用於進階操作,因APP用途為原型預覽,“長按”可為特殊操作使用。

專案內頁 左:android,右:ios

ios專案內頁:

  • 導航欄位移式動態為ios特色,類似點擊啟動圖示開啟APP的動態過程,可幫助使用者理解頁面切換和動線關係,android版app也都這麼做了,其各家系統也可做出改變。
  • 原型頁面無頁面標題,只能靠頁面縮圖判斷是哪個畫面。

android專案內頁:

  • 導航欄為android響應式動態效果,區塊樣式變化是其特色。
  • 標籤欄(tab bar)固定於底部,應與ios版本一致,讓使用者專心於當前原型內容,而非讓動線更複雜,這樣返回按鈕就有三個了。
  • 預覽原型頁面,滑動時過場邏輯有誤,前後頁層級易混淆,ios版則正確。

【mobile01】

首頁 左:android(漢堡選單),右:ios

兩者除遵照官方規範介面,在名稱、圖示風格、內容一致,ios版畫面空間似乎更流暢,留白與間距控制恰到好處,內頁樣式大部分一致;於分類操作稍稍不同,ios導航欄與android漢堡選單影響標籤(tab選項)位置,但兩者介面操作邏輯保有一致性,若轉換系統使用能無痛接軌。

【google日曆、Gmail】

左:android,右:ios

“更多”選項圖標在Gmail信件內頁有明顯差異,google日曆ios版則未放置, 其餘介面與操作體驗幾乎一致。

其他想法:

  • 裝置先天侷限影響介面,android介面既定的返回鍵與操作邏輯,必定與ios介面產生差異,多數人也在意裝置性能(可能與系統特性有關),扁平化介面則可有效提升、與未來介面優化空間。
  • 若漢堡選單適合APP,ios版也可以使用。
  • 一致性並非是介面完全一模一樣,如圖示風格,ios簡約感與android質量感可以個別取用,再保持兩者介面平衡。

chinginge認為:

前一陣子剛開始去了解Android的設計規範時,我就對於沒有遵守設計規範的APP感到困惑,覺得Android就該有Android的樣子,iOS就該是長這個模樣,應該要讓使用者的體驗一致才對。不過所謂的使用者體驗一致,到底是APP本身的體驗、操作相同,還是遵守系統規範,使其跟其他APP操作經驗相同,反而讓我往這方面去思考,也因此就用我個人的使用經驗,來討論遵守設計規範這件事。

我選出了幾個個人常用的APP來做比較,並粗略分成三大類,希望藉此能比較出使用上的差異。

一、個人常用APP

Evernote:左iOS;右Android
This image has an empty alt attribute; its file name is KKBOX.jpg

KKBOX:左iOS;右Android
This image has an empty alt attribute; its file name is MEDIUM.jpg
Medium:左iOS;右Android

很巧的上面這三個APP,很清楚的就能看出他們是依照各系統的規範來設計,因個人是使用iPHONE,所以當嘗試用這三個APP的Android介面時,只能說卡的有點多,先不說互動部分,光是介面的大不同,要找個功能就要花一些時間重新學習,且請使用Android的家人操作比較,對於這三個APP的體驗上,他是較偏好iOS的介面。

二、大家常用個人也常用的APP

This image has an empty alt attribute; its file name is LINE-FB-1024x433.jpg
從左到右依序為:FB(iOS)、FB(Android)、Line(iOS)、Line(Android)

在FB與Line部份,很明顯的看出是在導覽這部分位置不同,iOS是底部導覽、Android是頂部導覽,除了這部份外,其他的介面樣式差異並不大,所以在使用上並不會遇到像第一類的問題,可以滿快上手的。

This image has an empty alt attribute; its file name is IG-YOUTUBE-1024x433.jpg
從左到右依序為:YouTube(iOS)、 YouTube (Android)、IG(iOS)、IG(Android)

YouTube、IG這兩個APP介面可說是一模一樣阿,無論導覽樣式、其他功能的放置位置,圖形等等,所以在體驗上可說是無痛轉換,按照之前的使用方式即可,無需再重新學習適應。

三、google的APP

因Android的設計規範是由google訂定,所以我很好奇google的APP在這兩個系統上的介面設計有無差異,所以也挑選多數人使用的APP來比較一下。

This image has an empty alt attribute; its file name is chrome-gmail-1-1024x433.jpg
從左到右依序為:Chrome(iOS)、 Chrome(Android)、gmail(iOS)、gmail(Android)

在Chrome部分,兩個系統是不一樣的,iOS是用底部導航,Android則將功能選項放在右上的更多。 iOS在去年更新介面後,個人就非常喜歡這個新介面,因此當回到Android的介面時主要是不太習慣,不過Android的介面也是iOS的舊介面,所以倒也是很快的能上手,只是google將iOS的介面改變,一定不是只為了要遵守iOS的規範,背後也許有很多的數據、資料來支持這部份的改變。

This image has an empty alt attribute; its file name is 日曆-相簿-1024x433.jpg
從左到右依序為:日曆(iOS)、 日曆(Android)、相簿(iOS)、相簿(Android)
This image has an empty alt attribute; its file name is MAP-1024x433.jpg
從左到右依序為:地圖首頁(iOS)、 地圖首頁 (Android)、導航(iOS)、導航(Android)

從gmail、日曆、相簿到地圖這幾個APP,基本上他們的介面是一樣的,有些功能的放置位置雖不同,但也都能很快的找到,所以也沒有太大的適應問題。

四、購物類型的APP

個人是一網路購物的愛好者,因此國內大型的購物網站APP我大部分都使用過,像雅虎購物中心、雅虎商城、蝦皮拍賣、MOMO乃至大陸的淘寶等,也因此發現購物型的APP在這兩個系統上,在介面設計這部分幾乎都是一致,即使有些小小的不同,多是互動設計所需(像因Android有實體的返回鍵,而iOS沒有這部分就有差異,但對使用上是沒有太大影響的),我想也許是要讓使用者能夠順利的完成每一次的購物,降低重新學習的機率,進而促進結帳的轉換率,而讓兩個系統的體驗一致。

This image has an empty alt attribute; its file name is 蝦皮-雅購-1024x433.jpg
從左到右依序為:蝦皮拍賣(iOS)、蝦皮拍賣(Android)、雅虎購物中心(iOS)、雅虎購物中心(Android)
This image has an empty alt attribute; its file name is 亞馬遜-淘寶-1024x433.jpg
從左到右依序為:Amazon(iOS)、 Amazon(Android)、淘寶(iOS)、淘寶(Android)

五、總結

經過上面那些APP的體驗比較,其實可以很明確的知道設計一致的好處之一,就是使用者即使換了不同的手機系統,依舊能照以前的使用習慣來操作,不用重新學習;不然就像FB與Line的中間做法,即配合則系統的規範,但介面設計與互動變化不大,讓使用者也能快速熟悉;而當兩則差異大時,這對使用者來說就需花時間學習,陣痛期會比較久一點。

設計的需求牽涉廣泛、是有滿多面向需一起評估的,像是開發成本、數據資料、使用者需求等等,這些因素都是會影響APP的設計,但是我想最終的考量還是使用者需求,也就是說如當某個需求在某個系統規範上是不支持時,身為產品規劃的我會選擇滿足使用者需求,那規範就參考吧。


uirater認為:

通常會有這個疑慮,主要考量iOS與android的APP介面是否該一致?

若按照官方規範設計介面,兩種系統的APP會有各自的模樣(圖1),通常在導覽系統可看出明顯差異。這一派的支持者認為,官方規範會貫徹到手機系統的內建APP,比如通話、訊息、照片、行事曆等等,因為用戶免不了要開啟這些基本功能,終究得學會如何使用。一旦熟悉操作模式後,可以快速上手其他遵照官方介面規範的APP,不用重新學習,這對於使用體驗是利多。

好像滿有道理,但真的是這樣嗎?

圖1 (左)android,(右)iOS的FB,主畫面最大差異是導覽列。

另一派的觀點認為,兩種系統的APP介面可以一致,每日活躍用戶達10億人次Instgarm正是代表案例(圖2),甚至客製UI自成一格。一致的版面首先可以減輕規劃和設計的負荷,如果工程師也能支援,這個方式就可行。其實不光是開發階段,APP上架後還有維護跟優化,所以起頭的決策會產生長遠的影響。

但APP的使用者往往不是開發團隊,不是使用體驗優先嗎?怎麼會先考量開發者的工作量?

圖2 iOS、android的Instagram僅有細微差異,主畫面可視為一樣。

這兩派的觀點各有道理,如果先把事情簡化,我個人比較偏向介面一致的做法。如果開發團隊已能充分掌握用戶行為,即使不照兩大系統的介面規範,還是可以做到良好的使用體驗,甚至比官方的做法更好。

支持介面一致,我有兩個理由。

首先,智慧型手機、APP都已成熟,至今兩大系統的介面仍保有各自特色,但主要操作模式不會相去太遠,所以熟悉iphone的用戶,轉換到android不會變成手機白痴,反之亦然。原因在於iOS、android持續調整介面規範時,都會互相參照優點,比如material design以前沒有bottom navigation,但是在大螢幕手機形成主流後,為了方便單手操作,也比照了iOS的Tab Bars,追加這個介面組件。好不好用的感受不會天差地遠,即使兩大系統的規範內容有所不同,最終還是會往共通的使用經驗靠攏,也就是簡單易用的介面永遠受歡迎,這才是開發者應該關注的重點。 所以熟悉官方規範,是為了截長補短,綜合兩方的優點,變成自己的最佳方案。

再來,好不好用,要做用戶測試,也要觀察行為數據,通過了才算數。那些主張按照官方規矩的論點,說到底沒有佐證,少了證據便缺乏說服力。以玩運彩討論區APP為例,改版時為了顧及現有用戶的習慣,在iOS與android系統都是同款介面,上線前實做用戶測試所發現的問題,沒有一項的發生原因是未按照官方規範。應該說操作流程的問題,並非介面規範能夠解決,反而原本我們以為很方便的swipe left/right手勢操作(圖3),撈出行為數據時才發現沒人使用,而且有部分用戶未發現下方的bottom navigation。我們直覺以為bottom navigation很明顯,應該很容易發現,但從數據來看,不見得如此。所以光用推論的方式,很有可能主觀偏誤。

圖3 可swipe left/right切換頁面

雖然我個人傾向介面一致,但要更謹慎的話,我的答案會變成看情況。這個回答不是取巧,因為考慮的層面變多了,需要綜合評估以下面向後取得共識。

1.用戶因素
這個因素列為首要重點,如果沒人會用,後面就不用談了。
對於一款新的APP,若缺乏既有的數據資料(圖4),可以先用人口統計變項初步分析目標對象:

  • 年紀:兒童、年輕族群、中年人、銀髮族。
  • 性別:男性、女性。
  • 國別:本地、多重語系。
  • 其他…。

不用多做解釋,針對年輕族群或銀髮族設計的介面,重點會不一樣。

我們印象中的年輕族群,大多熟悉網路、3C,學習力也夠,可以快速舉一反三,所以開發者不見得要死守規範,可以嘗試更有意思的操作方式。但是銀髮族比較不具備以上特質,既有的使用習慣反而重要,即使開發者認為理所當然的操作,也不能直覺以為年長者可以輕易上手,這時遵守官方規範就有其必要。

圖4 firebase偵測到玩運彩討論區APP的audiences年齡分佈,25~44歲為大宗。

2.產品因素:改版 VS 全新
如果是改版,要先考量用戶既有的使用習慣。當APP的UX原本沒有重大問題,大幅度的改版會導致用戶必須重新學習、適應,很容易引起反彈,這點不是按照官方規範執行就能解決。所以與其一次大改惹怒用戶,不如分階段微幅改動,溫水煮青蛙。

如果是全新的APP,要看是否已有網站上的服務。如果沒有,代表產品尚未問世,這時自由度比較高,行有餘力還可以考量跨裝置、跨平台的問題。但如果產品已有完善的手機版網頁且有用戶基礎,之後才推出APP,那麼APP的UI比照辦理手機版網頁會比較好,用戶才能無痛接軌。

3.團隊因素
APP除了開發,還要維護。開發團隊如果對APP的掌握度不夠,對良好的使用體驗也沒概念,可以先遵照官方規範的指示,至少站在巨人的肩膀上是相對保險的做法。不過長遠來看,還是要盡快補足人力與能力方面的空缺,畢竟官方規範的重點在於提供「標準」,內容並無法啟發我們規劃出理想的資訊架構,以及便捷的操作流程。也就是說,遵守規範並非APP好用的充分條件,所以這部分的優化還是要靠人去克服。

4.趨勢因素
除了沒得商量的規定得遵照發佈平台的要求,比如啟動圖示的規格,其他APP內的介面設計大多由開發團隊主導,這時選擇照官方規範執行的開發團隊還會遇到一個常態問題:更新

官方規範會因應趨勢、系統與硬體變革而持續調整,有時出現大幅更新,像是2014年發佈的Material Design。面對這些變化,守規矩的開發團隊勢必得抉擇導入新規範的時機,是立即跟進嗎?還是等新的規範普及後再處理?這點沒有標準答案。

即便導入後,上架新的版本,如何得知用戶的感受?特別當舊版已有良好的使用體驗,採用新的規範後會不會造成反效果?

——

以上四個層面的考量都有一項共通特質-推論。開發團隊的預想可能和終端用戶的感受大相徑庭,所以要以實證資料為準。在驗證通過之前,即便是Apple或Google制定的規範,都該視為合理的假設,若沒通過驗證,照樣要修正。

實證資料的取得方法包含質化、量化:

  • 易用性測試:若是介面有大幅改版,或是全新的產品,可以做出仿真的原型(prototype)後邀請5~10位用戶參與易用性測試,協助開發團隊找出介面的重大問題。如果用戶不會使用,功能再完整都是白搭。
  • MVP測試:做出最小可行產品(Minimum Viable Product)後邀請用戶試用一段時間,再回訪用戶的感受。請用戶試用意謂產品是真的可以使用,只是功能限縮,僅提供最必要的項目而已,目的在於驗證產品的價值假設,這點是跟易用性測試不同的地方。
  • A/B testing:也就是做實驗,有實驗組、控制組。當APP進入到優化階段,針對小部分的變更,可以透過A/B testing取得量化數據來驗證開發團隊的假設。
  • 行為數據:偵測用戶在APP中的操作行為,畢竟用戶的說法可能和實際情況有出入。

——

延伸閱讀:


發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *