mcpField
F
figma-design-brief

figma-design-brief

github.com/mohitagw15856デザイン・UI1.5k49 回インストール5 日前に更新
リポジトリ

figma-design-brief について

figma-design-briefは、製品要件をFigmaで作業を始めるデザイナー向けの構造化されたブリーフにまとめます。ユーザーフロー、画面、コンポーネント、制約、アクセシビリティの確認を扱います。

主な機能

  1. 01要件をブリーフに整理
  2. 02ユーザーフローと例外の整理
  3. 03画面とコンポーネントの一覧
  4. 04アクセシビリティとコントラスト確認

活用シーン

  1. 01PRDをデザインブリーフに変換
  2. 02機能要件のデザイン準備
  3. 03指定色のコントラスト確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill figma-design-brief

インストール後、Claude Code で/figma-design-briefを入力して読み込まれたか確認します。

詳細

Figma デザインブリーフスキル

プロダクト要件や機能リクエストを、構造化されたデザインブリーフに変換します。デザイナーが自信を持って Figma を開き、制作を始めるために必要な情報をすべてまとめます。

こちらとは少し違いますか？ デザインがすでにあり、仕様との照合を行う場合は、figma-design-qa を使用してください。

必要な入力

  • 機能または要件（PRD の抜粋やチケットを貼り付けるか、機能を説明してください）
  • ユーザーの目標（ユーザーは何を達成しようとしていますか？）
  • プラットフォーム（iOS / Android / Web / レスポンシブ / すべて）
  • 利用可能な既存コンポーネント（任意）
  • スケジュール（デザインはいつまでに必要ですか？）

プログラムによるヘルパー

コントラスト比は目視では判断できません。AA の基準は 4.5:1 です。白地に #777777 を使うと 4.478（不合格）、#767676 では 4.54（合格）です。スクリーンショットを どれだけ見ても、この違いは判別できません。計算しましょう。

npx --yes notugly fix "#8ab4f8" "#ffffff"     # ratio, APCA, and the nearest passing colour
npx --yes notugly onepager <url> --out review.html   # every pairing, printable
npx --yes notugly vision                      # which colours merge for colour-blind viewers

notugly fix は、比率、APCA の輝度コントラスト、および選択済みの色に最も近い合格色（色相と彩度は同じ）を返します。 これらの数値を推測するのではなく、以下の表に記入してください。

決定論的で、依存関係はゼロ、モデル呼び出しもありません。そのため実行コストはかからず、毎回同じ結果が得られます。

ブリーフで色を指定する場合は、想定するテキストと背景の各組み合わせについて、測定した比率を明記してください。実現不可能な組み合わせを指定したブリーフは、誰かが気づくまでデザインサイクルを無駄にします。

出力構成

1. ブリーフのヘッダー

機能、PM、デザイナー、プラットフォーム、デザイン期限、開発への引き継ぎ日。

2. 何を、なぜデザインするのか
  • 目標：［解決するユーザーの課題を一文で］
  • 背景：［2～3文。なぜ今なのか？何がきっかけなのか？］
  • 成功の定義：［具体的に観察できる成果］
3. デザインするユーザーフロー

フロー N：［フロー名］

  • 開始地点：［ユーザーが開始する場所］
  • 手順：［番号付きの主要な手順］
  • 終了地点：［フローの終了場所］
  • エッジケース：［空の状態、エラー状態、読み込み状態］
4. 必要な画面
画面新規／更新備考
［画面］新規［主な要件］
5. 必要なコンポーネント
コンポーネントライブラリ内にあるか対応
［コンポーネント］はい／いいえ／バリアントが必要使用／作成／拡張
6. 制約と要件
  • 必須事項：［譲れない制約］
  • 避けるべきこと：［使用しないデザインパターン］
  • アクセシビリティ：［WCAG レベル、タッチターゲットのサイズ］
7. 未解決の質問
  • ［質問 — 担当者］

品質チェック

  • 目標が成果に焦点を当てている（「機能をデザインする」ではない）
  • すべてのフローにエッジケースが含まれている
  • コンポーネントの表で新規作成と再利用が区別されている
  • 制約にアクセシビリティ要件が含まれている
  • 未解決の質問に担当者が割り当てられている

アンチパターン

  • 解決策を説明するデザインブリーフを書かないでください。ブリーフではデザインの答えではなく、問題と制約を説明する必要があります
  • 成功基準を省略しないでください。デザイナーは着手前に「完了」がどのような状態かを把握する必要があります
  • 再利用できる既存のコンポーネントを省かないでください。デザインシステムを考慮しないブリーフは、一貫性のない実装につながります
  • 未解決の質問を放置しないでください。デザイン作業中ではなく、開始前にエスカレーションしてください
  • 要件とデザイン指示を混同しないでください。ブリーフが定めるのは「何を」であり、「どのように」ではありません

想定されるトリガーフレーズ

  • 「［機能］のデザインブリーフを書いて」
  • 「この PRD を Figma のデザインブリーフにして」
  • 「［要件］について、何を作るべきかデザイナーに説明して」
  • 「Figma 用の［機能］のデザイン仕様を作成して」
  • 「［機能］をデザインするために、デザイナーが知っておくべきことは何ですか？」

コメント

Markdown 対応