如何設計iOS導航？騰訊高手從2個方面深入分析！

本文主要探討的是在iOS交互設計中，針對「是否應該有首頁 Tab」和「保持底部導航欄常駐」這兩點差異展開討論。

蘋果全球開發者大會（WWDC22）在今年 6 月如期舉行，大會主要目的是向研發者們展示最新的軟件和技術，其中也不乏一些設計思想。今天的文章引自會上蘋果設計師分享的關于如何改善 iOS 導航的視頻，結合了新觀點來探討 iOS 導航建議與實際設計中的差異。

一、iOS 導航建議概述

導航的目的是幫助人們盡快熟悉界面，以輕松發現內容并與 App 進行互動。好的導航能讓人把注意力都集中在內容和體驗上。導航會告訴人們在你的 App 中如何呈現項目、如何尋找信息以及如何實現目的。而導航跟用戶的自然認知落差太大，就會讓用戶感覺這個 App 很不好用。

原視頻 1 陳述了底部導航欄（Tab bars）、層級式導航（Hierarchical navigation）及模態式呈現（Modal presentations）的各種改良技巧與方法。底部導航欄即我們常見的全局標簽式導航，我們也稱 Tab；層級式導航出現于由上層往下層信息深入的時候，通常表現為從右往左推進頁面；模態式呈現專門用于展示某個界面中的獨立任務，通常表現為從下往上呈現。蘋果提出，底部導航欄的幾個設計要點有：

1. 使用底部 Tab 反映信息層級；
2. 使用清晰簡潔的文案；
3. 底部 Tab 間的功能分布平衡，無重復或耦合；
4. 避免在同一個頁面反復強調一個功能；
5. 保持底部 Tab 導航欄常駐。

其中，「使用底部 Tab 反映信息層級」與「使用清晰簡潔的文案」相對明確；「底部 Tab 間功能分布平衡」和「避免在同一個 Tab 頁面反復強調同一個功能」常與首頁的設計相悖，由此引發蘋果“刪除首頁”的建議；「保持底部 Tab 導航欄常駐」指全局導航欄必須始終位于屏幕底部，包括進行層級交互時，僅當模態交互時隱藏底部全局導航。這或多或少和我們常見的 App 設計實踐有所出入，下面針對「是否應該有首頁 Tab」和「保持底部導航欄常駐」這兩點差異展開討論。

二、是否應該有首頁 Tab

1. iOS 建議 vs 實際現狀

蘋果不建議 App 在底部 Tab 中設置「首頁」，因為首頁常被用來一次性展示 App 內部的所有功能，因此會破壞了 App 的層級結構，這造成的負面影響是多方面的：

1. 用戶需要大量翻頁才能找到想要的內容，并且要消耗精力來排除無關功能的干擾；
2. 用戶使用 App 完成不同行動時涉及到的功能乃至思維方式都是截然不同的，而堆砌在首頁的功能缺乏足夠的內容支持，影響了用戶的使用決策；
3. 如果因為碰巧點擊某個元素而被迫切換到其他 Tab 的功能頁面還會導致用戶暈頭轉向。

另一個常見的現象是在同一個 Tab 頁面內（常常是首頁）反復強調同一個功能，然而過多的重復功能將使用戶弄不清信息本應在哪里又為什么被放置到那里。無論是功能在 Tab 間的重復還是頁面內的重復都可能導致用戶被“困”在首頁而直接放棄探索導航欄其他區域。

假設一個兼具篩選地點、規劃行程與我的路線的騎行規劃 App，常出現這樣的首頁設計

蘋果建議放棄首頁，以清晰的結構劃分 Tab

同時蘋果也澄清了，此處所說的「重復」特指「功能的重復」，而非「內容的重復」。在不同的界面，用不同的方式顯示同類型內容如歌曲或照片是合理的。但功能就不一樣了，因為功能涉及到人們出于某種目的所要采取的行動，這種時候重復將讓用戶感到困惑。

盡管蘋果內置 App 堅持著無首頁的設計方案，但縱觀國內外 App，多數產品都會使用首頁，例如國外的 Twitter、Facebook、Youtube...國內的淘寶、Bilibili、豆瓣...反而沒有首頁的產品屈指可數。在首頁的設計上出現實際應用與規范建議的偏差可能是由以下的原因造成：

2. 此"首頁"非彼"首頁"

我們常見的全局導航可以簡單歸為兩類：

