prompt-engineering-ui

UI 生成のためのプロンプトエンジニアリング

LLM にデザインの意図を伝える技術を習得しましょう。このスキルでは、一貫性のある高品質なユーザーインターフェースの生成に特化して最適化されたプロンプトパターンを扱います。

---

このスキルを使用する場面

• 一貫性のある UI コンポーネントを生成するプロンプトを書く
• デザインの意図を AI システムに正確に説明する
• デザインシステム用の再利用可能なプロンプトテンプレートを構築する
• 構造化されたフィードバックを使って UI 生成を反復する
• UI パターン用の少数ショット例を作成する
• 一貫性のない UI 生成結果をデバッグする

---

UI プロンプトの課題

UI 生成が特に難しいのは、次の要素が必要だからです。

1. 視覚的な精度 - 正確な間隔、色、タイポグラフィ
2. 動作の仕様 - インタラクション、状態、アニメーション
3. コンテキストとの整合性 - デザインシステムとの適合
4. アクセシビリティへの準拠 - WCAG、ARIA、キーボード操作
5. レスポンシブ対応 - 複数のブレークポイント、デバイス
6. コード品質 - クリーンで保守しやすい出力

UI は視覚的、動作的、技術的な要素を同時に持つため、一般的なプロンプト手法ではうまくいかないことがよくあります。

---

主なプロンプトパターン

パターン 1：コンポーネント契約

コンポーネントを、入力と出力の仕様を明示した契約として定義します。

## Component Contract: DataTable

### Purpose
Display tabular data with sorting, filtering, and pagination.

### Props (Inputs)
| Prop | Type | Required | Default | Description |
|------|------|----------|---------|-------------|
| data | T[] | Yes | - | Array of data objects |
| columns | ColumnDef[] | Yes | - | Column configuration |
| pageSize | number | No | 10 | Rows per page |
| sortable | boolean | No | true | Enable column sorting |
| filterable | boolean | No | false | Show filter inputs |

### Visual Specification
- **Container**: bg-white rounded-lg shadow-sm border border-gray-200
- **Header row**: bg-gray-50 text-gray-600 text-sm font-medium
- **Data rows**: hover:bg-gray-50 border-b border-gray-100
- **Typography**: Font-sans, body text 14px, headers 12px uppercase
- **Spacing**: Cell padding 12px horizontal, 8px vertical

### States
1. **Loading**: Skeleton rows with pulse animation
2. **Empty**: Centered message with icon
3. **Error**: Red border, error message below
4. **Selected**: bg-blue-50, left border accent

### Accessibility Requirements
- role="table" on container
- Sortable columns announce sort direction
- Focus visible on all interactive elements
- Keyboard navigation: Tab through headers, Enter to sort

### Output Format
React TypeScript component using Tailwind CSS.
Include JSDoc comments and prop types.

効果がある理由：

• 明示的な契約によって曖昧さがなくなります
• 視覚仕様には実際の CSS 値を使用します
• 状態を指定することで、不完全な実装を防げます
• アクセシビリティは必須要件です

---

パターン 2：デザイントークンの埋め込み

一貫性を保つため、デザイントークンをプロンプトに直接埋め込みます。

Generate a Card component following these design tokens:

## Tokens
```json
{
  "spacing": {
    "xs": "4px",
    "sm": "8px",
    "md": "16px",
    "lg": "24px",
    "xl": "32px"
  },
  "colors": {
    "surface": {
      "primary": "#FFFFFF",
      "secondary": "#F9FAFB",
      "elevated": "#FFFFFF"
    },
    "border": {
      "subtle": "#E5E7EB",
      "default": "#D1D5DB"
    },
    "shadow": {
      "sm": "0 1px 2px rgba(0,0,0,0.05)",
      "md": "0 4px 6px rgba(0,0,0,0.1)"
    }
  },
  "radius": {
    "sm": "4px",
    "md": "8px",
    "lg": "12px"
  }
}

要件

• カードの背景には surface.elevated を使用する
• 枠線には border.subtle を使用する
• パディングには spacing.lg を使用する
• 角丸には radius.lg を使用する
• シャドウには shadow.md を使用する

可能な場合は、これらのトークンを Tailwind クラスに対応付けます。

**Token Mapping Strategy**:
```typescript
// Prompt can include this mapping guide
const tokenToTailwind = {
  "spacing.xs": "p-1",
  "spacing.sm": "p-2",
  "spacing.md": "p-4",
  "spacing.lg": "p-6",
  "spacing.xl": "p-8",
  "colors.surface.primary": "bg-white",
  "colors.surface.secondary": "bg-gray-50",
  "colors.border.subtle": "border-gray-200",
  "radius.lg": "rounded-xl",
  "shadow.md": "shadow-md",
};

---

パターン 3：視覚的な参照の連鎖

抽象的な説明から具体的な説明へと、視覚的な説明を連鎖させます。

## Component: Hero Section

### Mood (Abstract)
Confident, minimal, focused. The user should feel capable and unintimidated.

### Aesthetic (Semi-Abstract)
- Clean sans-serif typography
- Generous whitespace (40% of viewport)
- Single accent color for CTAs
- Photography: abstract, not literal

