響應式UI設計怎麼做？Breakpoint設定與版面配置實務

什麼是響應式 UI 設計？它和 RWD 差在哪？

響應式 UI 設計是讓介面在不同螢幕寬度下維持可讀、可操作、可交付的設計方法。它承接 RWD 與 Responsive Design 的版面調整，但會進一步處理 UI 元件、互動狀態與手機優先的操作情境。

響應式 UI 設計的核心定義

響應式 UI 設計的核心，是依螢幕寬度、內容密度與使用情境，調整版面、元件排列、導覽方式、表單輸入與操作回饋。設計師不能只問「這頁手機版長什麼樣」，更要問「這個元件在手機、平板、桌機上是否還能完成同一個任務」。

以電商商品頁為例，桌機版可以讓圖片、商品資訊、規格與購買按鈕並排；手機版通常要重新排序，讓商品圖、價格、規格選擇與加入購物車依照決策順序出現。這是版面問題，也是 UI 決策問題。

RWD 偏版面，響應式 UI 還包含元件與互動

比較項目	RWD 常見焦點	響應式 UI 設計焦點
主要範圍	網頁版面隨螢幕寬度調整	版面、元件、互動、輸入狀態一起調整
常見問題	欄位幾欄、圖片怎麼縮放	導覽怎麼收合、表格怎麼讀、CTA 是否可點
交付重點	手機版、桌機版畫面	Breakpoint 規則、元件狀態、間距、最大寬度
驗收方式	畫面有沒有跑版	內容是否清楚，操作是否順，狀態是否完整

GUI 跟 UI 差在哪？簡短回答 PAA

GUI 是圖形使用者介面，重點在按鈕、視窗、圖示、選單這些可視化操作形式。UI 是使用者介面的總稱，範圍更廣，包含視覺、資訊架構、互動流程、輸入回饋與不同裝置上的狀態安排。

GUI 是圖形介面形式，UI 是整體使用介面設計範圍

在響應式 UI 設計裡，GUI 元素只是其中一部分。真正影響可用性的，常常是元素在不同寬度下的排列、顯示時機與操作回饋。Alice Wang 在審設計稿時，最常先看互動狀態是否被畫出來，因為少畫狀態比少畫一張頁面更容易造成實作落差。

Breakpoint 是什麼？為什麼不能只背 375、768、1440？

Breakpoint 是版面或元件需要切換狀態的寬度點。375、768、1440 可以當參考，但 Breakpoint 設定應該依內容斷點、元件可用性與實際版面失效點決定，不能只照裝置尺寸背誦。

Breakpoint 的真正用途：在版面失效前切換

Breakpoint 的用途，是在內容變得不好讀、欄位過擠、按鈕不好點、表格爆版之前切換版面。前端常用 Media Query 實作斷點，但設計判斷不該從 CSS 語法開始，而要先看畫面何時開始失效。

例如服務頁在 1024px 時三欄卡片還可讀，縮到 860px 後標題開始換行過多、按鈕被擠到不穩定的位置，這個 860px 附近就可能是內容斷點。實務上會再整理成設計系統可管理的斷點，例如 768px 或 900px，而不是留下太多零散尺寸。

裝置斷點 vs 內容斷點

類型	判斷依據	適合用途	風險
裝置斷點	手機、平板、筆電、桌機的常見寬度區間	建立初始設計稿與前端斷點命名	容易忽略內容本身何時壞掉
內容斷點	文字、圖片、欄位、元件開始不好讀或不好操作的位置	決定是否需要新增 breakpoint 或調整元件狀態	需要逐步測試，不能只靠模板

常見斷點可以參考，但不能照抄

375、768、1440 常被拿來當手機、平板、桌機的代表尺寸，原因是它們方便設計稿溝通，也接近許多團隊的測試習慣。但這些數字不是規格答案。若一個後台表格在 1024px 就已經難以閱讀，等到 768px 才切換會太晚；若一個簡單活動頁在 768px 仍然穩定，也不一定需要平板專屬設計稿。

手機、平板、桌機只是起點，不是設計答案

比較好的做法，是先用常見區間建立基本框架，再透過內容檢查決定是否補斷點。Breakpoint 設定要服務內容與任務，不是服務設計稿數量。

