Day 13｜手機版不是把 Sidebar 縮小：Header、Navbar、Sidebar 與 Bottom Navigation 怎麼分工

安安～我是ChiYu～

昨天，我把邀請成員和建立活動的流程接了起來。想說順手切到手機尺寸看一下，瀏覽器才剛縮到 360px，桌面那條 Sidebar 依然很有自己的想法，硬是占著半張畫面。

內容區已經快被擠成收據了，它還站得筆直。

圖 1：和昨天結尾是同一張還原畫面。Sidebar 沒有變成手機導覽，只是把選單與內容一起壓窄。

昨天先讓它露個臉，今天來拆問題。選單名稱被截成省略號、正文只剩半張卡片的寬度，整個畫面卻找不到開啟或關閉導覽的入口。

問題就出在一開始的需求：

「幫我做一個 SaaS 後台，要有 Header、Sidebar，手機版也要能用。」

AI 確實做了 Header，也做了 Sidebar；手機版當然也看得到。每一項都能打勾，合在一起卻漏洞百出：完整側欄被壓進窄螢幕，設定、活動紀錄和專案全部搶同一塊空間，使用者還得靠底色猜自己在哪一頁。

這正是 Vibe Coding 很容易遇到的狀況。你說了想要哪些元件，AI 就把元件都端上來；但你沒有交代誰比較重要、手機要留下什麼，它只好把桌面版縮小交差。

今天要處理的，就是同一套目的地到了不同裝置該怎麼重新分工。我會拆開 Header、Navbar、Sidebar Navigation、Navigation Menu、Bottom Navigation 與 Current Page Indicator，也把完整操作放進 UI 元件百科的導覽 Demo。你可以直接收合側欄、切換目前頁，再把瀏覽器縮小看看手機選單會不會露餡。

圖 2：畫面上的元件都能帶人前往別處，但它們負責的層級、頻率和裝置完全不同。

如果只叫 AI「做一套導覽」，它很容易把這六個角色當成六種造型。接下來得先把工作分清楚，才不會做出一個到處都有選單，使用者卻還是找不到路的後台。

AI 有做手機選單，只是把 Sidebar 壓扁了

原始 Prompt 真的只有一句：

做一個 SaaS 後台的側邊選單和手機版選單。

開頭那張圖，是依同一份模糊 Prompt 在網站還原的問題現場。原始實驗在 2026 年 7 月 24 日使用 Codex Desktop 完成，可惜當時沒有保存模糊 Prompt 產出的第一張畫面。為了讓前後差異還能被檢查，我在 7 月 27 日用當日 GPT-5 系列模型重跑一次，刻意不提供目的地頻率、手機優先順序與焦點規則；下面這張才是當次重跑留下的畫面。

圖 3：第一版桌面很像管理後台，手機也真的「有選單」。問題是每個目的地都被當成一樣重要。

有一說一，單看桌面版，我大概會覺得它已經有七八十分：品牌、側欄、目前頁的底色都在，看起來也頗像一套正經的 SaaS 後台。

切到手機後就不是這回事了。

• 完整 Sidebar 直接縮進左側，正文只剩一小條。
• 活動紀錄、設定與高頻入口一起搶空間。
• 目前頁只靠底色表達，顏色不明顯就很難辨認。
• 它提供了「手機選單」，卻沒有替手機使用者決定什麼最值得留下。

AI 第一版不是少做一個元件，而是少做一層判斷。這一層得由我補上。

先別急著挑元件，先算目的地出場幾次

我先把 LumenDesk 的使用情境攤開來看：概覽、成員與專案會頻繁切換；設定和活動紀錄必須找得到，但不值得一天到晚占著手機底部；搜尋、帳號與通知則是跨頁都可能使用的工具。

於是，同一批目的地被重新分成這樣：

這張表才是真正需要交給 AI 的資訊架構。只寫「要有 Header 和 Sidebar」，講的是零件；補上頻率、層級與裝置，才是在交代零件怎麼一起工作。

桌面空間夠，LumenDesk 選擇用 Sidebar 攤開完整結構；手機空間少，Bottom Navigation 只留高頻入口，完整導覽再由 Header 開啟。Navbar 會留在文章裡比較，但不和 Sidebar 重複放置同一批主要目的地。兩套主導覽一起全勤，不會讓路更好找，只會讓使用者開始懷疑到底該看上面還是左邊。