### Visual Details (Concrete)
- **Layout**: Centered, max-width 1200px, py-24
- **Headline**: text-5xl font-bold tracking-tight text-gray-900
- **Subheadline**: text-xl text-gray-600 max-w-2xl mx-auto mt-6
- **CTA Group**: mt-10 flex gap-4 justify-center
- **Primary CTA**: bg-indigo-600 hover:bg-indigo-700 text-white px-8 py-4 rounded-lg
- **Secondary CTA**: border border-gray-300 text-gray-700 px-8 py-4 rounded-lg

### Content
- Headline: "Build interfaces that inspire"
- Subheadline: "The design system that empowers creators to ship beautiful products faster."
- Primary CTA: "Get Started"
- Secondary CTA: "Learn More"

連鎖の構成：

Mood → Aesthetic → Visual Details → Content
 ↓         ↓            ↓            ↓
Emotion   Style     CSS Values    Text

このパターンは、意図から実装へと段階的に進められるため効果的です。

---

パターン 4：状態マシンの仕様

コンポーネントの状態を状態マシンとして定義します。

## Button Component States

### State Machine

idle → hover → pressed → idle ↓ ↓ ↓ focus focus focus ↓ ↓ ↓ disabled (terminal) loading (blocks all transitions)

### State Definitions

| State | Visual Treatment | Tailwind Classes |
|-------|------------------|------------------|
| idle | Default appearance | bg-blue-600 text-white |
| hover | Slightly darker | hover:bg-blue-700 |
| focus | Ring indicator | focus:ring-2 focus:ring-blue-500 focus:ring-offset-2 |
| pressed | Darker, slight scale | active:bg-blue-800 active:scale-[0.98] |
| disabled | Muted, no pointer | disabled:bg-gray-300 disabled:cursor-not-allowed |
| loading | Spinner, no text | Spinner SVG, opacity-50, pointer-events-none |

### Transitions
- All transitions: `transition-all duration-150 ease-in-out`
- Scale transitions: spring-like (use framer-motion if available)

### Implementation Notes
- Use `<button>` element, never `<div>`
- disabled state must be set via HTML attribute
- loading should set aria-busy="true"

---

パターン 5：制約優先のプロンプト

解決策の範囲を絞るため、最初に制約を提示します。

## Constraints (Non-Negotiable)

### Technical Constraints
- React 18+ with TypeScript strict mode
- Tailwind CSS only (no CSS-in-JS)
- No external component libraries
- Bundle size: component must be < 5KB gzipped

### Design Constraints
- Must pass WCAG 2.1 AA
- Must work without JavaScript (progressive enhancement)
- Must support RTL layouts
- Color contrast ratio >= 4.5:1

### Browser Support
- Chrome 90+, Firefox 88+, Safari 14+, Edge 90+
- No IE11 support required

### Performance Constraints
- First paint < 100ms
- No layout shift on load
- Images must be lazy-loaded

---

## Now, generate a Modal component that satisfies all constraints above.

制約を先に提示する理由：

• 無効な解決策をすぐに排除できます
• 生成の対象を実現可能なアプローチに絞れます
• レビューが容易になります（チェックリストで検証できます）
• 要件に反する「創造的な」解決策を防げます

---

反復的な改善パターン

フィードバックループの手順

効果的な反復のために、フィードバックを構成します。

## Iteration 1 Feedback

### What Works
- Component structure is correct
- Props interface is well-typed
- Basic styling matches tokens

### What Needs Fixing

#### Critical (Must Fix)
1. **Missing keyboard navigation**
   - Current: Only mouse interaction works
   - Required: Arrow keys to navigate, Enter to select
   - Reference: WAI-ARIA Listbox pattern

2. **Color contrast failure**
   - Current: text-gray-400 on bg-white (ratio 2.5:1)
   - Required: Minimum 4.5:1 for body text
   - Fix: Use text-gray-600 (ratio 5.7:1)

#### Important (Should Fix)
3. **Animation too fast**
   - Current: duration-75
   - Recommended: duration-150 for better perception

#### Nice to Have
4. Consider adding subtle shadow on hover

### Revised Requirements
Regenerate the component addressing Critical and Important items.

---

差分ベースの改善

全体を再生成するのではなく、具体的な変更を依頼します。

## Current Component

```tsx
<button className="bg-blue-500 text-white px-4 py-2 rounded">
  Click me
</button>

変更依頼

1. ホバー状態を追加：ホバー時に bg-blue-600
2. フォーカスリングを追加：フォーカス時に ring-2 ring-blue-500 ring-offset-2
3. 無効状態を追加：プロパティと視覚的な処理を追加
4. 読み込み状態を追加：スピナーと loading プロパティを追加

出力形式

変更箇所を説明するインラインコメントを付け、変更後のコードのみを表示します。

---

### The A/B Variant Request

Request multiple options for comparison:

```markdown
Generate 3 variants of a Card component:

## Variant A: Minimal
- No shadow
- Hairline border only
- Maximum whitespace