響應式 UI 的 Breakpoint 設定流程

響應式 UI 的 Breakpoint 設定可以用五步驟處理：先定義最小可用寬度，再排手機版內容優先順序，逐步放大找內容斷點，依元件狀態補斷點，最後把規則交付給工程師。

Step 1：先定義最小可用寬度

先決定產品願意支援的最小可用寬度。常見手機 viewport 會落在 320px 以上，因此許多網站會以 320px 作為極窄檢查點，以 360px 或 375px 作為主要手機設計稿。這些數字是實務檢查用的畫布，不代表所有使用者都拿同一種手機。

最小寬度要檢查字級是否可讀、按鈕是否可點、表單欄位是否可輸入、錯誤訊息是否有位置顯示。若 320px 下需要犧牲核心任務，就要調整內容優先順序，而不是把所有東西縮小。

Step 2：從手機版排出內容優先順序

手機優先不是把桌機版往下堆，而是先決定小螢幕上最重要的資訊與操作。報名頁通常先放活動名稱、日期地點、價格、報名 CTA；品牌故事、講者介紹、延伸文章可以往後放。這個順序會直接影響後續欄位與斷點判斷。

Step 3：逐步放大畫布，找出版面斷裂點

從手機寬度往上放大，觀察內容何時開始需要改變排列。單欄內容可能在 600px 左右開始顯得太長，卡片清單可能在 768px 附近適合變成兩欄，後台資料區可能在 1024px 才有足夠空間顯示側邊欄。斷點不是一次決定，而是在拉寬過程中被看見。

Step 4：依元件狀態決定是否新增 breakpoint

有些 breakpoint 不是整頁版面需要，而是元件需要。導覽列可能在 900px 以下收成選單，表格可能在 768px 以下改成卡片，篩選器可能在手機版改成抽屜或 Bottom Sheet。這類元件斷點如果沒有先定義，工程師很容易只能猜。

Step 5：把斷點寫成設計規則，而不是只交幾張圖

交付時要把 breakpoint 寫成規則，例如「小於 768px 時卡片由三欄改一欄」、「內容容器最大寬度 1200px」、「表格在手機版改卡片，每筆資料保留狀態、日期、金額與操作」。只交靜態圖，等於把最重要的判斷留到實作階段。

常見 Breakpoint 區間怎麼規劃？

常見 Breakpoint 應以區間規劃，不以單一裝置規劃。320px 到 767px 可視為手機區間，768px 到 1023px 為平板區間，1024px 到 1439px 為筆電與桌機區間，1440px 以上要控制最大寬度。

區間	常見設計重點	需要注意的 UI 問題
320px 到 767px	單欄、手機導覽、表單堆疊、主要 CTA 明確	文字過小、按鈕太近、鍵盤遮擋、內容順序錯亂
768px 到 1023px	兩欄機會、平板橫直向、導覽是否展開	卡片過寬、側欄尷尬、表格仍然不夠寬
1024px 到 1439px	桌機主要版面、欄位系統、側邊欄、資料密度	資訊太散、行長過長、元件缺少最大寬度
1440px 以上	限制內容寬度，避免畫面被無限拉開	文字行長過長、卡片距離過遠、視覺重心分散

手機區間：320px 到 767px

手機區間通常以單欄為主，重點是內容順序、觸控目標與輸入流程。若頁面有複雜篩選、表格或多步驟表單，手機版需要獨立思考操作路徑。我的判斷是，只要手機版需要完成交易、預約、登入或搜尋，就不能只靠縮放。

平板區間：768px 到 1023px

平板區間最容易被忽略，因為它介於手機與桌機之間。設計上可以開始使用兩欄，但不一定適合完整桌機導覽。服務頁、文章頁、課程頁通常在這個區間很好處理；後台、CRM、報表頁則要特別檢查表格與側欄是否互相擠壓。

筆電與桌機區間：1024px 到 1439px

這個區間多半是桌機版主要工作區。設計稿要開始處理欄位、最大寬度、側邊欄、資料密度與滑鼠操作狀態。若是 SaaS 或管理後台，1024px 常是關鍵檢查點，因為許多使用者會在筆電上工作，而不是只用大螢幕。