如果還是分不清楚，可以先記住下面這張角色表：

名詞先有了，接著一個一個看它們到底在負責什麼。

Header：別把全站頁首變成 UI 雜物抽屜

圖 4：Header 承接品牌、帳號與手機主選單入口；各頁自己的操作，留在各自的內容區。

Header 元件頁裡放了品牌、目前工作區、帳號，以及手機版的主選單入口。這些東西有一個共通點：使用者走到哪一頁，都可能需要它們。

Header 很容易被當成「不知道放哪就先丟這裡」的區域。搜尋、篩選、儲存、匯出、通知、語言、深色模式全部排成一列，最後每個功能都在，真正要用時卻像在工具箱底部撈螺絲。

判斷方式很簡單：這個操作如果只屬於目前頁面，就讓它留在頁面裡；只有跨頁共用的入口，才值得進入 Header。到了手機版，Header 還要多負責一件事：提供開啟完整導覽的按鈕，但不用把完整清單直接攤在上面。

Navbar：同層目的地一多，畫面就開始塞車

圖 5：Navbar 適合概覽、成員與專案這類同層級目的地；項目一多，就該重新分組。

Navbar 元件頁示範的是少量、同層級而且常常往返的目的地，例如「概覽、成員、專案」。這幾個頁面沒有誰包著誰，重要程度也接近，排在同一列能讓人快速切換。

但 Navbar 的空間不是吃到飽。當項目長到八九個、名稱開始折行，或需要分成「工作區」與「管理」兩組時，就表示它已經扛不住了。這時應該換 Sidebar Navigation 承接結構，低頻項目則收進 Navigation Menu。

AI 常會因為畫面塞得下，就繼續往 Navbar 加。我的驗收不只看有沒有溢出，還會問：使用者能不能一眼看出這些目的地彼此是同一層？不能的話，排成一列也沒有比較清楚。

LumenDesk 這次沒有同時採用這套 Navbar。它的管理功能需要分成「工作區」與「管理」，所以桌面版選擇 Sidebar 作為唯一的主要導覽。如果產品只有概覽、成員、專案三個平行區域，我才會改用 Navbar，並把 Sidebar 拿掉。元件比較頁可以把兩種方案都攤開，正式畫面不用為了證明我認識它們就全部裝上去。

Sidebar Navigation：左邊那條灰色區域，其實是資訊架構

圖 6：桌面 Sidebar 將工作區與管理項目分組，也提供收合與目前頁標示。

Sidebar Navigation 元件頁把「概覽、成員、專案」放在工作區，再把「活動紀錄、設定」放進管理。畫面上只是多了分組標題，使用者卻不用在五個平鋪項目中來回掃描。

Sidebar 適合桌面後台，因為它能同時呈現較多目的地、群組與層級。它也可以收合，替內容區讓出空間；不過收合不是把東西變不見，使用者必須能再把它展開，只剩圖示時也要知道每個入口通往哪裡。

這句話看起來很基本，我第一次實測時還是翻車了。

收合動畫很順，連結名稱卻一起蒸發了

2026 年 7 月 24 日，我在網站按下「收合側邊導覽」。側欄成功縮成圖示列，正文仍顯示目前在「成員」，展開按鈕也好好留著。只看截圖，這個 Demo 很容易被判定完成。

接著我檢查瀏覽器讀到的結構，才發現部分導覽入口只剩沒有名稱的 Link。視覺使用者也許還能猜圖示，鍵盤與螢幕閱讀器使用者卻失去了「概覽、成員、專案」這些目的地名稱。

這就是「看得到」和「真的能用」之間的差距。原本我只要求收合後保留 Tooltip，實測後把條件改成：「收合後，每個 Link 在瀏覽器可存取結構中仍保留原本名稱；鍵盤焦點移到圖示時，也能辨認目的地。」

W3C 將 <nav> 視為導覽地標；同一頁有不只一組導覽時，還要為它們提供可區分的名稱，例如「主要導覽」與「側邊導覽」。不然輔助科技一路讀下去，只會遇到好幾個都叫 navigation 的區域。W3C WAI：Landmark Regions

AI 做出收合動畫，只能算完成一半。連結名稱留得住、按鈕能展開回來，這個狀態才算完整。

Bottom Navigation：手機底部不是網站地圖

圖 7：Demo 底部有三個目的地與一個「更多」開關；設定與活動紀錄則由完整選單提供。

