網路架站

設計與前端的分界不是像不像技術,是能不能被瀏覽器驗證

多數人以為設計與前端的界線,靠「設計做視覺,前端把它變成網頁」這句話就能撐住,吵不清楚的地方最後靠時間磨合,總有人讓步。過去這確實成立,因為從一張設計稿變成一個能上線的網頁,中間隔著轉譯這道工序,需要時間,也需要來回溝通,誰該對哪個細節負責,可以邊做邊談出共識。

但當 AI 工具能直接讀懂設計檔案裡的圖層、樣式與變數,幾分鐘內生成一版堪用的畫面之後,這道緩衝正在消失。轉譯不再需要那麼多時間,原本靠時間成本蓋過去的模糊地帶,就這樣被攤在檯面上,決定權在誰手上、誰該為哪個細節負責,變成一個得先講清楚、不是邊做邊磨合的問題。

AI 生成畫面的速度讓分工線比以往更容易畫在錯的地方

設計稿變成網頁,從來不是一個機械式的複製動作。前端拿到的是靜態畫面,得重新決定間距怎麼換算成程式碼看得懂的單位、顏色怎麼對應到色票,遇到畫面沒交代清楚的地方,例如某個按鈕在窄螢幕下該怎麼縮,還得自己補一個合理的判斷。這道轉譯工序原本就有損耗,需要靠雙方來回討論才能補齊,這個討論的過程,其實就是分工模糊地帶被磨合掉的地方。

Figma 在 2025 年 6 月推出的 Dev Mode MCP server(測試版),把這個磨合的時間大幅壓縮。這支伺服器讓 GitHub Copilot、Cursor、Windsurf、Claude Code 這類 AI 程式碼代理人,透過 Model Context Protocol 直接讀取設計檔案內部的結構化資料,包括圖層階層、樣式、變數(也就是 design token)、元件屬性與素材參照,不必再靠螢幕截圖,也不必靠工程師憑經驗猜測設計稿沒畫出來的部分。

轉譯的時間一旦被壓到接近即時,原本靠磨合掩蓋的責任不清就直接浮上檯面。以前一個沒講清楚的細節,可以在來回溝通裡順便講開;現在畫面幾分鐘就跑出來了,沒人先講清楚的地方,AI 只會照著它讀到的資訊做出一個版本,而那個版本背後藏著它自己猜的假設,跟誰都沒對過。

分界的判準是決定的效果而非職稱

要回答這件事該誰決定,直覺的做法是問這聽起來比較像設計還是比較像技術,但這個問法本身就會出錯,因為很多決定聽起來像技術,例如某個數值該設多少,實際上牽動的是視覺意圖;也有些決定聽起來像美感,例如某個畫面該長怎樣,實際上牽動的是不同瀏覽器、不同裝置會不會正常運作。

比較站得住腳的判準,是看這個決定會不會被瀏覽器環境驗證。會影響使用者在瀏覽器裡實際看到、實際操作到的結果,而且答案得靠不同裝置、不同瀏覽器、真實的使用者操作去驗證,這種決定該交給前端;決定的是畫面想傳達什麼、資訊的輕重與順序、品牌調性該長怎樣,這種不管背後用哪一種技術實現、答案都不會變的意圖判斷,該交給設計。

設計與前端誰拍板,看這個決定會不會被瀏覽器環境驗證:會被驗證的交給前端,不受技術實現影響的意圖交給設計。
判準不是聽起來像哪一邊,而是換裝置、換瀏覽器後答案會不會變;會被驗證的交給前端,不變的意圖交給設計。

設計扛的是視覺意圖與資訊層級的判斷

設計要決定的是這個畫面想讓使用者先看到什麼、品牌的調性該長什麼樣子、一個資訊在整個版面裡的輕重排序。這些判斷即使換了技術實現方式,答案也不該變,同一個品牌換了一組前端團隊接手,或是從一套框架換成另一套框架,使用者該先注意到哪個按鈕、標題該用什麼語氣,都不會因為底層技術換了就跟著換。

正因為答案不受技術影響,這類判斷才適合交給設計拍板。前端可以對某個排版有意見,但那通常是「這樣做技術上比較好處理」的意見,不是「這個資訊本來就該擺在後面」的判斷;後者的答案,得回到設計當初為什麼這樣安排去找。

前端扛的是這些意圖在瀏覽器裡忠實運作的結果

前端要負責的是讓設計決定的意圖,在真實的瀏覽器環境裡真的發生。同一個畫面,在不同的裝置尺寸、不同的瀏覽器版本、使用者不同的操作動作,像是點擊、輸入、網路延遲,底下都得撐得住原本要傳達的效果,這件事離不開瀏覽器本身。