大螢幕區間：1440px 以上如何限制內容寬度

大螢幕不是把內容繼續拉寬。文章頁要控制行長，卡片列表要避免間距過大，表單不應變成橫跨整個畫面。常見做法是設定內容最大寬度，例如主要內容容器控制在設計系統規範內，背景或輔助區塊可延展，但核心閱讀區要穩定。

不是所有區間都需要獨立設計稿

如果版面在某個區間只是自然伸縮，不需要新狀態，就不必多畫一套完整設計稿。更有效的交付，是標明哪些寬度要切換、哪些元件維持流體版面、哪些容器有最大寬度。

元件級響應式設計：Breakpoint 不只影響整頁版面

Breakpoint 不只影響整頁欄位，也會影響每個 UI 元件的狀態。導覽列、卡片、表格、表單、CTA、Modal 都可能需要重排、收合、替換、固定或改成手機版專用互動。

UI 元件	桌機常見狀態	手機常見狀態	Breakpoint 判斷點
導覽列	Header Menu 展開	Hamburger 或 Bottom Nav	選單項目開始擠壓或換行
卡片	多欄並排	單欄堆疊	圖片、標題、按鈕比例失衡
表格	多欄比較	卡片、精簡欄位或橫向捲動	欄位低於可讀寬度
表單	雙欄或群組排列	單欄輸入	欄位標籤與錯誤訊息無法穩定顯示
CTA	放在區塊右側或頁尾	可能固定在底部	使用者需要頻繁操作或轉換流程長
Modal	置中彈窗	Bottom Sheet 或全頁	內容高度超出手機可視範圍

導覽列：何時從 Header Menu 變成 Hamburger 或 Bottom Nav

導覽列不該等到爆版才收合。當選單文字開始擠壓、換行，或右側登入與主要按鈕沒有穩定空間時，就該切換。內容網站常用 Hamburger；高頻操作產品可以考慮 Bottom Nav，但項目要少，通常只放最常用的三到五個目的地。

卡片：橫排、直排與資訊層級調整

卡片在桌機版可以圖片左、文字右，也可以三欄並排。到了手機版，圖片、標題、摘要、標籤與按鈕的順序要重新確認。若卡片是課程、商品或服務方案，價格、狀態與主要操作應優先露出，摘要可以縮短。

表格：手機版要改卡片、橫向捲動還是精簡欄位

表格沒有單一答案。若使用者需要比較多筆資料，例如訂單列表，橫向捲動可以保留，但要清楚提示。若每筆資料可獨立閱讀，例如會員紀錄，可以改卡片。若手機只需要快速判斷狀態，就精簡欄位，保留日期、狀態、金額與主要操作。

表單：欄位堆疊、輸入順序與錯誤訊息位置

桌機表單可以雙欄，手機版通常應改單欄。欄位順序要符合填寫流程，錯誤訊息要貼近欄位，不要集中在最上方讓使用者來回找。地址、付款、報名資料這類長表單，要檢查鍵盤開啟後還能不能看見目前欄位與下一步。

CTA：手機版是否需要 Sticky Button

手機版是否需要 Sticky Button，要看任務是否需要持續可操作。商品頁、報名頁、預約頁通常適合固定主要 CTA；文章頁、一般介紹頁不一定需要。固定按鈕會佔用可視空間，因此要確認不遮住內容，也不與 Cookie 提示或聊天工具重疊。

Modal：手機上是否應改成 Bottom Sheet

桌機置中 Modal 到手機上常會變得難讀，尤其內容包含表單、選項或說明文字時。手機版可以改成 Bottom Sheet 或全頁流程，讓內容有足夠高度與捲動空間。若 Modal 內有確認與取消按鈕，兩者位置要固定且不被鍵盤遮住。

互動與輸入情境：手機版不是把桌機版縮小

手機版 UI 要重新處理 Hover、觸控目標、鍵盤遮擋與單手操作。桌機版能靠滑鼠、寬螢幕與 hover 呈現的資訊，在手機上常需要改成直接顯示、點擊展開或重新排序。

不要把重要資訊藏在 Hover 裡

