安安～我是ChiYu～
昨天，我才用 Escape 取消了「停用林子安」這個危險動作。帳號保住了，管理員也沒有因此下班，反而接著問我：
那我可以先看一下林子安的部門、角色和目前專案嗎？
很合理。停用帳號以前先把資料看完，總比按下去之後才開始考古好。
於是我把需求改成：
點成員資料表的一列，顯示完整資料。
昨天結尾就停在下面這張圖。這是我依照第一版需求，在網站上重建的錯誤現場；它不含真實帳號與個人資料：
圖 1：和昨天結尾是同一張畫面。林子安的資料出現了，原本拿來比較的成員清單卻被遮罩鎖住。
AI 很快就交出一張置中的白色卡片，背景順便變暗。林子安的資料確實出現了，但其他成員的部門與角色也被蓋得乾乾淨淨。
想比較下一位成員？先關掉 Modal、記住剛才看到的內容，再打開另一位。畫面沒有壞，使用者的記憶力倒是被當成系統資源用得很勤勞。
這就是今天的問題：詳細資料出現時，原本的工作脈絡還要不要留在畫面上？
我們會用 LumenDesk 的虛構成員管理情境，拆開 Sheet、Drawer 與 Bottom Sheet。所有人名與資料都只是示範，不會連到真實帳號。
我也把這組選型放進 Vibe UI Atlas 的 Dialog、Drawer 與 Bottom Sheet 比較頁。文章負責講判斷過程，網站則可以直接操作 Demo、對照差異與複製 AI Prompt。
在看個別元件以前，先看今天真正的岔路在哪裡：
圖 2：選擇浮動面板時，先看原頁是否仍有用，再看任務長度和裝置空間。
這張圖最值得記住的不是三個元件名稱，而是第一個問題：「背景裡的資料還有沒有用？」只要答案是有，就不該反射性地用一張置中卡片把它全部遮住。
這裡還有一條很容易被名稱蓋掉的界線：Drawer、Sheet 與 Bottom Sheet 是設計系統常用的視覺與版型名稱，不是各自對應一個固定的 ARIA 角色。背景要不要鎖住、焦點要不要限制在面板內，仍要由任務決定。面板從右邊滑出來，不會自動獲得「可以操作背景」的能力。
我先在桌面版 Demo 點了「查看林子安的資料」。右側面板打開後，林子安的部門、角色與加入日期出現在眼前，背景的三筆成員資料仍然看得見。
注意，是「看得見」，不是「還能點」。目前網站 Demo 的 Drawer 裡可以變更角色，因此採用模態行為：背景清單保留作為視覺脈絡，但操作暫停，焦點也留在面板裡。若產品要讓管理員直接點下一列、逐人比對，那就要改成 Non-modal Drawer，並另外設計焦點如何在清單與面板之間移動。
更重要的是，面板標題直接寫「林子安」，不是一個放到誰身上都成立的「詳細資料」。使用者不需要猜自己剛才到底點了哪一列。
看完後，我故意什麼都不改，直接按 Escape。
結果是：
這串結果看起來很普通，卻是 Drawer 真正有價值的地方。使用者只是暫時靠近一筆資料，看完還能回到原本的位置；至於能不能在面板開啟時直接比較其他成員，則要看它被定義成 Modal 還是 Non-modal，不能只看面板從哪裡滑出來。
如果 Prompt 只寫「從右邊滑出一個漂亮面板」，AI 大概會把動畫做得很順。至於關閉後回哪裡、資料有沒有偷偷改掉、清單還剩多少可以看，那就只能靠緣分了。
Sheet、Drawer、Bottom Sheet 這三個名稱，最容易卡住人的其實是 Sheet。
在不同設計系統與元件套件裡，Sheet 的定義不一定完全相同。這篇把它當成一個比較泛用的家族稱呼：有一塊浮動面板，用來承載內容或操作。
問題是，「有一塊面板」只說了一半。至少還缺兩件事：
同樣是白底、圓角和陰影，可能是要求使用者先處理完的 Dialog，也可能是保留資料表脈絡的 Drawer，還可能是手機底部的 Bottom Sheet。外觀很像，工作方式卻完全不同。
我在 Sheet 元件頁 放了一個刻意寫完整的版本：面板置中出現、背景暫停、Escape 可以關閉。以互動語意來看，它就是一個 Modal Dialog，只是使用 Sheet 的視覺樣式。Sheet 不能代替我們回答模態與否。
圖 3：Sheet 描述的是浮動面板樣式；這個 Demo 另外指定置中、模態與 Escape 關閉，所以互動上屬於 Modal Dialog。
所以當我跟 AI 說「做一個 Sheet」時，我不會把這句當成需求已經寫完。它比較像是在說「我要一台車」：四輪、兩輪、載人還是載貨，最好還是補一下。
Drawer 通常從畫面側邊滑出。這個方向很常見，但從右邊滑出來只是外觀，保留原頁脈絡才是用途。原頁可以只是留在眼前，也可以繼續操作；兩者差很多，Prompt 必須選一個。
在 LumenDesk 裡，管理員本來就在成員清單比對部門、角色與狀態。點擊林子安後，如果右側打開 Drawer，原本的列、排序與篩選結果還留在旁邊，使用者就知道自己從哪裡來，也能接著查看下一位。
網站上的 Drawer Demo 就是這個情境：
圖 4：右側 Drawer 顯示林子安的資料與角色操作；這個 Demo 保留背景清單的視覺脈絡，但在編輯期間暫停背景操作。
我會在 Drawer 裡放這些內容：
但我不會把一張十幾欄的完整表單、分三步才能完成的邀請流程，或需要大量閱讀的設定頁塞進去。那些工作縮到側邊不會變簡單，只會讓捲動、比對與錯誤修正一起變辛苦。
你可以直接操作 Drawer Demo：選擇角色後按儲存，只會更新示範訊息；按 Escape 或取消則會關閉面板，並把焦點還給原本的開啟按鈕。
因此我會這樣記：Drawer 的價值不是「不用跳頁」，而是「原頁仍值得留在眼前」。 若原頁還必須能操作，再明確加上 Non-modal 規格；若面板正在編輯資料，採 Modal 也合理，但不能假裝背景還能點。
把同一個情境搬到 360px 手機上，桌面 Drawer 很快就出事了。
左邊想留一點清單，右邊又要塞完整資料，最後兩邊都只剩一條縫。這時候若只是把 Drawer 改成「由下往上滑」，名字換成 Bottom Sheet，工作也只完成一半。
手機上的 Bottom Sheet 還要重新決定：
今天的 Demo 只保留林子安的摘要，以及「查看完整資料」和「變更角色」兩個下一步。需要編輯更多欄位時，就進完整頁面，不讓 Bottom Sheet 一路長到使用者開始懷疑自己是不是打開了另一個網站。
Android 的官方文件也把 Bottom Sheet 描述為錨定在畫面底部、用來呈現次要內容的表面。這很適合「先看摘要，再決定下一步」，不是把桌面設定頁整包塞進手機。Android Developers：Create a bottom sheet
我把這個情境放到 360px 的網站 Demo 裡實際檢查：
圖 5：手機版 Bottom Sheet 保留可見把手、關閉按鈕、成員摘要與兩個下一步，沒有把完整表單硬塞進去。
拖曳把手只是「這張面板可能可以移動」的提示，不是所有人都能理解或操作的關閉控制。在 Bottom Sheet Demo 裡，使用者還能按可見的關閉按鈕或 Escape；面板不會造成整頁水平捲動，關閉後焦點也會回到「快速查看林子安」。這些都比「滑上來的動畫有沒有很絲滑」更值得驗收。
到這裡，可以把幾個出口擺回同一張工作桌上：
| 使用者正在做的事 | 最需要留下什麼 | 建議出口 | 不要硬塞成 |
|---|---|---|---|
| 在桌面資料表查看或比對成員 | 原本的列、排序與篩選脈絡 | Drawer；再決定 Modal 或 Non-modal | 把清單完全遮住的置中面板 |
| 只看一段摘要，再決定下一步 | 目前頁面與一兩個主要動作 | Sheet，但要補方向與背景規則 | 只有「做一個 Sheet」的模糊需求 |
| 在手機快速查看或處理少量動作 | 拇指可及性與底部安全空間 | Bottom Sheet | 被硬壓窄的桌面 Drawer |
| 編輯多欄資料、跨步驟審核或長篇閱讀 | 完整工作空間與可分享網址 | 完整頁面 | 不斷加高、加寬的浮動面板 |
還有一個不能混進來的情境：如果管理員不是「查看林子安」，而是要「停用林子安的帳號」，使用者就必須先理解後果並做出決定。這時候仍應使用昨天的 Confirmation Dialog，不是在 Drawer 角落塞一顆紅色按鈕，希望大家都不要手滑。
W3C 對 Modal Dialog 的要求很明確：開啟後背景內容不可操作、焦點留在對話框內、Escape 提供可預期的關閉方式，關閉後焦點通常回到原本的觸發元素。W3C WAI-ARIA APG：Modal Dialog Pattern
如果還是拿不定主意，可以照這張圖走一次：
圖 6：先判斷使用者是否必須停下來回應，再看原頁脈絡是否有用，最後才處理裝置寬度。
我的判斷順序不會從「哪個元件比較新潮」開始，而是先問：這是中斷、查看，還是完整工作？元件名稱只是最後替這個判斷貼上的標籤。
原本那句「點一列，顯示完整資料」把裝置、內容範圍與返回路徑全部留給 AI 猜。改寫後，我會這樣交代：
在 LumenDesk 的成員管理頁製作「查看成員詳細資料」流程。
桌面版：使用者點選成員列表中的「林子安」後，從右側開啟 Drawer。保留背景資料表的視覺脈絡；Drawer 顯示姓名、部門、角色與加入日期，只允許變更一個角色欄位。因為這次包含編輯，採 Modal 行為：背景暫停操作，焦點留在面板內。提供關閉、取消與儲存；Escape 或取消不變更資料，關閉後焦點回到開啟 Drawer 的按鈕。若需求改為直接逐列比對，才改用 Non-modal Drawer，並補上清單與面板之間的鍵盤移動方式。
手機版：改用 Modal Bottom Sheet，從底部顯示林子安摘要與「查看完整資料」「變更角色」兩個動作。除了可見拖曳把手，還要提供明確的「關閉」按鈕、Escape／系統返回路徑與足夠底部安全留白；背景暫停操作，並在 360px 寬度下不能出現水平捲動。關閉後焦點回到開啟入口。
若需要編輯多個欄位、跨多步驟或長篇說明，改到完整頁面；不要塞進 Drawer 或 Bottom Sheet。停用帳號等高風險動作另用 Confirmation Dialog。
這段 Prompt 沒有要求「像現代 SaaS」，但它把真正會影響操作的條件說清楚了：桌面保留什麼、手機留下什麼、關閉後回哪裡，以及內容長大後該從哪個出口離開。
Vibe Coding 要的不是把所有 UI 名詞都塞進 Prompt。先做出選型判斷，再把不能被 AI 自由發揮的界線寫進去，通常更有用。
我會沿著這條路徑驗收：
只要其中一題開始答得很勉強，通常不是再多加一點寬度就能解決，而是這份內容已經該搬到完整頁面了。
最後，我在桌面選擇 Drawer，在手機改用 Bottom Sheet。兩邊都只保留摘要與少量下一步；按 Escape 關閉時，資料不會改變，焦點也回到原本的觸發點。
和昨天的 Confirmation Dialog 相比，今天沒有逼管理員先回答一個危險問題，而是讓他靠近資料、看完，再回到原本的清單繼續工作。開頭那句「顯示完整資料」，也終於從一張遮住所有東西的白色卡片，變成可以依裝置與任務驗收的介面。
不過 Drawer 裡又冒出三個需求：角色欄位旁的問號要解釋權限規則、管理員要能變更角色，滑過主管姓名時還想先看一份人物摘要。最初的 Prompt 把它們揉成一句：
「在問號圖示上滑過去，顯示詳細說明和操作。」
下面這張圖，是我依照第一版需求在網站上重建的錯誤現場，不含真實帳號與個人資料：
圖 7：短提示被做成迷你設定頁。滑鼠一移開，權限說明、角色選擇、儲存按鈕和主管資料就一起消失。
這張 Tooltip 看起來很會做事，實際上同時扛了說明、操作與人物預覽。鍵盤怎麼打開、觸控裝置要按哪裡，以及滑鼠移進按鈕後浮層會不會收起來，需求全都沒有交代。
明天，我們就從 Drawer 裡繼續拆 Tooltip、Popover 與 Hover Card。滑過去會出現，只能證明它會出現；至於裡面該放說明、操作還是人物摘要，那又是另一場選型現場。
<dialog>（查閱日期：2026-08-07）
iThome鐵人賽
看影片追技術