Claude Design 把素材變成系統

Claude Design 把品牌素材變成可重複使用的團隊設計系統。

我用設計系統一陣子了，越用越知道哪裡不對勁。很多工具嘴上說是「幫你建立品牌系統」，實際上就是叫你丟一堆素材進去，然後給你一個看起來很整齊、但根本不敢直接上線的半成品。顏色像、字體像、按鈕也像，但一到真實頁面就開始走鐘，最後還是回到每個人各做各的。我最煩的就是這種假簡單流程，因為它看起來省事，實際上只是把混亂延後。

這次讓我停下來看的，是 Claude Help Center 的設定教學。它不是在跟我講什麼宏大理論，而是很直接地說：把你真的有的資產丟進去，讓 Claude 抽出可重用的元素，再慢慢修到符合品牌。Claude Design 目前在 beta，支援 Pro、Max、Team、Enterprise 方案，而且是給會真正擁有這套系統的人來做。這點很重要，因為設計系統死掉，通常不是工具不行，是沒人願意管那段最煩的中間流程。

先丟資產，不要先丟幻想

“It extracts reusable components, colors, typography, and patterns from the assets you provide—codebases, slide decks, or other design references—and uses them as the foundation for every project created within your account.”

翻譯一下就是：Claude Design 不是要你憑空發明一套系統，它要的是證據。真實畫面、真實元件、真實品牌素材。你給它 React component library，它可以讀結構；你給它簡報，它可以看出視覺語言；你給它 logo 跟配色檔，它至少能先抓出基本 token。

我以前最常看到的爛局，就是團隊還沒決定 source of truth，就先開始寫「完美設計系統規格」。結果最後變成 Figma、行銷網站、前端實作三方互打，誰都說自己才是對的。Claude 這種做法比較務實：先把現有的東西餵進去，再讓模型去整理出穩定模式。

實操上我會這樣做：先選一個主要來源。產品 UI 在 code 裡，就先用 code；品牌感最強的是行銷頁，就先用成熟頁面或 deck；如果兩個都有，那更好。重點不是完美，而是降低猜測。Claude 只能從你給的東西裡抽特徵，所以來源越乾淨，後面你要修的就越少。

• 產品團隊最適合：component library 或 design system repo
• 品牌團隊最適合：完成度高的 deck、PDF、landing page
• 混合團隊最適合：code、截圖、品牌素材一起上

先定組織，再談系統，不然只是在重複做白工

文件裡有一句我覺得很實在：先建立或切換到你的 organization，再完成 onboarding。聽起來像小事，但這其實就是整個流程的核心。這不是每個專案各自試一次的玩具，它是 organization 層級的設定，之後 Team 和 Enterprise 的新專案會直接沿用。

這件事會直接改變我的思考方式。以前我會問：「怎麼讓這張 mockup 看起來好看？」現在我會問：「什麼東西應該讓每個新專案自動繼承？」這才是正確問題。如果你的目標是減少 style drift，你就不能讓每個人都從空白開始。空白最容易養出各種自以為是的設計。

我自己做內部工具時就踩過這坑：每個新專案都從不同的 button radius 開始、不同的灰階開始、不同的 heading 口味開始。沒人故意亂搞，只是大家都從空白出發。Claude Design 的 organization flow，就是在拆掉這個空白起點。

實操上，我會先決定誰是 owner，再上傳素材。小團隊可能是 lead designer 或 frontend lead；企業環境通常是 brand owner 加上有權限的 admin。不要讓五個人一起「幫忙」，不然最後通常只會得到五套半成品。

• 先確認 admin 權限
• 只指定一個編輯與發布 owner
• organization 名稱要跟實際使用團隊一致

不要只上傳規範，給它看真的例子

教學裡有一句很直白：要放 real examples，不要只放 spec。這句很關鍵。色票只能告訴 Claude 什麼是藍色；完成的 landing page 才會告訴它藍色在真實版面裡怎麼工作，旁邊配什麼字級、什麼間距、什麼層級。這就是 token list 跟可用系統的差別。

