Screen design

画面設計

目的

要件定義で整理されたユーザーストーリーを、実装可能な画面仕様へ落とし込む。 画面一覧・遷移図・ワイヤーフレーム・項目定義・状態定義を一貫した形式で作成し、開発チームが迷わず実装できる設計書を成果物とする。

使うタイミング

• 要件定義完了後、アーキテクチャ設計・詳細設計の前
• 新規画面追加時や既存画面の大幅改修時
• フロントエンド実装前にUI仕様を確定したいとき
• 画面設計書のレビュー依頼を受けたとき

進め方

1. ユーザーストーリーの棚卸し 要件定義書のユーザーストーリーを一覧化し、「誰が」「何をする」画面が必要かを抽出する。 画面IDを SCR-001 形式で採番する。

2. 画面一覧の作成 画面ID・画面名・対応するユーザーストーリー・担当ロール・優先度をまとめた表を作成する。

3. 画面遷移図の作成 MermaidのflowchartまたはstateDiagramで遷移を可視化する。 条件分岐（権限・認証状態・データ有無）も明記する。

   flowchart TD
     A[ログイン画面 SCR-001] -->|認証成功| B[ダッシュボード SCR-002]
     A -->|認証失敗| A
     B -->|新規作成クリック| C[登録フォーム SCR-003]
     C -->|保存成功| D[詳細画面 SCR-004]
     C -->|キャンセル| B
     D -->|編集クリック| E[編集フォーム SCR-005]
     E -->|保存| D
   

4. ワイヤーフレームの作成 テキスト/ASCIIで各画面のレイアウトを表現する。 コンポーネントの配置・優先度・サイズ感を伝えることが目的であり、デザインの精度は問わない。

   +----------------------------------+
   | [Logo]        [ユーザー名] [ログアウト] |
   +----------------------------------+
   | [検索バー________________] [検索]  |
   +----------------------------------+
   | ■ 件名     担当者  期日    ステータス |
   | □ タスクA   山田   06/20   進行中   |
   | □ タスクB   佐藤   06/25   未着手   |
   +----------------------------------+
   | [新規作成]           [< 1/5 >]   |
   +----------------------------------+
   

5. 画面ごとの項目定義 各画面について表示項目・入力項目・アクションを定義する（後掲テンプレート参照）。 入力項目は型・必須/任意・バリデーションルール・エラーメッセージを必ず記載する。

6. 状態の網羅 全画面で以下5状態を定義する。未定義の場合は「N/A（理由）」と明記して省略可。

   • 空状態(empty): データが0件のとき何を表示するか
   • ローディング: データ取得中のインジケーター・スケルトン方針
   • エラー: API失敗・ネットワーク断時のメッセージとリカバリーアクション
   • 成功: 操作完了時のフィードバック（トースト・ダイアログ・遷移）
   • 権限なし: 閲覧・操作権限がないユーザーへの表示

7. デザイン原則の確認

   • 一貫性: ボタン・フォーム・カードなどはコンポーネントを再利用し、画面ごとに独自UIを作らない
   • フィードバック: 全操作に対して結果を明示（成功トースト・エラーメッセージ・ローディングスピナー）
   • アクセシビリティ: コントラスト比4.5:1以上、キーボード操作可能、画像にalt属性
   • レスポンシブ方針: ブレークポイント（例: sp<768px / tab<1024px / pc≥1024px）と各サイズでの挙動を明記

8. レビューとチェックリスト確認 後掲チェックリストで抜け漏れを確認し、設計書を完成させる。

成果物テンプレート

# 画面設計書

## 画面一覧

| 画面ID  | 画面名       | 対応ストーリー | 担当ロール | 優先度 |
|---------|------------|------------|--------|------|
| SCR-001 | ログイン画面  | US-001     | 全ユーザー | 高   |
| SCR-002 | ダッシュボード | US-002     | 一般・管理者 | 高  |

## 画面遷移図