設計工具裡的原型頂多能模擬幾種固定情境,沒辦法窮舉所有裝置與瀏覽器的組合,也沒辦法模擬使用者網路不穩、輸入了奇怪字元這類真實狀況。這正是為什麼會不會被瀏覽器環境驗證是判準,而不是畫出來的稿子看起來怎麼樣,稿子看起來對,不代表它在各種真實環境裡都跑得對。

美術決定的外衣包著行為決定的內裡

前面的判準聽起來清楚,套進實務細節卻常常難以一刀劃開,因為很多地方表面上看起來只是這畫面好不好看的美術判斷,實際上同時牽動著在不同裝置、不同狀態下會怎麼運作的行為判斷,兩種性質糾纏在同一個畫面元素裡,才會吵不完。

斷點、互動狀態、design token、alt 文字四個灰色地帶,每一個都是意圖與內容歸設計、技術實作歸前端。
最容易吵不清楚的四個地帶:斷點、互動狀態、design token、alt 文字,拆開來看誰拍板意圖、誰拍板技術實作。

斷點技術判斷歸前端、排序優先順序歸設計

斷點該設在哪個像素寬度、要設幾個、導覽列什麼時候該收進漢堡選單,這些屬於瀏覽器裡怎麼運作的技術判斷,該由前端定案。Nielsen Norman Group 的 Kelley Gordon 在 2024 年的文章裡,把常見的斷點分成四個區間,用 T 恤尺寸命名:extra-small 大約在 500 像素以下,對應手機,常見 4 欄網格;small 落在 500 到 1200 像素,對應平板,8 欄網格;medium 在 1200 到 1400 像素,對應筆電,12 欄網格;large 則是 1400 像素以上,對應外接螢幕,延續 12 欄網格。

但同一份文章也指出,受限於設計資源,實務上多數設計師只處理 2 到 3 個斷點,沒辦法每個尺寸都做。問題就出在這裡:同一個裝置尺寸下,哪塊內容先被看到、哪個行動按鈕不能被擠到畫面外,是資訊層級的判斷,前端不該自己決定,該由設計先給答案。混淆最容易發生在設計只交出桌機稿和手機稿兩張,中間的尺寸完全沒講,前端只能自己猜哪些內容重要。

該篇文章也直接點名這件事該怎麼分工,建議讓開發團隊參與斷點的制定,因為實際把斷點寫進網站的人是他們。這句話反過來也成立,斷點的像素值前端可以拍板,但同一個尺寸下那些資訊的優先順序,前端不該替設計決定。

沒有定義的互動狀態,責任不會自動轉嫁給前端

hover、focus、載入中、錯誤、空狀態,這類會因為使用者的動作或系統狀態而改變的畫面,很多設計稿只畫了正常狀態這一張,沒畫到的部分容易被當成前端自己看情況處理就好。

但這些狀態一樣牽動視覺意圖,錯誤訊息該用什麼語氣、空狀態要不要放一張插圖鼓勵使用者繼續動作,這些都是設計判斷,不是前端能力範圍內該補的空缺。設計沒有先定義,前端做出來的版本就是一個沒有視覺判斷介入的版本,那不是前端能力不足,是設計的工作沒做完整。這類狀態該先納入設計稿的清單裡,而不是留給前端在寫程式的當下順手決定。

Design token 的語意由設計拍板,寫成程式變數是前端的事

顏色、間距、字級這類數值,看起來像純美術的選擇,一旦被整理成 design token,例如把某個藍色命名為代表主要行動色的變數,它就同時變成程式裡會被反覆引用的東西。這個顏色代表什麼情境、什麼場合該用哪個間距,這種語意判斷該由設計來定義。

但把這個語意寫成前端框架吃得進去的變數格式、維護它的版本、確保命名在跨專案之間不會互相衝突,這是工程責任,該由前端扛。常見的失守是兩邊都以為對方在維護這套系統,結果同一個藍色,在設計稿裡叫一個名字,在程式碼裡卻叫另一個名字,兩邊各自為政,誰也沒發現對方早就換了說法。

alt 文字內容是設計判斷,語意標籤正確與否是前端職責

一張圖片該寫什麼替代文字,取決於這張圖片在這個畫面裡想傳達什麼,這是關於意圖的判斷,該由清楚這張圖片為何存在的人來決定內容,通常是設計或內容撰寫者。W3C 網頁無障礙推動組織(WAI)發布的 alt 決策樹,把圖片依用途分成幾類分別判斷:純裝飾用的圖片該給空的 alt 屬性;具有特定功能的圖片,例如一個只用圖示表示的按鈕,alt 該寫的是這個按鈕的功能,而不是描述圖示長什麼樣子;圖片裡本身就有文字、而這段文字沒有在頁面別處出現,alt 就該把圖片裡的文字內容寫進去。

但 alt 屬性有沒有被正確寫進 HTML、圖示按鈕是不是真的用語意化的標籤包起來,而不是一個純裝飾用的容器,這是前端的技術職責。寫對了,設計決定的那段文字才真的傳得到需要它的使用者手上。兩邊都以為是對方的事,最後的結果就是 alt 文字要嘛空白,要嘛寫了卻沒被正確讀出來。

