D1: 画面コンセプト集

本書の目的と範囲

本書は 「全画面のミニ要件」ではなく「画面体験そのものの方向性 + 代表シーンの絵姿」 を扱う。下流のワイヤーフレーム・画面遷移図・全画面要件は、本書のコンセプトを判断基準にして設計者・エンジニアが起こす。

本書に書くもの	本書に書かないもの(降ろし先)
プロダクト全体の画面体験コンセプト(1段落)	個別画面の要件項目(→ D2 画面要件群)
体験原則 3-5 項目	全画面の網羅一覧・ID 採番(→ D2 画面要件群)
トーン&マナー方針(Figma ムードボード参照)	状態網羅・遷移網羅・バリデーション・エラー時挙動(→ D2 画面要件群)
代表シーン 2-3(最大5)	ハイファイデザイン・コンポーネント仕様・トークン(→ D3 以降)

サイズ感の規律: ビジネスサイドが現実に議論・合意できる規模に収める。代表シーンは 2-3 が標準、最大 5。これ以上に膨らんだら本書の目的から外れているサイン(全画面網羅型に逆戻りしていないかを確認する)。

inputする成果物

成果物のパス	内容
docs/D1.business-requirements/business-requirement-document.md	上流のBRD(事業戦略・KPI・フェーズ2境界 等を参照)
docs/D1.business-requirements/actor-list.md	上流のアクター一覧(代表シーンの主アクター ID の引用元)
docs/D1.business-requirements/product-requirement-document.md	上流のPRD(§提供価値・体験方針・§システム利用ユーザーと体験設計・§UI/UX方針 を参照)
docs/D1.business-requirements/user-story-list.md	上流のユーザーストーリー一覧(代表シーンが体現するストーリーの参照元)
docs/D1.business-requirements/domain-requirements/*.md	上流のドメイン要求仕様書群(代表シーンが該当する業務工程の参照元)
docs/D1.business-requirements/screen-concepts.md	既存の画面コンセプト集(更新・レビュー時のみ参照。新規作成時は未存在)

outputする成果物

成果物のパス	内容
docs/D1.business-requirements/screen-concepts.md	画面コンセプト集本体

使用するテンプレート

出力時は以下のテンプレートを読み込み、その章構成・書き方ヒントに従う。

テンプレートのパス	内容
.claude/skills/d1-screen-concepts/template.md	画面コンセプト集テンプレート(章構成・書き方ヒント)

外部成果物として Figma file(ムードボード/スタイルタイル + 代表シーン用ラフ)を併走させる。本書は Figma file へのリンクを含むが、Figma file 自体の作成は本スキルの責務外(後述「Figma との関係」参照)。

新規作成時の振る舞い

新規作成時(docs/D1.business-requirements/screen-concepts.md 未存在)は ユーザーへのヒアリングを行わず、上流成果物群と業界一般知識からコンセプト・原則・代表シーンを推定して直接生成する。

1. PRD §「提供価値・体験方針」と BRD §「事業戦略」「KPI」を読み、プロダクト全体の 画面体験コンセプト(1段落)を抽出する
2. PRD §「提供価値・体験方針」・§「UI/UX方針」・§「システム利用ユーザーと体験設計」 から、画面設計の判断軸として効く 体験原則 3-5 項目 を派生させる。各項目には上流 ID(DOM-COMMON-* / BRD KPI 等)への参照を付ける
3. PRD §「UI/UX方針 > デザインシステム・トーン&マナー」を参照し、トーン&マナー方針(数行 + Figma ムードボードリンク)を書く。具体ビジュアル設計は Figma 側、本書は方針宣言のみ
4. 代表シーンを 2-3 選定(下記「代表シーンの選定基準」参照)。各シーンに対して、場面(誰が・いつ・何のために)・体現したいコンセプト・期待する画面の雰囲気・関連上流 ID・Figma リンク を記述
5. Figma フレーム/ムードボードへのリンクは新規作成時には埋めない。各リンク欄には {{...URL}}【要確認】 を仮置きする
6. ID は SC-PR-<連番>(体験原則)/ SC-SCENE-<連番>(代表シーン) 形式(成果物略号=SC (Screen Concepts)、カテゴリ=PR / SCENE)。画面体験コンセプト宣言の段落自体には ID を付けない
7. アクター列にはアクター名と アクター一覧(./actor-list.md)の ID を併記(例: 営業職員(ACT-1) / 申込人(ACT-5))。複数アクターが共用するシーンは中黒区切り
8. 上流から確定できない値は推測で埋めず、要確認マーカーを残す
9. 受け入れ基準章は設けない(本書はビジネス合意のための議論材料であり、検収観点の網羅は本書の責務ではない)
10. 「本書について」章も設けない(ユーザーストーリー一覧以降の成果物の方針)

代表シーンの選定基準

「このプロダクトを一言で説明するならこの場面」と言える、コンセプトを最も色濃く体現する数シーンに絞る。以下のいずれかに該当するシーンを優先する:

• 顧客接点の核 — 信頼・体験品質に直結する場面(EC なら商品詳細・チェックアウト、ゲームならキャラ作成・初回プレイ、金融なら顧客の意思確定や同意取得 等)
• コア差別化領域の象徴 — 競合との差を絵で語れる場面(ドメイン定義書で「コア」と分類されたドメインの代表シーン)
• メイン業務動線で使用頻度が最も高い場面 — 現場の生産性・体験満足に直結する場面

以下は通常 代表シーンに含めない(D2 画面要件群で扱う):

• バックオフィス・管理画面・例外対応・監査基盤系(動作要件としては重要だがビジネスサイドの体験コンセプト議論には乗りにくい)
• ログイン・設定・エラー画面 等の標準的横断画面(デザイン慣習が確立している)

留意事項

• 議論可能なサイズに収める: 代表シーンは 2-3 が標準、最大 5。原則は 3-5。それ以上に増えそうなら、本書の目的から外れているサイン
• コンセプト宣言は実装手段に踏み込まない: 画面体験の方向性を語る段落であり、機能名・コンポーネント名・画面遷移の具体は書かない
• 体験原則は判断軸として使える具体性を持つ: 「使いやすくする」のような抽象は避ける。「入力時点での不備抑止」「判定根拠の追跡可能性」のような、後工程の設計判断で「この案は原則○○に反するから不採用」と言える具体性を持たせる
• 業界中立 + ユーザー視点の語彙: コンポーネント名・API 名・テーブル名・状態フラグ名 等のシステム実装語は混入させない。表示したい情報や操作したい行為は ユーザーが日常的に使う語彙 で書く
• 代表シーンは「絵で語るための言葉」を提供: シーンの記述は、デザイナーが Figma で絵を起こす際の判断材料になる粒度で書く。「項目網羅」ではなく「シーンの雰囲気・主役となる情報・期待する操作感」を伝える
• 上流とのトレーサビリティ: 体験原則・代表シーン それぞれに、上流 ID(DOM-COMMON-* / BRD KPI / *-BR-* / US-*)への参照を最低 1 つ紐付ける
• PRD §UI/UX方針 との整合: アクセシビリティ水準・対象デバイス/ブラウザ/プラットフォーム・エラー時体験方針 等は PRD §UI/UX方針 で宣言済み。本書は上位コンセプトとして整合させる(矛盾しないこと)
• フェーズ2 ラベルの付与: 将来段階導入の体験原則・代表シーンには [フェーズ2] ラベルを付与し、初期/将来の境界を明示する
• D2 画面要件群との棲み分け: 表示項目の網羅・状態網羅・遷移網羅・バリデーション・エラー時挙動・空状態・権限不足時 等は D2 へ
• D3 以降のデザインフェーズとの棲み分け: ハイファイデザイン・カラー設計・タイポグラフィ・コンポーネント仕様・デザイントークン・インタラクション仕様は D3 以降へ

Figma との関係

本書は Figma file への リンク参照 として機能する。Figma file 自体の作成・更新は ユーザーが手動で行う ことを前提とする。

本書が Figma 側に期待する成果物は以下に限定される(全画面ワイヤー網羅ではない):

Figma 側成果物	用途	紐付け先
ムードボード/スタイルタイル	トーン&マナー方針の視覚化	本書「トーン&マナー方針」のリンク
代表シーン用ラフ(各シーン1枚)	代表シーンの絵姿(中〜高忠実度可、コンセプト議論用)	各代表シーンの Figma リンク

これによりビジネス合意フェーズの Figma 投資が現実的な量(ムードボード1 + 代表シーン2-3)に収まる。全画面ワイヤーフレームは D2 画面要件群の責務であり、本書段階では作成しない。

Figma MCP ツールが利用可能な環境で ユーザーから明示指示があった場合に限り、use_figma / create_new_file 等で初期ラフを生成してもよい。ただしビジネス側の意図反映は人手の方が確実なため、自発的な Figma ファイル生成は行わない。

Figma リンク先の読み取り(レビュー・更新時)

Figma MCP ツールが利用可能な環境では、本書のレビュー・更新時に リンク先を実際に取得して本文記述と照合する。本書は Figma と対で読まれる文書であり、テキストだけを読んで整合を判断しない。

取得の条件: 対象リンクが実 URL(【要確認】 が外れている)であり、かつ node-id を含む場合に限り取得する。仮置きのままのリンク・node-id を持たないファイル全体 URL は取得せず、後者はフレーム単位の URL をユーザーに求める。新規作成時はリンクが全て仮置きのため、取得は発生しない。

使うツール:

ツール	用途
get_screenshot	既定。絵姿の確認はこれで足りる
get_metadata	シーン内の構成要素を数える必要がある場合のみ
get_variable_defs	本書では使わない(色・タイポの具体値は D3 の責務)
get_design_context	本書では使わない(design-to-code 用であり D1 の抽象度を超える)

照合の観点: トーン&マナー方針の宣言文とムードボード/スタイルタイルが同じ方向を向いているか。各代表シーンの「期待する画面の雰囲気」とラフの絵姿が一致しているか。本文が言及していない主要素がラフに描かれていないか(逆も同様)。

齟齬を見つけた場合の扱い: どちらが正かを自己判断せず、齟齬の内容をユーザーに指摘するに留める。Figma file は人手管理であり、本書側を Figma に合わせて書き換える・Figma を本書に合わせて編集する のいずれも自発的には行わない。

転記の禁止: 取得したビジュアルから、カラーコード・フォント名・余白値・コンポーネント名 等の具体値を本書に書き写さない。これらは D3 以降の責務であり、Figma を見たことを理由に本書の抽象度を下げない。

完成時のセルフチェック

執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。

• 画面体験のコンセプト が1段落で明確に宣言されているか(PRD §「提供価値・体験方針」と矛盾しない)
• 体験原則 が 3-5 項目で、各原則が「判断軸として使える具体性」を持っているか(抽象的すぎる原則は不可)
• 各体験原則に上流 ID(DOM-COMMON-* / BRD KPI / 等)への参照が紐付いているか
• トーン&マナー方針 が宣言され、Figma ムードボード/スタイルタイルへのリンク欄が用意されているか
• 代表シーン が 2-3(最大 5)であり、過剰に増えていないか
• 各代表シーンに 場面(誰が・いつ・何のために)・体現したいコンセプト・期待する画面の雰囲気・関連上流 ID・Figma リンク が記載されているか
• 代表シーンの選定がビジネスサイドが議論したくなる粒度(顧客接点・コア差別化・メイン業務動線)になっているか(バックオフィス・管理画面・例外対応・ログイン/設定 等が紛れていないか)
• 「本書について」「受け入れ基準」等の章が 置かれていない か
• システム実装語(コンポーネント名・API 名・テーブル名・状態フラグ名 等)が混入していないか
• D2 領域(表示項目網羅・状態網羅・遷移網羅・バリデーション 等)が混入していないか
• D3 以降のハイファイデザイン要素(カラー・タイポ・トークン・コンポーネント仕様)が混入していないか
• PRD §UI/UX方針 と矛盾していないか
• フェーズ2 該当の原則・シーンに [フェーズ2] ラベルが付与されているか
• ID が SC-PR-<連番> / SC-SCENE-<連番> 形式になっているか
• Figma URL に 【要確認】 が残っている場合、それが意図的な仮置きか(初期はマーカー残置が正常)
• {{ や XXX のプレースホルダが残っていないか(Figma URL を除く)

下流への伝搬関係

作成・更新時は以下の下流成果物との整合を意識する:

下流成果物	画面コンセプト集から何を引く
画面要件群(D2)	体験原則を全画面の設計判断軸として継承。代表シーンの方向性を念頭に置きつつ、全画面の正式な要件項目を網羅展開
ワイヤーフレーム・画面遷移図(D2-D3)	体験原則・代表シーンの雰囲気を全画面のワイヤーに展開する起点
デザインカンプ・デザインシステム(D3 以降)	トーン&マナー方針・代表シーンのハイファイ化の起点。デザイン会社への発注ブリーフとしても機能