| name | web-app-designer |
| context | fork |
| description | Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。 |
Web App Designer（Webアプリデザイナー）
Webアプリのデザインを体系的に行う。依頼内容に応じて適切なデザイン手法を選択・適用し、実装可能なデザイン仕様を出力する。
ワークフロー概要
Phase 1: 要件・コンテキスト把握
→ Phase 2: デザイン手法の選択
→ Phase 3: デザイン実行
→ Phase 4: アウトプット生成
Phase 1: 要件・コンテキスト把握
デザイン対象を正確に理解するための情報を収集する。
Step 1.1: デザイン対象の特定
以下を確認する:
| 確認項目 | 質問例 |
|---|
| アプリ種別 | SaaS / EC / ダッシュボード / LP / 管理画面 / ポータル / SNS |
| デザインスコープ | 新規プロダクト全体 / 特定機能のUI / 既存UIの改善 / レスポンシブ対応 / アクセシビリティ改善 |
| 主要画面 | どの画面をデザインするか（一覧/詳細/フォーム/ダッシュボード等） |
Step 1.2: ターゲット・環境の確認
| 確認項目 | 内容 |
|---|
| ターゲットユーザー | ペルソナ、技術リテラシー、利用頻度 |
| 対象デバイス | デスクトップ中心 / モバイルファースト / 両対応 |
| 対象ブラウザ | モダンブラウザのみ / IE対応 / 特定ブラウザ |
| パフォーマンス要件 | 初期表示速度、データ量の想定 |
Step 1.3: 既存資産の確認
| 確認項目 | 有無を確認 |
|---|
| デザインシステム | 既存のコンポーネントライブラリがあるか |
| ブランドガイドライン | ロゴ・カラー・フォントの規定があるか |
| UIフレームワーク | Tailwind / MUI / shadcn/ui 等の指定があるか |
| 既存コードベース | 既存UIとの整合性を取る必要があるか |
Phase 1のアウトプット: デザインブリーフ（対象・スコープ・制約の要約）
Phase 2: デザイン手法の選択
依頼内容に応じて最適なデザイン手法を選定する。
Step 2.1: 手法選定マトリクス
| 依頼の種類 | 主要手法 | 補助手法 | 参照 |
|---|
| 新規プロダクト全体 | Design Thinking | 画面設計 → インタラクション設計（DS未整備なら先にdesign-system-builderで基盤構築） | — |
| 特定機能のUI | コンポーネント設計 | 状態設計 → インタラクション設計 | references/layout-system.md |
| 既存UIの改善 | ヒューリスティック評価 | ユーザビリティテスト → 改善設計 | — |
| レスポンシブ対応 | モバイルファースト | ブレークポイント設計 → グリッド設計 | references/layout-system.md |
| アクセシビリティ改善 | WCAG 2.1 AA準拠 | ヒューリスティック評価 → セマンティックHTML | references/layout-system.md |
| デザインシステム構築 | → design-system-builderスキルに委譲 | DS全体の構築はdesign-system-builderを使用 | — |
| ダッシュボード・プロダクトUI | 情報アーキテクチャ + ミニマルUI | グリッドレイアウト → データビジュアライゼーション → ユーティリティコピー | references/layout-system.md, references/art-direction.md |
| フォーム設計 | ユーザビリティ原則 | バリデーション設計 → エラー状態設計 | references/layout-system.md |
| LP・マーケティング | ナラティブ構造 + ビジュアルコンポジション | ヒーロー設計 → コンテンツ戦略 → モーション設計 → CTA最適化 | references/art-direction.md, references/layout-system.md |
Step 2.2: 手法の組み合わせ判断
依頼内容が複数の種類にまたがる場合は、手法を組み合わせる。
判断基準:
- スコープが広い（プロダクト全体） → Design Thinking から開始
- スコープが狭い（特定画面） → コンポーネント設計から開始
- 既存UIの改善 → ヒューリスティック評価から開始
- アクセシビリティが要件に含まれる → 常にWCAG 2.1 AAチェックを併用
Phase 3: デザイン実行
選択した手法に基づきデザインを実行する。以下の要素を依頼に応じてカバーする。
Step 3.0: ビジュアル方針定義（LP・プロダクトUI共通）
コンポーネント設計の前に、ページ全体の構図と方針を定義する。詳細は references/art-direction.md を参照。
LP・マーケティングの場合、以下を言語化する:
| 項目 | 内容 | 例 |
|---|
| Visual thesis | ムード・素材・エネルギーの1文説明 | 「NYC コーヒー文化とY2K美学を融合した温かみのあるトーン」 |
| Content plan | ヒーロー → サポート → 詳細 → ソーシャルプルーフ → 最終CTA | 5セクション構成 |
| Interaction thesis | 2-3のモーションアイデア | 「ヒーロー進入アニメーション + スクロール連動パララックス」 |
プロダクトUI・ダッシュボードの場合、以下を定義する:
| 項目 | 内容 |
|---|
| 表面階層 | background → surface → elevated surface の控えめな階層 |
| 情報密度方針 | 濃密だが読みやすい。装飾ではなくタイポグラフィと間隔で階層を表現 |
| カード使用基準 | デフォルトはカードなし。相互作用が必要な場合のみ |
共通の制約: H1は1個、セクション最大6個、フォント2種類まで、アクセント色1色、プライマリCTA1個
Step 3.1: レイアウト設計
グリッドシステム:
- 12カラムグリッドを基本とする（
grid-template-columns: repeat(12, 1fr)）
- 8pxグリッドでスペーシングを統一
- スペーシングスケール: 4, 8, 16, 24, 32, 48, 64, 96px
ページ構造の定義:
┌─────────────────────────────────────┐
│ Header │
├──────────┬──────────────────────────┤
│ Sidebar │ Main Content │
│ (2-3col) │ (9-10col) │
│ │ │
│ │ │
├──────────┴──────────────────────────┤
│ Footer │
└─────────────────────────────────────┘
grid-template-areas でセマンティックなエリアを定義する- ページ全体構造は CSS Grid、コンポーネント内部は Flexbox を使い分ける
Step 3.2: カラー設計
60-30-10ルール（背景60% / 補助30% / アクセント10%）でセマンティックカラー体系（Primary/Secondary/Success/Warning/Error/Info/Neutral 50-950、各50〜950の明度スケール）を定義する。コントラスト比はWCAG 2.1 AA（通常テキスト4.5:1、大テキスト・UIコンポーネント3:1）を満たす。
Step 3.3: タイポグラフィ設計
Major Third（1.25倍）を基本にタイプスケール（xs〜3xl）を定義する。本文はline-height: 1.6、見出しはline-height: 1.15を目安とし、段落幅は1行45〜75文字に収める。4.4のCSS変数として出力する。
Step 3.4: コンポーネント設計（Atomic Design）
5階層で設計する:
| 階層 | 定義 | 具体例 |
|---|
| Atoms | 最小UI要素 | Button, Input, Icon, Badge, Label |
| Molecules | Atomsの組み合わせ | SearchBar, FormField, NavItem, MenuItem |
| Organisms | Moleculesの組み合わせ | Header, Sidebar, DataTable, CardList, Footer |
| Templates | ページ構造のワイヤーフレーム | DashboardLayout, AuthLayout, SettingsLayout |
| Pages | 実コンテンツを含む最終形 | DashboardPage, SettingsPage, LoginPage |
コンポーネント仕様の記述項目:
- 名前（PascalCase）
- 説明（1文）
- Props（型・デフォルト値・必須/任意）
- 状態一覧（Step 3.5参照）
- バリアント一覧
- 使用例
Step 3.5: インタラクション・状態設計
基本6状態:
| 状態 | 視覚表現 | 実装指針 |
|---|
| Idle | デフォルトの見た目 | 基本スタイル |
| Hover | 背景色変化、カーソル変更 | :hover 擬似クラス |
| Active/Pressed | 押し込み表現（scale, shadow変化） | :active 擬似クラス |
| Focused | アウトライン表示 | :focus-visible, outline: 3px solid #0066CC; outline-offset: 2px |
| Disabled | グレーアウト | opacity: 0.5, pointer-events: none |
| Loading | スピナー / スケルトン | アニメーション付き |
追加状態: Error（赤枠 + メッセージ）、Success（緑チェック）、Skeleton（プレースホルダ表示）
アニメーション指針:
- マイクロインタラクション: 100〜200ms
- UI遷移: 200〜300ms
- ナビゲーション遷移: 300〜500ms
- イージング:
ease-in-out（メイン）、ease-out（表示）、ease-in（非表示）
- 300ms以下で応答性を維持する
Step 3.6: レスポンシブ対応
モバイルファーストで設計し、min-width（sm 640 / md 768 / lg 1024 / xl 1280 / 2xl 1536px が一般的な区切り）で段階的にスタイルを追加する。モバイル1カラム→タブレット2カラム→デスクトップ3カラム+常時サイドバーへ拡張し、タッチターゲットは最低44x44pxを確保する。
Step 3.7: アクセシビリティチェック
WCAG 2.1 AAに準拠する（コントラスト比、キーボード操作性、ランドマーク・見出し階層、ARIA属性、labelとinputの関連付け、alt テキスト、prefers-reduced-motion）。
Step 3.8: 品質リトマステスト
デザイン完了時に以下を確認する。すべてYesであること。詳細は references/art-direction.md を参照。
| # | チェック項目 |
|---|
| 1 | ブランド/製品は最初の画面で誤認識不可能か？ |
| 2 | 強いビジュアルアンカーが1つ以上あるか？ |
| 3 | 見出しのスキャンのみでページの主張が理解できるか？ |
| 4 | 各セクションに1つの仕事しかないか？ |
| 5 | カードは本当に必要か？ |
| 6 | モーションは視覚的階層や雰囲気を向上させているか？ |
| 7 | 装飾シャドウをすべて削除してもプレミアムに見えるか？ |
Phase 4: アウトプット形式
依頼に応じて以下の形式で出力する。
4.1: 画面レイアウト
ASCIIアートまたはHTML構造記述で画面構成を表現する。
例: ダッシュボード画面
┌─────────────────────────────────────────────┐
│ [Logo] Dashboard Search... [Avatar ▼] │
├───────┬─────────────────────────────────────┤
│ ≡ Nav │ Welcome, User │
│ │ │
│ Home │ ┌──────┐ ┌──────┐ ┌──────┐ │
│ Tasks │ │ KPI │ │ KPI │ │ KPI │ │
│ Users │ │ Card │ │ Card │ │ Card │ │
│ ... │ └──────┘ └──────┘ └──────┘ │
│ │ │
│ │ ┌────────────────────────────┐ │
│ │ │ Chart / Table │ │
│ │ │ │ │
│ │ └────────────────────────────┘ │
├───────┴─────────────────────────────────────┤
│ Footer │
└─────────────────────────────────────────────┘
4.2: コンポーネント仕様書
各コンポーネントを以下のフォーマットで記述する:
### ComponentName
**説明**: 1文の説明
**Props**:
| Prop | 型 | デフォルト | 必須 | 説明 |
|------|----|-----------|------|------|
| variant | 'primary' \| 'secondary' \| 'ghost' | 'primary' | No | ボタンの見た目 |
| size | 'sm' \| 'md' \| 'lg' | 'md' | No | サイズ |
| disabled | boolean | false | No | 無効状態 |
| loading | boolean | false | No | ローディング状態 |
**状態**: Idle / Hover / Active / Focused / Disabled / Loading
**使用例**:
- プライマリCTA: `<Button variant="primary" size="lg">送信</Button>`
- 二次アクション: `<Button variant="secondary">キャンセル</Button>`
4.3: カラーパレット
## カラーパレット
### プライマリ
| スケール | HEX | 用途 |
|----------|-----|------|
| 50 | #EFF6FF | 背景ハイライト |
| 100 | #DBEAFE | ホバー背景 |
| 500 | #3B82F6 | メインカラー |
| 700 | #1D4ED8 | ホバー状態 |
| 900 | #1E3A8A | テキストアクセント |
（Success, Warning, Error, Neutral も同様に定義）
4.4: タイポグラフィスケール
:root {
--font-family-sans: 'Inter', system-ui, sans-serif;
--font-family-mono: 'JetBrains Mono', monospace;
--text-xs: 0.8rem;
--text-sm: 0.889rem;
--text-base: 1rem;
--text-lg: 1.25rem;
--text-xl: 1.563rem;
--text-2xl: 1.953rem;
--text-3xl: 2.441rem;
--leading-tight: 1.15;
--leading-normal: 1.6;
--leading-relaxed: 1.75;
}
4.5: インタラクション仕様
各インタラクションを以下で記述する:
### [コンポーネント名] のインタラクション
| トリガー | アクション | フィードバック | デュレーション |
|----------|-----------|---------------|---------------|
| クリック | 送信処理開始 | ボタンがloading状態に | 即時 |
| 送信完了 | 成功通知表示 | トースト表示 + ボタンsuccess状態 | 200ms |
| エラー | エラー通知表示 | トースト + ボタンidle復帰 | 200ms |
注意事項
- 実装可能性を優先する: Claudeはビジュアルモックアップを画像生成できない。ASCIIアート・HTML構造・CSS仕様で実装者が再現できる形で出力する
- 既存資産を尊重する: 既存デザインシステムやUIフレームワークがある場合、それに合わせる
- 段階的に進める: 全要素を一度に出力せず、Phase 1→4の順で段階的に進め、各Phaseでユーザーの確認を取る
- アクセシビリティは常に考慮する: 依頼にアクセシビリティの言及がなくても、WCAG 2.1 AA準拠を基本とする
- モバイルファーストを基本とする: 特に指定がなければモバイルファーストで設計する
連携スキル
| スキル | 連携タイミング |
|---|
| design-system-builder | デザインシステム全体の構築・運用が必要な場合。本スキルはDS成果物（原則・トークン・コンポーネント仕様）を入力として個別画面を設計する |
| app-idea-workshop | アイデア段階からの場合、先にワークショップでアイデアを具体化する |
| spec-gen | デザイン完了後、実装仕様書を生成する |
| architecture-reviewer | デザインシステムのアーキテクチャをレビューする |
| critical-code-review | デザイン実装後のコードレビュー |