手機沒有穩定的 hover 狀態。若價格說明、錯誤提示、功能解釋或關鍵操作只在 hover 時出現，手機使用者可能完全看不到。較好的做法是把重要資訊直接顯示，或改成點擊展開、提示標籤、說明連結。

按鈕與連結要有足夠點擊範圍

觸控目標太小會讓手機版看起來精緻，實際上很難操作。許多設計系統會以約 44px 作為觸控目標起點，實務上還要看按鈕間距、文字長度與手指誤觸機率。尤其是頁籤、表格操作、日期選擇與篩選器，不能只看視覺對齊。

鍵盤開啟後，表單與 CTA 不能被遮住

手機輸入時，可視高度會被鍵盤佔掉一大段。登入、搜尋、結帳、預約與報名流程都要測鍵盤開啟狀態。錯誤訊息要靠近欄位，下一步按鈕要能被找到，固定底部 CTA 要避免和鍵盤或系統操作區打架。

手機版內容可以重排、精簡，不一定完整搬運桌機版

手機版可以精簡輔助內容，但不能拿掉完成任務需要的資訊。電商頁可以把品牌故事放後面，但不能藏價格、規格、庫存與付款資訊。SaaS 方案頁可以縮短功能描述，但方案差異與限制條件要保留。

單手操作時，主要操作應放在容易觸及的位置

很多手機操作發生在通勤、排隊、走動或單手使用的情境。主要 CTA、返回、篩選、送出這類操作，應避免放在使用者很難觸及的位置。這不是追求新奇互動，而是把常用任務放在合理範圍內。

Figma 設計稿要交幾個尺寸？Breakpoint 如何交付給工程師？

Figma 響應式 UI 設計至少要交手機版與桌機版，複雜頁面再補平板或中間狀態。交付重點不是畫幾張圖，而是提供 Breakpoint 規則、Auto Layout 邏輯、元件變體與切換條件。

至少交手機版與桌機版，複雜頁面補平板或中間狀態

一般內容頁至少需要手機版與桌機版。若頁面有複雜表格、篩選器、雙欄表單、側邊欄或資料儀表板，就應補平板或中間斷點。產品負責人評估工作量時，可以先看哪些頁面在手機上會直接影響任務完成，例如購買、預約、查詢與填寫資料。

用 Auto Layout 表達可伸縮規則

Figma 的 Auto Layout 可以表達間距、堆疊、填滿、固定寬度與內容自適應。設計稿若只靠手動擺放，工程師很難判斷哪些區塊應該伸縮，哪些區塊應該固定。Auto Layout 設得好，handoff 時會少掉很多猜測。

用 Component Variant 管理不同裝置狀態

Component Variant 適合管理導覽列展開與收合、卡片橫向與直向、表格桌機與手機、Modal 與 Bottom Sheet 等狀態。若 Design System 已經有 token，斷點、間距、字級與元件狀態應盡量對應到同一套命名，避免每頁各自定義。

交付時要標明最大寬度、欄數、間距與切換條件

交付項目	應標明內容	工程師需要知道的原因
Breakpoint	切換寬度與切換後狀態	決定 Media Query 或 Container Query 實作規則
最大寬度	內容容器、表單、卡片列表的最大寬度	避免大螢幕版面被過度拉開
欄位與間距	欄數、gutter、區塊上下間距	確保不同頁面視覺節奏一致
元件狀態	展開、收合、固定、替換、隱藏條件	避免手機版缺少可用狀態
文字規則	字級、行高、是否使用 Fluid Typography 或 clamp()	維持跨寬度可讀性

不要只交靜態畫面，工程師需要規則

靜態畫面只能說明某個寬度下長什麼樣，規則才會說明寬度變化時怎麼動。Alice Wang 通常會要求設計稿旁邊留下註記，寫清楚「何時變一欄」、「何時收合」、「最大寬度多少」、「手機版隱藏的是輔助資訊還是核心資訊」。這些註記比多畫一張沒有說明的畫面更有用。

如何檢查響應式 UI 設計是否真的好用？

檢查響應式 UI 設計，要從內容、視覺、操作與跨裝置四個面向驗收。只看有沒有 RWD 不夠，還要確認資訊沒有裁切、按鈕可操作、表單可輸入，手機、平板、筆電、桌機都能完成任務。

