design-brief

design-brief

熱門

透過互動式訪談、程式碼庫探索與體驗設計決策,建立設計簡報。儲存為專案中的 Markdown 檔案。當使用者想撰寫設計簡報、規劃新功能或頁面、定義 UI 方向,或提及「brief」時使用。

435星標
34分支
更新於 2026/7/6
SKILL.md
唯讀
名稱
design-brief
描述

透過互動式訪談、程式碼庫探索與體驗設計決策,建立設計簡報。儲存為專案中的 Markdown 檔案。當使用者想撰寫設計簡報、規劃新功能或頁面、定義 UI 方向,或提及「brief」時使用。

此技能透過結構化對話建立設計簡報。若某些步驟非必要,可跳過。

範例提示

  • 「為 onboarding 流程寫一份簡報」
  • 「我需要先規劃設定頁面,再開始建構」
  • 「幫我定義行銷登陸頁面的方向」
  • 「為這個做簡報:一個顯示專案健康指標的儀表板」

流程

  1. 向使用者詢問他們想建構的詳細描述、目標對象,以及任何既有的限制或想法。

  2. 探索現有程式碼庫以了解當前狀態。特別掃描以下各項:

    • CSS 變數 / tokens:名為 tokens.cssvariables.csstheme.css 的檔案,或帶有自訂屬性的 :root 宣告
    • Tailwind 設定tailwind.config.jstailwind.config.ts,檢查 theme.extend 中的自訂值
    • UI 框架主題:Material UI 的 createTheme、Chakra 的 extendTheme、shadcn 的 globals.csscomponents.json
    • 元件目錄components/ui/shared/,或任何包含可重用 UI 元件的資料夾
    • Storybook.storybook/ 目錄或 *.stories.* 檔案,表示有文件化的元件庫
    • 設計 token 檔案:JSON token 檔案(Style Dictionary 格式、Figma token 匯出)
    • Package.json UI 相依套件:tailwindcss、@mui/material、@chakra-ui/react、@radix-ui、lucide-react、framer-motion 等
    • 字型載入:HTML 中的 Google Fonts 連結、@font-face 宣告、CSS/設定中的字型匯入
    • 現有頁面/佈局:路由檔案、佈局元件、頁面模板,顯示已建立的模式
    • 若存在元件,將其視為起始詞彙。簡報應擴展而非取代。
  3. 持續訪談使用者,深入每個設計面向,直到達成共識。逐一走過設計樹的每個分支,逐步解決決策間的相依性。針對每個問題,提供你的建議答案。

    至少涵蓋:

    • 主要使用者是誰?他們的 JTBD 是什麼?他們想達成什麼?
    • 這個介面的成功樣貌為何?
    • 情感基調是什麼?(冷靜、急迫、有趣、權威、溫暖、冷靜)
    • 這個介面應該像哪些現有產品、網站或風格?不該像什麼?
    • 有哪些硬性限制?(裝置、無障礙需求、效能預算、品牌指南)
    • 這個介面會包含哪些內容?哪些是佔位符,哪些是真實內容?
  4. 一旦完全理解,使用以下模板撰寫簡報。

檔案輸出

將簡報儲存至 .design/<feature-slug>/DESIGN_BRIEF.md,其中 <feature-slug> 是從正在設計的功能或頁面衍生的簡短、小寫、連字號名稱(例如 onboarding-flowsettings-pageproject-dashboard)。

此資料夾結構確保多次執行不同功能的設計流程不會覆蓋先前的工作。後續所有技能(資訊架構、設計 token、簡報轉任務、設計審查)都會讀取並寫入同一個子資料夾。

範例:

.design/
├── onboarding-flow/
│   └── DESIGN_BRIEF.md
└── settings-page/
    └── DESIGN_BRIEF.md

簡報模板

# 設計簡報:[功能/頁面名稱]

## 問題

使用者面臨的問題,從他們的角度描述。非技術面。非商業指標。而是人性的摩擦點。

## 解決方案

這個介面如何解決該問題,以體驗而非功能列表的方式描述。

## 體驗原則

最多三項原則,引導每個設計決策。每項原則應解決一個張力。
範例:「漸進式揭露勝於一次性複雜度」或「信心勝於速度」。

1. [原則] -- [這在實務上的意義]
2. [原則] -- [這在實務上的意義]
3. [原則] -- [這在實務上的意義]

## 美學方向

- **哲學**:[命名哲學或描述的氛圍。可參考 /frontend-design 技能。]
- **基調**:[情感註冊]
- **參考點**:[這個介面應該像的現有產品、網站或風格]
- **反參考**:[這個介面不該像什麼]

## 現有模式

程式碼庫中已存在的元件、token 與慣例,此設計必須尊重或擴展。

- 字型:[目前使用的字型]
- 色彩:[目前的調色盤/變數]
- 間距:[目前的間距尺度]
- 元件:[將被重用或擴展的現有元件]

## 元件清單

此功能所需的 UI 元件清單。針對每個元件,註明其狀態:已存在、需修改或全新。

| 元件 | 狀態                | 備註      |
| ---- | ------------------- | --------- |
| [名稱] | 已存在 / 修改 / 新增 | [詳細說明] |

## 關鍵互動

關鍵的互動模式。描述使用者做了什麼,以及介面如何回應。重點在狀態變化、轉場與回饋。

## 響應式行為

佈局在不同斷點如何調整。註明哪些元件在行動裝置上會改變行為(不僅是尺寸)。

## 無障礙需求

此介面的最低無障礙需求。包含對比度、鍵盤導航、螢幕閱讀器考量與焦點管理。

## 不在此範圍

此簡報明確不涵蓋的事項。請具體說明,以避免建構時範圍蔓延。