Claude 建議的素材類型很廣：codebase、prototype、slide deck、document、logo、typography specimen 都可以。這點我很喜歡，因為它比較像真實團隊的樣子。不是每家公司都有乾淨到發亮的 design system repo。很多公司只有一份 rebrand PDF、一個 Figma export、跟一個「大致上還可以」的前端 app。沒關係，先餵最好的證據。

我會把重點放在 coverage，不是 perfection。單一來源可以起步，但多種來源更容易讓 Claude 比對出穩定部分。尤其是你的品牌常常卡在「官方品牌」跟「產品團隊實際在用的東西」不一致時，多一點素材比較容易把那條界線拉出來。

我一直偏好能撐住不完美輸入的系統，因為現實就是這樣。沒人真的有一個永遠最新、每個元件都完整記錄的資料庫。就算有，你也是少數。對大多數人來說，做法就是先丟最強的證據，再看生成出來的 kit 能不能像你要的品牌。

實操上，我會建一個小而多樣的 asset bundle。不要丟十張幾乎一樣的截圖。放一個首頁、一個 dashboard、一張簡報頁、再加品牌色票。如果 codebase 裡有 component library，也一起放。你是在教系統品牌的形狀，不是在教它單一畫面。

用會露餡的 prompt 測，不要拿 demo 騙自己

上傳完之後，Claude 會產生一個 design system UI kit。文件說通常會包含 colors、typography、components、layout patterns。這些都不差，但真正的測試，是你丟一個具體、而且有點刁的需求，看它會不會露餡。

教學建議的測試 prompt 像是：「為 [你的產品] 做一個 landing page。」、「設計一個顯示 [相關指標] 的 dashboard。」、「做一份關於 [團隊常做主題] 的簡報。」我覺得這方向很對，因為太泛的 prompt 會把問題藏起來。landing page 可以看層級對不對；dashboard 會暴露 spacing 和 component 重用有沒有正常；簡報則會直接測到字體系統能不能扛長內容。

也就是說，你要測的是你團隊真的會做的工作，不是拿一張 demo 截圖交差。如果你們主要交付 dashboard，就不要只拿 marketing hero section 來驗證。若你們常做 sales deck 或 executive deck，就直接拿投影片測。系統要在真實使用情境裡拿到信任，不是在漂亮畫面裡自嗨。

我自己看這類系統時，通常會盯三件事：顏色有沒有一致、標題與內文是不是同一個家族、元件有沒有一直重複而不是每次都變形。只要其中一項開始漂，通常不是模型壞掉，而是輸入不夠，或 source 本身就不穩。

實操上，我會先做一份很短的驗證清單，而且每次更新都用同一組 prompt。這樣你才看得出來是系統真的變好了，還是只是換了另一種長相。

• 輸出有沒有維持正確的色彩層級
• 標題、內文、標籤的字級關係是否一致
• 重複元件有沒有維持重複，而不是到處變形
• 版面是否符合團隊實際交付的工作型態

發布不是按按鈕，是把預設值交出去

Claude Design 不只是讓系統留在建立者自己手上。當你打開 Published 開關之後，organization 裡從 homescreen 建立的新專案，會直接使用這套 design system，而不是 default。這一刻很重要，因為流程從草稿變成會影響大家的預設行為。

所以我對那些急著發布的團隊都會有點懷疑。系統如果只有八成對，太早發布只是把痛苦擴散出去；但如果它夠穩、夠一致，發布就能省掉大量重複設定。新專案一開始就有正常的起點，這在任何內部設計流程裡都很值錢。

文件裡最重要的細節之一，是發布綁的是 organization，不只是單一專案。這代表這個決定有營運層級的重量。你不是在核准一個檔案，你是在改變未來工作的預設行為。