Bottom Navigation 元件頁在手機底部放了「概覽、成員、專案」三個目的地，外加一個「更多」開關。前三個是使用者拿著手機時最常往返的頁面；第四個不是目的地，而是開啟完整選單的操作。

設定和活動紀錄沒有被刪掉，它們只是搬進 Drawer。這個差別很重要：刪掉會讓功能失蹤，重新分工則是讓低頻功能退到第二層，同時保留找得到的路徑。不過這也代表畫面混用了 Bottom Navigation 和選單開關，不能把四個項目全部稱為「四個同等重要的目的地」。

Android 的 Navigation Bar 指南把使用時機寫得很明白：精簡視窗中，放三到五個重要程度相近、會在各畫面持續出現的目的地。Bottom Navigation 一旦塞到六個、八個入口，每個點擊範圍和標籤都會開始縮水。畫面看似非常完整，手指只要稍微偏一點，就可能直接去隔壁頁串門子。Android Developers：Navigation bar

因此，LumenDesk 最後的規格只把「概覽、成員、專案」留在 Bottom Navigation。完整選單統一由 Header 的「開啟主選單」按鈕負責，不再讓底部的「更多」同時扮演目的地。網站 Demo 仍保留這個混合版本，正好可以拿來看出兩種角色混在一起時，規格名稱有多容易被帶偏。

Navigation Menu：低頻入口沒有消失，只是先讓出舞台

圖 8：Navigation Menu 暫時收納低頻連結，除了打開，也必須交代怎麼關閉。

Navigation Menu 元件頁裡的「更多」不是另一個目的地，而是一個開關。使用者點下去，才會看到活動紀錄與設定等低頻連結；選單要有清楚的展開狀態，點到外面或按 Escape 後也得收得回去。

如果裡面只是一般頁面連結，用揭露式清單就夠了。不要只是覺得 menu 這個字比較專業，就硬套桌面軟體那套命令選單；那會多出一整組鍵盤規則，最後 AI 做了外觀，操作卻只完成一半。

手機 Drawer 也有相同的驗收重點：從 Header 按鈕打開後，按 Escape 可以關閉；關閉時，焦點要回到原本的按鈕。使用鍵盤的人才不會在選單消失後，連自己站在哪裡也一起弄丟。W3C 的 Disclosure Navigation 範例也把 Enter、Space、Escape 與焦點處理列入互動條件。W3C WAI：Disclosure Navigation

Current Page Indicator：別讓三組導覽各說各話

圖 9：Header、Sidebar 與手機導覽都指向同一個目前頁，可見樣式與 aria-current="page" 也要同步。

Current Page Indicator 元件頁解決的是「我現在在哪裡」。LumenDesk 同時有 Sidebar、手機底部導覽與頁面標題，使用者切到「成員」時，三個位置都要說同一件事，不能 Sidebar 選著成員，底部卻還亮著概覽。

目前頁也不能只靠一個不太明顯的藍色底。文字、圖示、背景或外框可以一起提供差異；程式結構則用 aria-current="page" 把目前位置交代給輔助科技。WCAG 的 ARIA26 技術文件就是用 aria-current 表達這類狀態。W3C WAI：ARIA26

一套導覽只要回答不了「我在哪裡」，使用者即使找得到入口，也很容易懷疑剛才到底有沒有切換成功。

我沒有要求更多元件，只是把責任寫完整

理解六個元件後，我沒有叫 AI 再加一套炫一點的手機選單，而是把目的地頻率、跨裝置分工與驗收條件補回 Prompt：

為 LumenDesk 團隊工作區建立一套響應式全站導覽。先依目的地頻率與層級分工，不要把桌面 Sidebar 直接縮到手機上。

桌面版：
- Header 左側放品牌 LumenDesk；右側放帳號入口。
- 本後台選擇 Sidebar Navigation 作為唯一的主要導覽：概覽、成員、專案分為「工作區」，活動紀錄、設定分為「管理」。提供收合按鈕；收合後必須仍可用同一按鈕展開。
- 不要再用 Navbar 重複顯示概覽、成員、專案。若產品改成只有 2 到 4 個同層級目的地，可以改用 Navbar，並移除 Sidebar。