AI 工具開始直接讀取設計檔案,維護乾淨系統比分工本身更重要

回到開場提到的現象,AI 代理人現在能直接讀取設計檔案裡的圖層、命名與 design token,去產生程式碼。這代表設計稿畫得乾不乾淨、token 命名一不一致,不再只是設計團隊自己的美感堅持,而是直接決定 AI 產出的程式碼堪不堪用。

延續前面提到的 Dev Mode MCP server,它讓 AI 代理人讀取的資料涵蓋圖層階層、樣式、變數、元件屬性與素材參照,本質上是讓代理人讀取一套既有的系統去產生結果。換句話說,AI 產出的品質,取決於這套系統本身乾不乾淨、命名一不一致這件事,而這套系統從來不是只有設計、或只有前端單方面在維護。

AI 並沒有讓誰該負責什麼這個問題消失,反而把維護一套雙方都讀得懂、機器也讀得懂的系統,變成設計與前端共同的責任。分界因此正在往一個新的方向移動,從誰畫誰刻,移向誰維護這套系統的哪一塊。

分界該寫進交接流程裡,不該留給職稱去猜

設計與前端的界線不該靠這件事聽起來比較像我的工作這種直覺去猜,也不該靠職稱做預設分配,例如反正前端比較閒就把不確定的事都推給前端。實際做法是把前面提到的幾類灰色地帶,斷點、互動狀態、design token、alt 文字,逐一列進交接清單,針對每一類先講清楚這裡誰的決定算數,寫進團隊都看得到的文件裡,而不是等吵起來才臨時談。

這不是要消滅模糊地帶,模糊地帶永遠都會存在,新的工具、新的畫面元素還會不斷生出新的灰色地帶。真正該做的是先講好吵不清楚的時候誰說了算,讓交接從單純丟一個檔案過去,變成維護一份清楚的系統。

AI 把轉譯這件事變快了,卻沒有讓分工變簡單,它只是讓原本靠時間磨合掉的問題,提前攤在檯面上而已。真正決定一個團隊做得順不順的,從來不是設計和前端誰讓誰一步,而是這條界線畫得夠不夠清楚,清楚到連新加入的人都看得懂,也清楚到就算換了工具、換了團隊,這套判準依然站得住。

常見問答

本區問答由 AI 依文章內容自動整理,僅供快速參考,正式內容仍以全文為準。

設計與前端的界線該怎麼畫?

判準不是這件事聽起來比較像設計還是比較像技術,而是看這個決定會不會被瀏覽器環境驗證;會影響使用者在瀏覽器裡實際看到、操作到的結果,且答案得靠不同裝置與瀏覽器驗證的,該交給前端,決定畫面想傳達什麼、資訊輕重順序的意圖判斷,該交給設計。

網站的斷點該設在幾個像素寬度,誰該決定?

斷點該設在哪個像素寬度、要設幾個、導覽列何時收進漢堡選單,屬於瀏覽器裡怎麼運作的技術判斷,該由前端定案;但同一個尺寸下哪塊內容先被看到、哪個按鈕不能被擠出畫面外,是資訊層級的判斷,仍該由設計先給答案。

圖片的 alt 替代文字該由誰決定內容?

該由清楚這張圖片為何存在的人決定,通常是設計或內容撰寫者,因為這是關於圖片想傳達什麼的意圖判斷;至於 alt 屬性有沒有正確寫進 HTML、圖示按鈕是否用語意化標籤包起來,則是前端的技術職責,兩者都做對,內容才真正傳得到需要的使用者手上。

hover、錯誤訊息這類互動狀態,沒畫在設計稿裡怎麼辦?

這類狀態一樣牽動視覺意圖,例如錯誤訊息該用什麼語氣、空狀態要不要放插圖鼓勵使用者,都是設計判斷,不是前端能力範圍內該自己補的空缺;設計沒有先定義清楚,前端做出來的版本就會是一個沒有視覺判斷介入的版本,該把這些狀態先納入設計稿的清單裡。

AI 能讀懂設計檔案後,畫稿乾不乾淨還重要嗎?

更重要,AI 代理人現在能直接讀取設計檔案裡的圖層、命名與 design token 去產生程式碼,畫稿乾不乾淨、token 命名一不一致,直接決定 AI 產出的程式碼堪不堪用;維護一套雙方都讀得懂的系統,因此變成設計與前端共同的責任。

資料來源
  1. Breakpoints in Responsive Design(2024) — Nielsen Norman Group(Kelley Gordon)
  2. Introducing our Dev Mode MCP server: Bringing Figma into your workflow — Figma
  3. An alt Decision Tree — W3C 網頁無障礙推動組織(WAI)