mcpField
D
design-handoff-brief

design-handoff-brief

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

design-handoff-brief について

プロダクトマネージャーやデザイナー向けに、機能ブリーフやPRDをユーザー目標、制約、エッジケース、成功基準に基づくデザイン引き継ぎ資料へ変換するスキルです。モデルを呼び出さずに色のコントラストを測るコマンドラインツールも含みます。

主な機能

  1. 01機能をユーザー目標として再定義
  2. 02制約とエッジケースの整理
  3. 03観察可能なデザイン成功基準
  4. 04対象外項目の明示
  5. 05コントラスト測定用コマンドラインツール

活用シーン

  1. 01PRDからデザイン要件を作成
  2. 02デザイナーへの引き継ぎ準備
  3. 03インターフェース配色のコントラスト確認

インストール

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

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

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

詳細

デザイン引き継ぎブリーフスキル

デザイナーが正しい方向性を見失ってからではなく、Figmaを開く前にユーザーの状況や制約を把握できるよう、デザイナーの成功を後押しするデザインブリーフを作成します。

必須入力

提示された情報をもとに作成してください。不足している情報があっても、完全な出力を作成します。不足分は妥当な仮定で補い、(仮定、要確認) と記載して、最後に仮定を一覧にしてください。中心となる題材そのものが欠けている場合（書く内容が何もない場合）に限り、先に質問してください。

  • 機能ブリーフまたはPRD（大まかなメモでも構いません）
  • デザイナーの名前またはチーム名（個別対応に使用）
  • 技術的制約（すでに判明しているエンジニアリング上の制限）
  • スケジュール（デザインをいつまでに完成させる必要があるか）

デザイナーが実際に必要としていること（PMが見落としがちなこと）

  • 機能名ではなく、ユーザーの目標
  • この時点でのユーザーの感情
  • 成功の定義 — デザインがうまくいったと、どうすればわかるか
  • 技術、法務、ブランド、アクセシビリティ上の制約
  • 対応が必要なエッジケース
  • 明示的に解決の対象としないこと

プロセス

  1. 提示された機能ブリーフまたはPRDを読む
  2. ユーザーの目標を抽出する（機能を中心とした表現から、ユーザーの成果を中心とした表現に言い換える）
  3. 制約を特定する — 技術的制限、ブランドガイドライン、アクセシビリティ要件
  4. デザインで対応すべきエッジケースを列挙する
  5. デザインを評価するための成功基準を定める
  6. デザインのスコープクリープを防ぐため、「対象外」セクションを作成する
  7. 検証 — 列挙したすべてのエッジケースが具体的にデザインできる内容であること、また対象外の各項目が明確に「対応しない」と言えるほど具体的であることを確認する

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

コントラスト比は目視では判断できません。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 — 可能であれば測定可能にする]
  • [基準2]
  • [基準3]

制約：

  • 技術：[エンジニアリング側から提示された制限]
  • ブランド：[関連するブランドガイドライン]
  • アクセシビリティ：[必要なWCAGレベル、具体的な要件]
  • 法務／コンプライアンス：[該当する場合]

デザインで対応すべきエッジケース：

  • [エッジケース1]
  • [エッジケース2]
  • [エッジケース3]

明示的な対象外：

  • [今回のデザインでは解決しないこと]

参考資料：

  • ユーザーリサーチ：[リンク]
  • 既存のパターン：[Figmaコンポーネントライブラリのリンク]
  • 競合の事例：[関連する場合はリンク]

品質チェック

  • ユーザーの目標がユーザーの言葉で記載されている（機能／製品を中心とした表現ではない）
  • 少なくとも1つのエッジケースが、エラーまたは失敗状態を扱っている
  • 成功基準が測定可能、または観察可能である（「見栄えがよい」ではない）
  • 対象外の項目に、対象に含まれると思われがちだが実際には含まれないものが少なくとも1つ明記されている
  • 技術的制約が、エンジニアが確認できるほど具体的である

アンチパターン

  • ユーザーの目標を機能の言葉で書かないでください（「チェックアウトフローを設計する」など）。ユーザーの視点に立ち、動機と結果を含めて書く必要があります。
  • 「明示的に対象外とする項目」のセクションを省略しないでください。これがないと、デザイナーが今回のイテレーションで対象としていない問題まで、意図せず解決してしまいます。
  • どの機能にも当てはまるほど一般的なエッジケース（例：「エラーに対処する」）を列挙しないでください。各エッジケースは、この機能固有の失敗パターンに即したものである必要があります。
  • エンジニアリング上の制約が正確であることを確認せずに、ブリーフを引き渡さないでください。誤った制約は、制約がないことよりも悪影響があります。
  • ユーザーの感情的な背景を省略しないでください。感情的な土台のないデザインは、技術的には正しくても、体験としては平坦なものになります。

例となるトリガーフレーズ

  • 「デザインブリーフを作成して。」
  • 「デザインの引き継ぎ資料を作成して。」
  • 「新機能についてデザイナー向けのブリーフを作成して。」
  • 「PRDをデザイン要件に変換して。」

コメント

Markdown 対応