UI Mockup Builder
画面モックアップは、最終プロダクトに近い「見た目」を具体化する静的な設計図(高フィデリティ)です。
Purpose
-
合意形成を早く・安く、実装前に見た目の地雷を潰す
-
開発引き渡しを滑らかにする
-
静的画だけで誤解される「状態」を先に明確にする
Output (default)
リポジトリに「Mockup Pack(モックアップ一式)」を作成します。Figma自体の操作はせず、Figmaに起こせる粒度の仕様と、必要ならHTML/Tailwindで再現できる静的モックを生成します。
推奨の出力先:
-
docs/mockups/<feature-or-epic>/
-
README.md (目的・前提・対象画面・参照・決定事項)
-
style-guide.md (色/タイポ/余白/角丸/影/アイコン方針)
-
tokens.json (色・スペーシング・タイポなどのトークン)
-
screens/
-
<screen-id>__spec.md (画面仕様)
-
components/
-
<component-id>__spec.md (コンポーネント仕様)
-
copy/
-
strings.md (文言案、i18n注意、可変長対策)
-
state-matrix.md (主要状態一覧)
-
html/ (任意:静的HTMLモック)
-
exports/ (任意:スクリーンショット、PNG出力物など)
Operating Principles
-
最初にWireframe/Mockup/Prototypeを判定:早期にフィデリティを間違えない
-
既存資産を最優先:デザインシステム/トークン/コンポーネントがあれば必ず寄せる
-
状態を先に潰す:通常/空/ローディング/エラー/成功を最低限揃える
-
作り込みすぎない:目的に対して過剰なフィデリティは避ける
-
実データで検証:ダミーテキストでなく、実データ寄りで桁・改行・i18nを確認
Workflow
Step 0: Activation check(最初に必ずやる判定)
-
依頼が「ワイヤー」「モック」「プロトタイプ」のどれかを判定する
-
Wireframe:構造・情報設計・導線のラフ(未完成に見せて議論をロジックに寄せる)
-
Mockup:見た目を最終に寄せた静的画(色/タイポ/余白/コンポーネント/状態)
-
Prototype:遷移や操作感の検証(インタラクティブ)
-
モックアップが適切なら、このSkillを続行
-
ワイヤーが先なら「まずワイヤー→確定後にモックアップ」の順に提案し、同じフォルダに段階成果物として残す
Step 1: Repo scan(既存資産の確認)
-
既存のデザインシステム/UIライブラリ/トークンがあれば最優先で寄せる
-
例:design/ , docs/design-system/ , tokens/ , tailwind.config.* , shadcn/ui , MUI , Chakra , Ant 等
-
既存の画面遷移図/PRD/要件/ユーザーフローがあれば読み、画面一覧を確定する
Step 2: Minimal questions(不足があるときの最小ヒアリング)
-
resources/intake_questions.md を参照し、足りない情報だけを質問する
-
ユーザーに確認するのは「作るために絶対必要」なものだけ
-
なければ仮定して進め、仮定はREADMEに明記
Step 3: Foundation(見た目の土台を決める)
-
resources/style_guide_template.md と tokens.json を作る(既存があれば拡張・補完のみ)
-
タイポ/カラー/レイアウト/コンポーネント方針を決定
Step 4: Screen-by-screen mockup spec(画面ごとに静的モック仕様を作る)
-
各画面 screens/<screen>__spec.md を作成
-
resources/screen_spec_template.md をベースに仕様を埋める
-
画面の目的/レイアウト/コンポーネント/表示データ/状態/注釈を必ず含める
Step 5: Components(ズレを防ぐためにコンポーネントを先に固める)
-
新規コンポーネントが必要なら components/<component>__spec.md を作る
-
resources/component_spec_template.md をベースに作成
-
variants / states / props を明確にし、画面間で使い回せる前提にする
Step 6: State matrix(例外や落とし穴を先に潰す)
-
state-matrix.md に「画面×状態」を表でまとめる
-
最低限:空(0件)/ローディング/エラー/成功/無効
Step 7: Optional HTML mock(必要な場合だけ)
-
開発側との合意形成やレビュー効率のために、静的HTMLで見た目を再現する(任意)
-
ルール:動的ロジックは作らない(見た目と状態だけ)
-
Tailwind等があるならそれに寄せる
Step 8: Handoff pack(開発引き渡しの不足情報を埋める)
-
README.md に以下をまとめる
-
対象画面一覧、到達条件(権限/ルート)
-
画面ごとの仕様ファイルへのリンク
-
未確定事項(要確認)と暫定仮定
-
重要なデザイン判断
Step 9: Quality check(品質チェック)
-
resources/quality_checklist.md で自己レビューし、問題があれば修正
-
特に以下を重点確認:
-
目的に対してフィデリティが適切
-
静的画で誤解される「状態」が揃っている
-
実データ寄りの内容で崩れ検証している
-
レスポンシブとアクセシビリティを意識している
-
コンポーネント/トークンに寄せて、画面ごとのズレが生まれない
Formatting Rules
-
Markdownを基本にし、読みやすさ優先
-
テーブル、箇条書き、画像リンクを活用
-
重要な判断は太字、参照はリンク
-
コード例はシンタックスハイライト付き
Examples (triggers)
-
「この機能の画面モックアップ作って。開発に渡せる状態(空・エラー・ローディング込み)で」
-
「Figmaに起こす前に、画面の見た目を最終に寄せたモック仕様をMarkdownで作りたい」
-
「この画面群、ブランドカラーとタイポまで決めた高フィデリティの静的デザインが欲しい」
-
「UI mockupを作って」
-
「画面デザインの状態パターンも含めて設計書を作って」
References