1. 一種表現為通過 Tab 平鋪 App 內的所有功能，功能之間互斥、涇渭分明（例如微信讀書、airbnb）；
2. 另一種表現為首頁 Tab +關鍵內容/功能 Tab，整體 Tab 間呈現總分結構（例如 ins、微博、豆瓣）。

前者較多出現在功能型產品上，以功能劃分 Tab，后者較多出現在內容型產品，圍繞內容歸屬、內容類型等內容維度劃分 Tab。因此使用首頁的產品也多為內容社區型或有意轉型為內容社區的產品。

蘋果建議規避的是功能在首頁的重復推薦，這種方式相當于用首頁做了一個全站的功能介紹和導航，自然與底部的全局導航有沖突。如上述所說，我們常見的首頁推薦多是內容上的推薦，這種情況僅是引用了“首頁”的概念，而非蘋果推薦刪除的“首頁”(聚合了其他 Tab 的功能)。類似圍繞推薦能力進行內容投放的 Tab 在蘋果設計中也有呈現，只是不叫“首頁”，而叫“推薦”，Apple Store 中就有“為你推薦” Tab。

以“首頁”之名行推薦之事的情況

3. 設計視角不同

雖說常見的“首頁”更多是基于內容的推薦，但偶爾也能見到首頁重復曝光其他 Tab 功能的情況。加上有時內容與功能之間的界限沒有這么清晰，比如在圖文信息流里插入推薦的小組討論時，很難厘清推薦的屬于小組的信息內容還是加入討論的功能，因此由于加入首頁導致用戶放棄探索導航欄的問題確實存在。然而我們很少會否定這樣的設計，之所以如此，可能是操作系統設計視角與軟件設計視角的區別。蘋果是手機廠商，可以在銷售手機時預先安裝 App，內置軟件無下載門檻，因此可以做到每個 App 各司其職，天氣 App 只需要做好天氣展示，音樂 App 只需要做好聽歌體驗。App 定位穩定且單一使 Tab 間很容易做到清晰、平衡。而 App 開發商不同，需要不斷拓寬業務范圍，產品成熟后要尋求突破，一旦尋求突破就很難在不打破原有底部 Tab 結構的情況下維持結構清晰。這時首頁推薦就作為一種折衷的“萬能”方案出現了。當然也不是說有“理由”了就可以心安理得地往首頁塞功能，蘋果的建議不無道理，比起完成“萬能”方案，探索合理且有效的解法更值得我們投入精力。

三、保持底部導航欄的常駐

1. iOS 建議 vs 實際情況

依照蘋果的觀點，保持底部導航欄的常駐能幫助用戶在不同層次的信息間輕松切換，同時各層級間的關系還能保持清晰。比如我可以在“城市”頁面查看一條新路線，并與我“行程”頁面里一條行程中已存儲的路線作比較，后者在“行程”的層級中要低兩層，要實現這種比較，不同頁面就必須目的明確，內容的區分也要細致。

對比城市 Tab 里找到的路線和行程里已有的路線

至少自 07 年 iOS2 問世以來，蘋果的內置 App 就一直在層級切換中保持底部導航欄常駐，且國外產品（Twiter、Youtube、Ins、Facebook...）也都遵循這項建議設計。相比之下，國內產品幾乎找不到常駐底部導航欄的產品。

為什么會出現這樣國內外的差異，或許我們可以從以下幾個方面來思考：

2. 在一個 Tab 做完事再去另一個 Tab？

iOS 建議「保持底部導航欄常駐」的出發點是“讓用戶始終能訪問 App 的核心區域，幫助用戶在不同層次的信息間輕松切換，同時各層級間的關系還能保持清晰”。我認為它的核心思路是 Tab 之間功能清晰平衡的情況下，用戶不需要在 Tab1 做完一件事后，再去做 Tab2 的事，也就是說兩個 Tab 的功能可以一起執行，甚至可以互相影響（如上文舉例的對比城市 Tab 里的路線和我的行程里的路線）。從該角度上看，保持底部導航欄常駐也適用于國內 App。

3. 沿襲自網頁端設計

保持全局導航常駐的思想很有可能沿襲自網頁端設計。Steve Krug 在《Don‘t Make Me Think》一書中提到（06 年）：

導航應該總是出現在這里...僅僅讓導航部分在每一頁以一致的外觀出現在同樣的位置這一點，就會讓你立即確認自己仍然待在這個網站上...如果在網站上找不到方向，人們不會使用你的網站...