```mermaid
flowchart TD
  SCR-001 -->|認証成功| SCR-002

画面定義: [SCR-XXX] 画面名

目的: この画面でユーザーが達成することを1文で記述

遷移元: SCR-XXX（〇〇操作時） 遷移先: SCR-XXX（〇〇操作時）

レイアウト（ワイヤーフレーム）

+---------------------------+
| ヘッダー                   |
+---------------------------+
| メインコンテンツ             |
+---------------------------+
| フッター                   |
+---------------------------+

表示項目

項目名	データ元（API/Store）	形式・備考
ユーザー名	GET /users/me	文字列

入力項目

項目名	型	必須	バリデーション	エラーメッセージ
メールアドレス	text	必須	RFC5322形式	有効なメールアドレスを入力してください
パスワード	password	必須	8文字以上	パスワードは8文字以上で入力してください

アクション

ラベル	種別	遷移先/処理	非活性条件
ログイン	ボタン（primary）	POST /auth → SCR-002	入力エラーあり
キャンセル	ボタン（ghost）	SCR-001に留まる	なし

状態別表示

状態	表示内容
空状態(empty)	N/A（認証画面のため）
ローディング	ボタンをスピナーに切り替え、フォームをdisable
エラー	フォーム下部にエラーメッセージを赤テキストで表示
成功	ダッシュボードへ遷移
権限なし	N/A（認証前のため）

## チェックリスト

- [ ] 全ユーザーストーリーに対応する画面が存在する
- [ ] 全画面に画面IDが採番されている
- [ ] 画面遷移図に全画面が含まれ、孤立画面がない
- [ ] 全入力項目にバリデーションルールとエラーメッセージが定義されている
- [ ] 全画面で5状態（空/ローディング/エラー/成功/権限なし）が定義されている
- [ ] 表示項目のデータ出所（APIエンドポイントまたはStore）が明記されている
- [ ] コンポーネントの再利用方針が記載されている
- [ ] アクセシビリティ要件が記載されている
- [ ] レスポンシブ対応のブレークポイントと挙動が記載されている
- [ ] 設計書がアーキテクチャ設計と整合している

## アンチパターン

- **ハッピーパスしか設計しない**: エラー状態・空状態を後回しにすると実装時に仕様が曖昧になる。必ず全5状態を先に定義する
- **エラーメッセージ未定義**: 「エラーを表示する」だけでは実装者がコピーを考えることになる。具体的な文言まで設計書に含める
- **画面ごとにUIパターンがバラバラ**: 同種の操作に異なるUIパターンを使うとユーザーの混乱を招く。コンポーネント一覧を先に定義し再利用を徹底する
- **データの出所が未定**: 「ユーザー名を表示」と書いても取得元APIが不明だと実装できない。表示項目には必ずデータ元を明記する
- **遷移条件の未定義**: 「詳細画面へ遷移する」だけでは権限・データ状態による分岐が漏れる。条件分岐を遷移図と定義表の両方に記載する
- **アクセシビリティの後回し**: 実装後の対応は工数が大きい。コントラスト・キーボード操作・alt属性は設計段階で要件化する

## モデル委譲ガイド

共通原則は [[orchestration]] を参照。

| 作業 | 担当モデル | 理由 |
|-----|----------|------|
| UX上の重要判断（画面統廃合・情報設計・ナビゲーション構造） | 司令塔（メインモデル） | ビジネス要件とUX原則の両立が必要な判断 |
| 複雑な画面のワイヤーフレームドラフト（複数ロール・多状態） | Opus | 多くの制約と状態を同時に考慮した設計が必要 |
| 画面項目定義表の作成・バリデーション一覧の整理 | Sonnet | 定型フォーマットへの落とし込みは中規模モデルで十分 |
| Mermaid遷移図の作成・更新 | Sonnet | 図の構造変換は定型作業 |
| 定型画面（CRUD一覧・詳細・編集フォーム）のドラフト | Sonnet | パターンが確立された画面は高度な判断不要 |
| 既存画面の棚卸し・画面一覧への整理 | Haiku | 既存情報の転記・集約作業 |

## 関連スキル

- [[requirements-definition]] — ユーザーストーリーの元となる要件定義
- [[architecture-design]] — 画面設計と整合するフロントエンド構成の設計
- [[detailed-design]] — 画面設計を受けてコンポーネント・API仕様を詳細化
- [[implementation]] — 画面設計書を元にした実装
- [[task-breakdown]] — 画面単位でのタスク分解
- [[non-functional-requirements]] — アクセシビリティ・パフォーマンス要件の定義
- [[orchestration]] — マルチエージェント委譲の共通原則