手機版：
- Header 保留品牌、帳號與「開啟主選單」按鈕。
- 點擊後以 Drawer 顯示完整導覽；Escape 可關閉，關閉後焦點回到開啟按鈕。
- Bottom Navigation 只固定顯示三個同等重要的高頻目的地：概覽、成員、專案。設定與活動紀錄留在 Drawer；不要再放一個假裝是目的地的「更多」。

狀態與驗收：
- 每一組導覽都以文字與可見樣式標示目前頁，並在目前連結加上 aria-current="page"。
- 不同導覽區域使用有名稱的 nav，例如「主要導覽」與「側邊導覽」。
- 360px 寬度下，Sidebar 不應和內容並排；完整清單改由 Drawer 提供。
- 不使用只有顏色才看得懂的目前頁狀態。

這版 Prompt 沒有要求 AI 換一個框架，也沒有規定 Sidebar 要幾個像素。真正改變結果的，是每個元件在桌面和手機上的工作，以及做完後要怎麼驗收。

第二版先救回手機版，收合後的名稱卻還沒過

圖 10：第二版桌面選擇 Sidebar 作為主要導覽，保留完整分組，也能收合替內容讓出空間。

圖 11：第二版手機把完整清單交給 Header 的 Drawer；底部 Demo 仍看得到「更多」混合入口，正式規格會移除它。

重新分工後，桌面 Sidebar 可以收合，手機也不再把完整側欄和正文並排；360px 下沒有整頁水平溢出。可是第一輪複測收合狀態時，部分只剩圖示的連結依然失去可辨識名稱。

所以這時候還不能寫「導覽完成」。比較準確的結果是：

這個結果也提醒我，改寫 Prompt 不會神奇地讓整個介面一次畢業。它只是讓問題變得可以逐項抓出來，而不是看著一張漂亮截圖猜「應該可以吧」。

修正後複測：這次入口名稱真的留下來了

我把下一輪條件寫得更直接：「收合只隱藏可見文字，不得移除連結的可存取名稱。」

2026 年 7 月 27 日重新檢查時，概覽、成員、專案、活動紀錄與設定五個 Link 在收合後都保留完整名稱；展開／收合按鈕的名稱也會跟著狀態切換。本機的可存取結構與鍵盤複測通過。

目前仍未驗證的是正式螢幕閱讀器實聽與 200% 縮放。這兩項不能因為 DOM 已經有 aria-label 就直接當作通過；同樣地，已經修正並複測的入口名稱，也不該繼續寫成目前失敗。

如果你正在做自己的後台，可以到 桌面與手機導覽架構比較頁照著做三個動作：

1. 收合 Sidebar，再把它展開。
2. 切到「設定」，確認每一組導覽都同步指出設定。
3. 把寬度縮到 360px，開啟 Drawer 後按 Escape，確認焦點回到觸發按鈕。

這三步都能走完，才算從「有做手機版」往「手機上真的能用」前進了一大段。

導覽把我送到頁面，頁面裡又冒出五種「進度」

這次我沒有替手機硬留完整 Sidebar，也沒有讓 Navbar 與 Sidebar 在桌面重複上班。Header 管共用入口，桌面選擇 Sidebar 攤開資訊架構；若產品只有少量平行頁面，才改由 Navbar 接手。Bottom Navigation 留住手機高頻目的地，Navigation Menu 暫時收納低頻功能，Current Page Indicator 則讓不同裝置別各說各話。

現在，我終於能從任何裝置順利進入「帳號申請」。結果頁面一打開，又同時看到系統位置、申請步驟、資料分頁、文件完成比例，全都長得有點像「你現在到哪裡」。

原始實驗沒有留下這張問題截圖，下面是依「加上進度功能」這句模糊 Prompt 還原的現場。

圖 12：五個問題各問各的，AI 卻很公平地全部回答 50%。

畫面排得非常整齊，答案也一致到有點可疑。我仍然不知道現在該回到上層、翻下一頁、繼續填表，還是只差兩份文件。

導覽回答了「要去哪裡」，卻沒有包辦頁面裡的「進行到哪裡」。明天，我們就來拆開 Breadcrumb、Pagination、Stepper、Progress Indicator、Table of Contents 與 Anchor Navigation，看看這六個元件為什麼不能混著用。

延伸閱讀

• W3C WAI：Landmark Regions
• W3C WAI：Navigation Landmark Example
• W3C WAI：Disclosure Navigation
• W3C WAI：ARIA26 - Using aria-current to indicate the current item
• Android Developers：Navigation bar

資料查閱：2026-08-07。