npx claudepluginhub caphtech/claude-marketplace --plugin design-pluginWant just this skill?
Then install: npx claudepluginhub u/[userId]/[slug]
Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。
This skill uses the workspace's default tool permissions.
references/design-methods.mdreferences/layout-system.mdWeb 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 | デザイン実装後のコードレビュー |
Similar Skills
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.