內容檢查：資訊是否被裁切、隱藏或順序錯亂

先檢查標題、價格、規格、日期、狀態、錯誤訊息與主要操作是否完整。手機版可以調整順序，但不能讓使用者需要的判斷資訊消失。若內容被折疊，要確認折疊後仍有清楚提示。

視覺檢查：字級、間距、圖片清晰度與像素對齊

字級太小、行距太擠、圖片模糊、圖示沒對齊，都會讓手機版看起來像勉強縮出來。Fluid Typography、clamp()、SVG 圖示與穩定間距可以改善跨寬度品質，但仍要實際看畫面。非整數 px 有時會造成細線或圖示發虛，特別是表格線、icon 與分隔線。

操作檢查：按鈕、表單、導覽與錯誤回饋

每個主要任務都要實際操作一次。加入購物車、送出表單、登入、搜尋、篩選、切換頁籤、關閉 Modal，這些狀態都比首頁第一屏更容易暴露問題。設計審查時只看截圖，通常抓不到鍵盤遮擋與錯誤訊息位置。

跨裝置檢查：手機、平板、筆電、桌機至少各看一次

檢查面向	要看的問題	常見修正
內容	是否裁切、隱藏、順序錯亂	重排資訊層級，補上展開提示
視覺	字級、間距、圖片、圖示是否穩定	調整字級階層、最大寬度與圖示尺寸
操作	按鈕、表單、導覽、錯誤回饋是否可用	放大觸控目標，調整 CTA 與錯誤訊息位置
跨裝置	手機、平板、筆電、桌機是否都能完成任務	補 breakpoint 或調整元件狀態

任何橫向捲動都要確認是不是刻意設計

橫向捲動不一定錯，表格或時間軸有時需要保留。但如果整頁出現橫向捲動，多半是容器、圖片、固定寬度元件或表格造成爆版。驗收時要分清楚，是特定元件刻意可橫滑，還是整頁意外跑版。

常見錯誤：看起來有 RWD，但其實 UI 不好用

常見的手機版 UI 問題，是只做版面縮放，沒有重新處理文字、卡片順序、表格、圖片、CTA 與互動狀態。看起來有 RWD，不代表使用者真的能閱讀、操作與完成任務。

只縮小桌機版，導致手機文字太小

桌機版的資訊密度搬到手機上，常會造成字級太小、行距太擠、按鈕貼太近。修正方式是重新定義手機版文字階層，刪減輔助描述，保留決策必要資訊，並讓操作元素有足夠空間。

卡片重排後資訊順序變亂

卡片從橫排變直排時，常見問題是圖片、標題、標籤、價格與按鈕順序失去邏輯。商品卡、課程卡、文章卡要各自檢查，因為使用者判斷一張卡片的方式不同。文章卡重視標題與主題，商品卡通常更重視價格、規格與狀態。

表格在手機爆版

表格爆版通常來自固定欄寬、欄位太多或文字不換行。可以依需求改成卡片、保留橫向捲動、固定第一欄，或在手機版只保留關鍵欄位。若是後台工作介面，不能只為了畫面乾淨就拿掉使用者判斷資料所需的欄位。

圖片變模糊、圖示沒對齊、非整數 px 造成視覺不穩

響應式設計不只看欄位切換，也要看視覺品質。圖片在高解析螢幕上模糊、圖示與文字 baseline 不齊、細線在某些寬度發虛，都會讓介面顯得不穩。這些細節在設計稿很容易被忽略，但實作後會直接影響信任感。

主要 CTA 在手機版消失或被鍵盤遮住

手機版最嚴重的問題之一，是使用者看完內容卻找不到下一步。報名、購買、預約、送出表單這類 CTA，要確認在捲動、鍵盤開啟、錯誤訊息出現時都能被找到。必要時可以使用 Sticky Button，但要避免遮住內容。

錯誤	影響	修正方式
只縮小桌機版	文字難讀，操作困難	重排內容，建立手機版字級與間距
卡片順序錯亂	使用者抓不到判斷重點	依任務重新安排圖片、標題、狀態與 CTA
表格爆版	資料無法閱讀或比較	改卡片、精簡欄位或設計明確橫向捲動
視覺細節不穩	畫面顯得粗糙，降低信任	檢查圖片解析度、SVG 對齊與像素邊界
CTA 消失	任務中斷，轉換流程失效	固定主要操作或調整 CTA 出現位置

