CAPHTECH

web-app-designer

"Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。"

CAPHTECH 1 Updated 3mo ago

Resources

1
GitHub

Install

npx skillscat add caphtech/claude-marketplace/web-app-designer

Install via the SkillsCat registry.

SKILL.md

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で基盤構築) references/design-methods.md
特定機能のUI コンポーネント設計 状態設計 → インタラクション設計 references/layout-system.md
既存UIの改善 ヒューリスティック評価 ユーザビリティテスト → 改善設計 references/design-methods.md
レスポンシブ対応 モバイルファースト ブレークポイント設計 → グリッド設計 references/layout-system.md
アクセシビリティ改善 WCAG 2.1 AA準拠 ヒューリスティック評価 → セマンティックHTML references/layout-system.md
デザインシステム構築 design-system-builderスキルに委譲 DS全体の構築はdesign-system-builderを使用
ダッシュボード設計 情報アーキテクチャ グリッドレイアウト → データビジュアライゼーション references/layout-system.md
フォーム設計 ユーザビリティ原則 バリデーション設計 → エラー状態設計 references/layout-system.md
LP・マーケティング ビジュアルヒエラルキー CTA設計 → コンバージョン最適化 references/layout-system.md

Step 2.2: 手法の組み合わせ判断

依頼内容が複数の種類にまたがる場合は、手法を組み合わせる。

判断基準:

  • スコープが広い(プロダクト全体) → Design Thinking から開始
  • スコープが狭い(特定画面) → コンポーネント設計から開始
  • 既存UIの改善 → ヒューリスティック評価から開始
  • アクセシビリティが要件に含まれる → 常にWCAG 2.1 AAチェックを併用

Phase 3: デザイン実行

選択した手法に基づきデザインを実行する。以下の要素を依頼に応じてカバーする。

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% アクセント(強調) CTAボタン / リンク / アクティブ状態

セマンティックカラー体系:

セマンティック名 用途 推奨HEX
Primary CTA、リンク、選択状態 #3B82F6
Secondary 二次アクション #6366F1
Success 成功、完了 #22C55E
Warning 注意、警告 #F59E0B
Error エラー、破壊的アクション #EF4444
Info 情報提供 #06B6D4
Neutral 50-950 テキスト、ボーダー、背景 #F9FAFB 〜 #030712

各カラーには明度スケール(50, 100, 200, ..., 800, 900, 950)を用意する。

コントラスト比(WCAG 2.1 AA):

  • 通常テキスト: 4.5:1以上
  • 大テキスト(18px太字 or 24px以上): 3:1以上
  • UIコンポーネント: 3:1以上

Step 3.3: タイポグラフィ設計

タイプスケール(Major Third 1.25倍を基本):

トークン名 サイズ 用途
text-xs 0.8rem (12.8px) キャプション、注釈
text-sm 0.889rem (14.2px) 補助テキスト、ラベル
text-base 1rem (16px) 本文テキスト
text-lg 1.25rem (20px) サブ見出し
text-xl 1.563rem (25px) セクション見出し
text-2xl 1.953rem (31.25px) ページ見出し
text-3xl 2.441rem (39.06px) ヒーロー見出し

行間・字間:

  • 本文: line-height: 1.6, letter-spacing: 0.01em
  • 見出し: line-height: 1.15, letter-spacing: -0.02em
  • キャプション: line-height: 1.5, letter-spacing: 0.03em
  • 段落幅: 1行あたり45〜75文字

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 で段階的にスタイルを追加する。

ブレークポイント:

名前 min-width 対象デバイス
base 0px モバイル(ポートレート)
sm 640px スマートフォン(ランドスケープ)
md 768px タブレット
lg 1024px デスクトップ
xl 1280px 大画面デスクトップ
2xl 1536px ワイドスクリーン

レスポンシブパターン:

  • モバイル: 1カラム、ハンバーガーメニュー、タブナビゲーション
  • タブレット: 2カラム、サイドバー折りたたみ
  • デスクトップ: 3カラム、常時表示サイドバー
  • タッチターゲット: 最低44x44px(Apple HIG)/ 48x48dp(Material Design)

Step 3.7: アクセシビリティチェック

WCAG 2.1 AAに準拠する。以下を確認する:

カテゴリ チェック項目
コントラスト テキスト 4.5:1以上、大テキスト 3:1以上、UI要素 3:1以上
キーボード 全機能がキーボード操作可能、フォーカス順序が論理的、フォーカスインジケーター 3:1以上
セマンティクス <nav>, <main>, <aside> 等のランドマーク使用、見出し階層が正しい
ARIA 可視テキストがない要素に aria-label、補足説明に aria-describedby
フォーム <label><input> の明示的関連付け、具体的なエラーメッセージ
画像 意味のある画像に alt テキスト、装飾画像は alt=""
動き prefers-reduced-motion の尊重

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 デザイン実装後のコードレビュー