實操上，我會把發布當成 release 來看。先 review 生成的 kit，再用真實 prompt 驗證，最後才把開關打開。如果你在 Team 或 Enterprise，還要先跟團隊說明變更，不然大家會以為 Claude 突然變怪了。不是，它只是開始照你的預設跑。

再補一個很實際的點：Enterprise 預設是關閉的。不要以為你帳號能用 Claude，就代表這個功能已經開好。先檢查 organization settings 和 permissions，不然你只是在找一個根本沒啟用的 toggle。

更新不要重做，直接 remix 就好

我最喜歡這篇教學的地方，是它的更新路徑。你可以到 organization settings 裡，點你要改的 design system 旁邊的 Open，再按右上角的 Remix，把 chat interface 打開。這個心智模型比「刪掉重來」好太多了。

翻譯一下就是：你的設計系統不是一次寫死，它是可以透過對話慢慢演進的。品牌會變、產品會長大、字體會收斂、色彩會微調。如果唯一的更新方式是整套重做，大家只會拖到系統明顯爛掉才肯動。這就是老系統會發霉的原因。

我以前接手過那種老系統，每次改一個地方都像在做 migration。沒人想碰，因為一動就會牽到十個下游假設。remix flow 的好處，就是把修正成本壓低。你可以直接叫 Claude 改系統，然後看結果，不用整包丟掉。

實操上，我會把 remix 用在小幅修正，不是拿來做緊急大翻修。如果 button style 稍微不對，就修；如果 typography scale 太鬆，就修；如果品牌方向整個換掉，那才可能需要比較大的 reset，但多數更新其實沒那麼戲劇化。

這裡又回到 ownership。沒人知道誰能 remix，更新就會卡住。指定一個人負責，並且讓他有足夠 context 判斷什麼叫「差不多可以」。設計系統最怕的不是不完美，是沒人敢決定。

可抄的模板

# Claude Design 團隊設計系統流程模板

## 1) 先定 owner
- 指定一位 designer、brand owner 或 frontend lead
- 確認 organization admin 權限可用
- 決定誰負責 review 與發布

## 2) 收集素材
至少準備一種，最好多種：
- 含元件庫的 codebase
- 能代表品牌的 slide deck 或 PDF
- 現有產品截圖或 prototype
- 品牌素材：logo、palette、typography 規格

## 3) 建立或切換 organization
- 打開 Claude Design
- 在左下角 project picker 選對 organization
- 完成 onboarding

## 4) 上傳 assets
- 優先放真實案例，不要只放規格
- 放完成頁面或畫面，不要只有 token
- 品牌同時存在於產品與行銷時，兩邊素材都放

## 5) 檢查生成結果
重點看這幾項：
- 色彩層級是否一致
- 字體層級是否合理
- 元件是否可重複使用
- 版面與 spacing 是否穩定

## 6) 用真實 prompt 驗證
每次都用同一組測試：
- 為 [產品] 做 landing page
- 設計一個顯示 [指標] 的 dashboard
- 做一份關於 [主題] 的 presentation

## 7) 確認後再發布
- 只有 review 完才打開 Published
- 確認 organization 新專案會套用這套系統
- 跟團隊說明這次變更

## 8) 後續更新用 Remix
- 到 organization settings
- 點 design system 旁的 Open
- 點 Remix 打開 chat
- 直接叫 Claude 調整，不要重建

## 9) 快速驗證清單
- 視覺是否符合品牌語氣
- 顏色、字體、間距是否一致
- 元件是否持續重複而不是漂移
- 系統是否支援團隊真正在交付的工作

這就是我會直接丟給團隊用的版本。它的目的不是做一份漂亮文件，而是讓你真的開始動：先定 owner，再餵真實素材，接著用真實工作驗證，最後才發布，之後靠 remix 持續修。

原始來源是 Claude Help Center。上面這篇的步驟骨架來自官方文件，我的整理方式、操作順序和實戰提醒是我自己重新拆過的版本。你如果要看最原始的說法，就直接回到官方教學。