Run any Skill in Manus with one click

web-app-designer

Stars1

Forks0

UpdatedJuly 8, 2026 at 20:34

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

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

CAPHTECH

CAPHTECH/claude-marketplace

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Web and Digital Interface DesignersComputer and Mathematical Occupations·SOC 15-1255

File Explorer

3 files

SKILL.md

readonly

More from this repository

same repository

design-system-builder

CAPHTECH/claude-marketplace

デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）からDesign Tokens・コンポーネント体系・ガバナンスまでを一貫して設計する。思考フレームワーク（Double Diamond・Atomic Design・Design Tokens 3層）の適用、暗黙的デザイン判断の形式知化（DDR/QOC/RFC）、UIインベントリ収集（手動+MCP自動化）を統合する。ゼロから体系的に構築する用途向け。既存の単発UIから再利用可能な構造を抽出するにはrelational-design-pluginのdesign-system-backflowスキルを使用すること。Use when: 「デザインシステムを構築して」「デザインシステムを設計して」「デザイントークンを定義して」「デザイン原則を策定して」「UIインベントリを作って」「デザインガバナンスを設計して」「デザイン判断を記録して」と言われた時。

2026-07-081

mobile-app-designer

CAPHTECH/claude-marketplace

iOS/Androidモバイルアプリのデザインを体系的に行うスキル。Apple HIG・Material Design 3などプラットフォームガイドラインに準拠し、ナビゲーション・レイアウト・コンポーネント・モーション・アクセシビリティを適切に設計する。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「モバイルアプリをデザインして」「iOSアプリのUIを設計して」「Androidアプリの画面を作って」「モバイルのナビゲーションを設計して」「タッチUIを改善して」「アプリのアクセシビリティを対応して」と言われた時。

2026-07-081

design-retract

CAPHTECH/claude-marketplace

Use this skill when a design assumption, user segment, business goal, constraint, or product requirement has changed and you need to analyze which design hypotheses, decisions, artifacts, copy, or components should be retracted or revised. Requires a Relational Design trace session with recorded observations/relations/hypotheses/decisions to analyze against — not a general "redo this design" request.

2026-07-081

design-review

CAPHTECH/claude-marketplace

Use this skill to critique an existing UI, frontend implementation, wireframe, flow, or visual design through Relational Design relations: user state, business intent, action risk, trust, information density, reversibility, accessibility, and implementation constraints. This is a relation-based critique, not a general design-methodology review — for platform-guideline or design-system compliance review, use design-plugin instead.

2026-07-081

design-system-backflow

CAPHTECH/claude-marketplace

Use this skill after creating or reviewing a design artifact to extract reusable design-system knowledge: semantic tokens, components, variants, interaction rules, copy patterns, accessibility constraints, and governance notes. This only backflows structure out of an artifact that already exists — to build or govern a design system from scratch (Design Tokens layers, Atomic Design, DDR/QOC/RFC, UI inventory), use design-plugin's design-system-builder instead.

2026-07-081

design-trace

CAPHTECH/claude-marketplace

Use this skill for UI/UX, frontend visual design, product flow, landing page, dashboard, component, or design-system-aware work where design reasoning should be traceable, isolable, and retractable. It orchestrates context reading, relation mapping, hypothesis generation, artifact design, critique, and trace archival. This is about the reasoning process, not visual output methodology — for HIG/Material Design/Atomic Design-driven UI or design-system construction without a trace/retraction workflow, use design-plugin's web-app-designer, mobile-app-designer, or design-system-builder instead.

2026-07-081

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