后續也有其他作者在書中提及：

（全局導航）是固定的，不會在用戶瀏覽網站的過程中變動...瀏覽網站時，用戶可以通過全局導航大致明白自己所在的位置，并能通過它跳轉到主界面，這樣的話，即使迷失了方向，也可以順利回到主路徑，在結構化內容中，這就像安全出口一樣。你也可以把它說成傳送門，用戶能夠借此在產品的主要區域之間跳轉。
——《內容即未來》Mike Atherton

可以看出，自網頁端設計以來，全局導航就被建議保持常駐，這一思想也在移動端被繼承下來了。而進入移動端后，這一思想是否依然有效？從上述引文中可以看出網頁端需要常駐全局導航的原因（“確認自己仍然待在這個網站上”“迷失時的安全出口”）在移動端似乎并不成立。網頁端很容易在連續點擊中跳出原本瀏覽的網頁，而移動端除非用戶主動退出或殺掉 App，否則就會持續在 App 內。App 的層級和復雜度也相比網頁更低，用戶在 App 內迷失的情況很少。既然保持常駐的理由在移動端已消失，拒絕常駐也未嘗不可。

4. 占用屏幕空間

大多數國內產品都選擇不常駐，或許更大的原因是保持底部 Tab 常駐會占用屏幕空間。這是產品設計從桌面端轉移到移動端后繞不開的問題。為此，也曾涌現出了許多導航設計，例如跳板式（也稱 Launchpad）、抽屜式、列表式等等...

16 年以前，或許是出于減少占用屏幕空間、增加導航欄數目的目的，安卓的設計規范一直倡導導航欄相關要素應置于頂部，側邊抽屜導航搭配頂部導航使用。直到 16 年才提出了底部導航的概念。在這期間，Facebook 針對抽屜式導航與底部標簽導航進行了 AB 實驗，并最終投入了底部標簽導航的懷抱。雖然沒有找到 Facebook 的實驗文章，但國外某設計團隊做了相同的實驗，并得出了結論：使用側邊抽屜導航會減少一半的用戶參與度 ?。

在「穩定呈現」與「減少屏幕占用」的多年博弈中，底部導航欄似乎獲得了最終的勝利，但即使在幾乎所有 App 都一致使用底部導航欄的現在，為了節省屏幕空間占用，Meterial Design 的設計規范中仍有一項是允許在頁面滾動的時候隱藏導航欄，可見占用屏幕空間仍是困擾設計的“頭等”大事，而國內的設計選擇在二級及以下層級的頁面隱藏導航欄，或許也是更好的解決方式之一。

四、總結

蘋果在 WWDC22 上分享的 iOS 導航建議，可以總結如下：

底部 Tab 導航、層級導航和模態式呈現這三種基礎的導航模式反映了日常流程設計中的三種思路：并行、串行與打斷。

1. 全局底部 Tab 導航欄是并行的設計思路。全局底部 Tab 展示了 App 的主要功能，主要功能之間允許并行執行。
2. 層級導航是串行的設計思路。層級導航隱藏的含義是一屏只做一個決定直到用戶到達目的地。當用戶要去另一個目的地時，必須原路返回，重新做出不同的決定。隨著細節的推進，內容應當越來越具體，選擇應當越來越少。
3. 模態式呈現是打斷的設計思路，它強調了用戶在完成或者取消當前任務前，不能進行其他操作，所有注意力都應集中在當前任務。

在實際的 App 設計中，我們沒有嚴格遵循 iOS 規范，對此也不必太過驚慌失措。規范建議并非一成不變，而是持續發展的。要知道在 19 年時，蘋果對導航的分類還是層級導航、扁平導航與內容/體驗驅動導航。可見規范會隨著時代的進步和產品的迭代更新變化，與其一味地照搬照做，不如探索規范形成的原因，在了解設計理念的基礎上，結合自身業務做新的嘗試，或許會有規范之外的意外收獲。

參考文獻：

1 https://developer.apple.com/videos/play/wwdc2022/10001/

2 https://material.io/components/bottom-navigation#specs

3《移動應用 UI 設計模式》Theresa Neil, 2013

?《Don't Make Me Think》, Steve Krug, 2005

? https://thenextweb.com/news/ux-designers-side-drawer-navigation-costing-half-user-engagement

?《內容即未來·數字產品規劃與建模》, Mike Atherton, 2018

歡迎關注作者微信公眾號：「We-Design」