## Variant B: Elevated
- Pronounced shadow
- No visible border
- Subtle hover lift effect

## Variant C: Outlined
- Thick left accent border
- Light background fill
- Category color coding

## Common Requirements (All Variants)
- Same prop interface
- Same content structure
- Same responsive behavior
- Same accessibility

## Output
Provide all three variants as separate components.
Include a brief rationale for when to use each.

---

UI の少数ショット例

例：ボタンのバリエーション

## Few-Shot Examples: Button Component

### Example 1: Primary Button
Input: Primary action button with "Submit" text
Output:
```tsx
<button className="bg-indigo-600 hover:bg-indigo-700 text-white font-medium py-2.5 px-5 rounded-lg transition-colors focus:ring-2 focus:ring-indigo-500 focus:ring-offset-2">
  Submit
</button>

例 2：セカンダリボタン

入力：テキストが「キャンセル」のセカンダリアクションボタン 出力：

<button className="bg-white hover:bg-gray-50 text-gray-700 font-medium py-2.5 px-5 rounded-lg border border-gray-300 transition-colors focus:ring-2 focus:ring-gray-500 focus:ring-offset-2">
  Cancel
</button>

例 3：危険操作ボタン

入力：テキストが「削除」の破壊的な操作ボタン 出力：

<button className="bg-red-600 hover:bg-red-700 text-white font-medium py-2.5 px-5 rounded-lg transition-colors focus:ring-2 focus:ring-red-500 focus:ring-offset-2">
  Delete
</button>

---

次を生成します：「詳細を見る」というテキストのゴーストボタン

**Pattern Recognition**:
- Consistent class structure across examples
- Clear input-output mapping
- Similar complexity level
- Demonstrates the pattern, not just the answer

---

## Prompt Templates

### Template: Component Generation

```markdown
# Generate: {ComponentName}

## Context
Project: {ProjectDescription}
Design System: {DesignSystemName}
Framework: React + TypeScript + Tailwind

## Design Tokens
{DesignTokensJSON}

## Component Specification
Purpose: {ComponentPurpose}
Props: {PropsTable}
States: {StatesList}
Variants: {VariantsList}

## Visual Requirements
Layout: {LayoutDescription}
Typography: {TypographySpecs}
Colors: {ColorSpecs}
Spacing: {SpacingSpecs}

## Behavior
Interactions: {InteractionList}
Animations: {AnimationSpecs}
Accessibility: {A11yRequirements}

## Constraints
{ConstraintsList}

## Output
Provide production-ready React TypeScript component.
Include prop types, JSDoc comments, and usage example.

テンプレート：デザインレビュー

# Review: {ComponentCode}

## Review Criteria

### Design Fidelity
- Does it match the design tokens?
- Is spacing consistent?
- Are colors correct?

### Accessibility
- Keyboard navigable?
- Screen reader friendly?
- Color contrast sufficient?

### Code Quality
- Types correct?
- Props well-named?
- Logic clear?

### Performance
- Unnecessary re-renders?
- Bundle size reasonable?
- Animations performant?

## Output Format
For each criterion, provide:
- Score (1-5)
- Issues found
- Specific fixes needed

---

UI プロンプトのアンチパターン

1. 曖昧な美的表現

悪い例：「モダンですっきりした見た目にする」 良い例：「Inter フォント、基本サイズ 16px、行の高さ 1.5、垂直方向のリズム 24px を使用する」

2. 状態の指定漏れ

悪い例：「ボタンを作成する」 良い例：「通常、ホバー、フォーカス、アクティブ、無効、読み込みの各状態を持つボタンを作成する」

3. デザインシステムのコンテキストがない

悪い例：「素敵な青を使う」 良い例：「デザイントークンのプライマリカラー（#4F46E5）を使う」

4. アクセシビリティへの配慮が暗黙的

悪い例：「アクセシブルにする」 良い例：「ARIA ラベル、WAI-ARIA Listbox パターンに準拠したキーボード操作、フォーカスインジケーターを含める」

5. 一度で完成するという期待

悪い例：最初の試行で完璧な出力を期待する 良い例：構造化されたフィードバックを用いて、2～3回の改善反復を計画する

---

クイックリファレンス

状況	使用するパターン
新しいコンポーネント	コンポーネントコントラクト
一貫性の確保	デザイントークンの注入
視覚的な意図の説明	ビジュアルリファレンスチェーン
複雑なインタラクション	ステートマシン仕様
手戻りの回避	制約優先のプロンプト作成
出力の改善	フィードバックループプロトコル
軽微な調整	差分ベースの改善
選択肢の検討	A/B バリアントのリクエスト

---

他のスキルとの連携

このスキルは、以下と組み合わせると効果的です。

• agent-orchestration/ui-agent-patterns - エージェントへの委任に使うプロンプトパターン
• context-management/design-system-context - プロンプトへのトークンの読み込み
• llm-application-dev/prompt-engineering-patterns - プロンプト作成の一般的な基礎
• design-mastery/design-principles - 説明に使う視覚的な語彙

---

「正確なプロンプトは、正確な思考です。意図が明確であれば、UI はそこから生まれます。」