響應式 UI 設計的 Breakpoint 決策總結

Breakpoint 設定的最佳做法，是從內容何時不好讀、元件何時不好操作、任務何時無法完成來反推。先看內容斷點，再看元件狀態，最後用真機與任務測試確認響應式 UI 設計是否可靠。

先看內容何時壞掉

內容斷點是最重要的起點。當文字行長過長、卡片資訊太擠、圖片比例失衡、表格欄位無法閱讀時，就要考慮切換版面。裝置區間只能協助命名與溝通，不能取代內容判斷。

再看元件何時需要換狀態

導覽列、表格、表單、CTA、Modal、篩選器都可能有自己的切換點。若團隊有 Design System，應把這些規則整理成元件層級規範，搭配 token、CSS Grid、Flexbox、Container Query 或 Media Query 實作。

最後用真機與任務測試確認是否好用

響應式 UI 設計的驗收標準，是使用者能不能在不同裝置完成任務。手機上能不能輸入，平板上側欄會不會擠壓，筆電上資料表是否可讀，大螢幕上行長是否過長，這些都要看實際狀態。只看設計稿，很容易高估介面的穩定度。

響應式 UI 設計和 RWD 一樣嗎？

不完全一樣。RWD 多半指網頁版面會依螢幕寬度調整；響應式 UI 設計則更重視元件、互動、表單、導覽與操作狀態在不同裝置上的變化。

Breakpoint 一定要用 375、768、1440 嗎？

不用。這些尺寸可以當參考，但真正的 breakpoint 應該依內容斷裂點、欄位密度、元件可用性與實際使用裝置決定。若內容在 900px 就已經不好讀，就不必等到 768px 才調整。

手機優先設計是什麼？

手機優先是先從最小螢幕安排內容與操作，再逐步放大版面。這能避免桌機資訊太多，到了手機版只能硬塞或縮小，也能更早看出哪些資訊才是任務核心。

Figma 響應式 UI 設計要畫幾個尺寸？

基本至少要有手機版與桌機版。若頁面資訊密集、平板流量高，或中間寬度會出現明顯版面問題，就應補平板或中間斷點。交付時也要標明 Auto Layout、最大寬度、欄數、間距與元件切換條件。

表格在手機版應該怎麼處理？

可以改成卡片式資訊、保留橫向捲動，或精簡欄位。選擇方式要看使用者是否需要比較多筆資料，以及哪些欄位是決策必要資訊。訂單列表與報表頁通常要比一般內容頁更保守，不能為了簡化而拿掉關鍵欄位。

手機版可以隱藏桌機版內容嗎？

可以，但不能隱藏使用者完成任務需要的核心資訊。手機版常需要重新排序、精簡輔助內容，保留最重要的資訊與操作。若內容被收合，應提供清楚的展開方式。

手機沒有 hover，原本 hover 才出現的資訊怎麼辦？

重要資訊不能只放在 hover 狀態。可以改成直接顯示、點擊展開、使用標籤提示，或在手機版改成不同的資訊呈現方式。價格說明、錯誤提示與主要操作尤其不能依賴 hover。

鍵盤遮住表單或按鈕怎麼解？

表單欄位要保留足夠捲動空間，錯誤訊息要靠近欄位，主要 CTA 不應被鍵盤遮住。登入、搜尋、結帳、預約與報名流程尤其要測，因為這些流程一旦被遮住，使用者很容易直接中斷任務。

GUI 跟 UI 差在哪？

GUI 是圖形使用者介面，指透過圖像、按鈕、視窗等元素操作系統或產品；UI 是使用者介面的總稱，範圍比 GUI 更廣，包含視覺、互動、資訊呈現、輸入流程與不同裝置狀態。

如何判斷響應式 UI 是否做得好？

看三件事：內容是否清楚、操作是否順、視覺是否一致。實務上要檢查字級、間距、橫向捲動、點擊目標、表單輸入與跨裝置狀態，也要用手機、平板、筆電、桌機各跑一次主要任務。