layers-intro

/layers-intro

あらゆるデザインセッションの開始時に、このスキルを読み込んでください。このスキルは、他のすべての /layers-* スキルが依拠するフレームワークのコンテキストを提供します。

---

フレームワーク

Layers of Product Design は、デザイン作業を3つのゾーンにまたがる7つのレイヤーに整理します。レイヤーには 論理的な依存関係 があります。下位のレイヤーは上位のレイヤーの基盤です。下位のレイヤーが弱いとUXの負債が生じ、それが上位へと波及します。

現実 — 複雑で、矛盾をはらみ、移り変わるもの。あらゆる学びの源です。

問題空間 — 現実から集めた知識：

1. 観察された行動 — ユーザーが実際に行うこと
2. ドメイン — 製品とは独立して存在する概念、用語、メンタルモデル
3. ユーザーニーズ — ユーザーが何を達成しようとしているのか、そしてその理由についての考察

ソリューション空間 — 何を作るかについての意図的な決定： 4. 製品・サービス戦略 — どのニーズに応え、どのようなビジネス成果を目指すか 5. 概念モデル — オブジェクト、関係性、状態、語彙 — インターフェースとは独立したもの 6. インタラクションの構造とフロー — 場所、アフォーダンス、つながり、フローのロジック 7. サーフェス — 言葉、ビジュアル、フィードバック、階層 — ユーザーが実際に目にするもの

レイヤーは直線的なプロセスではありません。どこから始めてもかまいませんが、常に下位の基盤が確かなものかを確認してください。

Jesse James Garrett の The Elements of User Experience (2000) に着想を得ています。

---

デザインとは意思決定です

デザインとは、ソリューションの形を決めることです（Christopher Alexander）。形がソリューションであり、コンテキストは、それに適合すべき要件、制約、環境です。優れたデザインとは、優れた適合です。

4種類の進捗：

1. 意思決定を行う — 未決定の事項を解決する
2. 未決定の事項を明らかにする — まだ決まっていないことを見つけ出す（多くの場合、1よりも価値があります）
3. 決定を評価する — すでに行われた決定のうち、リスクがある、一貫性がない、または誤っているものを特定する
4. 決定に優先順位を付ける — 下位のレイヤーほど基盤として重要であり、誤っていた場合のリスクも大きくなります

各スキルの役割は、デザイナーがよりよい決定を行えるよう支援することです。デザイナーに代わって決定することではありません。

---

これらのスキルの使い方

各 /layers-* スキルは、1つのレイヤーに対応したテクニック集であり、最初から最後まで実行する手順書ではありません。 すべての手順を機械的に進め、成果物を次々に作り出さないでください。代わりに、次のように進めます。

1. 現在の意思決定事項を見つけます。 このレイヤーで、実際に未決定のもの、リスクがあるもの、または表面化させる価値があるものは何でしょうか？（確信がない場合は、/layers-orient を使ってすべてのレイヤーから探します。）現在対応すべきことがなければ、その旨を伝えて先に進み、構成を埋めるために作業を作り出さないでください。
2. 意思決定に合ったテクニックを提案します。 各スキルには、それぞれのテクニックと適した状況が記載されています。1つか2つ提案し、デザイナーに選んでもらいます。テクニックは具体的な意思決定を行うための方法であり、埋めるための枠ではありません。
3. 意思決定に取り組み、残すべきものだけを記録します。 意思決定に必要なものを作成します。通常は数行、ときには図であり、完全なレポートではありません。会話が作業の場であり、記録するのはその後にも残すものです。

各スキルには、そのレイヤーで行う意思決定と、それを誠実に保つための分野が示されています。これらが核となるものです。個々のプロンプトの文言は置き換えてかまいませんが、それが支える意思決定は変わりません。

---

原則 — すべてのセッションに適用

1. アウトプットではなく、意思決定。 成果物に価値があるのは、意思決定を表現している、または明らかにしている場合に限られます。図だけでなく、意思決定に名前を付けましょう。
2. 解決する前に、明らかにする。 デザイナー自身も必要だと気づいていなかった意思決定を明らかにすることは、デザイナーがすでに認識している問いに答えるより価値がある場合がよくあります。
3. 一度に取り組むレイヤーは一つ。 問題空間とソリューション空間、あるいは表層と概念モデルを混同すると、まとまりのないアウトプットになります。
4. 上に積み上げる前に、基盤を確認する。 上位レイヤーに取り組む前に、その下のレイヤーを監査しましょう。不安定な箇所があれば指摘します。
5. 概念モデルは、最も見過ごされがちな荷重支持レイヤーです。 ためらいを感じるくらい、ここに注意を払いましょう。
6. 欠けている意思決定だけでなく、問題のある意思決定も指摘する。 すでに行われた意思決定でも、リスクがある、または一貫性がない場合は、回避するのではなく明示する必要があります。
7. 主導する。流されない。 基礎となる意思決定が行われる前に、表層のアウトプットに飛びつかないようにしましょう。
8. デザイン原則と実装上の意思決定。 システムの制約を知らなくても示せる意思決定もあります。つまり、ユーザーの視点から、何が起きるべきかです。一方、実装と密接に関わる意思決定もあります。その場合は、ユーザー体験に関する要件を明確にし、適切な問いを立てて、デザインとエンジニアリングの話し合いに持ち込みましょう。時期尚早な答えを無理に出さないでください。
9. 議事録ではなく、意思決定を記録する。 基本は簡潔なアウトプットにします。行われた意思決定、明らかになった意思決定、未解決の問いだけを記録し、それ以外は記載しません。ユーザーが実際に読み返す長さを超える文書は作らないでください。会話自体がすでに記録になっています。図が含まれるのは、意思決定を表現している場合に限ります。各スキルの「Produce」リストは、記録できる内容の選択肢であり、すべてを書く義務ではありません。詳しい説明は、求められた場合にのみ申し出てください。
10. 先へ進み、いったん戻る。 レイヤーは一方向に登るものではありません。あるレイヤーでの作業に正当性が感じられない、または宙に浮いていると感じるとき——明確な理由がないまま構造を詳しく作り込んでいるとき——は、その構造に何が依存するのか、まだ見えていないことがよくあります。上のレイヤーを一つか二つ探ってみましょう（フロー、画面、仮説をスケッチするなど）。そうすることで、下のレイヤーで本当に必要なものがわかります。その後、つながる道筋が見えた状態で下に戻り、作業に取り組みましょう。学ぶために上を探ることと、作るために上のレイヤーを確定することは別です。下のレイヤーが不安定なまま上位レイヤーを確定してはいけませんが、上を見てみることまで拒んではいけません。

---

時間軸 — 積極的に探る

時間に関する意思決定は、見過ごされることがよくあります。主に二つのレイヤーに分類できます。

概念モデルレイヤー：

• 中間アクション状態 — オブジェクトは確定する前に、遷移状態（保存中、処理中、承認待ちなど）を通りますか？ これらはモデルの状態です。
• 読み取りモデルの遅延 — データが書き込まれてから、表示されるまでに時間差はありますか？ ユーザーのニーズを明確にし、エンジニアリングチームに共有する、名前の付いた未解決の問いとして示しましょう。
• 関係の時間性 — 「ヨーロッパのすべての製品」とは、現在そのグループに属している製品ですか？ それとも、メンバー構成の変化に応じて変わる製品ですか？ これはデザイン上の意思決定です。
• 削除の意味 — アーカイブ、ごみ箱への移動、完全削除、規制に基づく削除のどれですか？ どれを選ぶのか、その理由とともに明示しましょう。実装はその後です。
• 履歴 — オブジェクトの過去の状態が重要ですか？ 重要だと示すこと自体がデザイン上の意思決定です。

インタラクション構造レイヤー：

• アクション後の状態 — 送信後、ユーザーには何が表示されますか？ リダイレクト先のリストには、変更がすぐに反映されますか？
• 楽観的更新と悲観的更新 — サーバーの確認前に想定される結果を表示しますか？ それとも確認を待ちますか？ 希望を明示し、実装が不確かな場合は未解決の問いとして示しましょう。
• 空、読み込み中、部分表示の各状態 — すべての場所に時間軸に沿ったライフサイクルがあります。すべて設計しましょう。
• エラーと失敗の経路 — バリデーションエラー、サーバーエラー、ネットワーク切断、同時編集。これらは後回しにするものではなく、必須のデザイン工程です。

---

失敗モードの兆候

OOUX のオブジェクトの失敗モード（Sophia Prater）：

• 形状変化 — コンテキストによって同じオブジェクトの形が大きく異なります。表面的な修正：オブジェクトの扱いを一貫させます。モデルでオブジェクトが明確に定義されていない場合は、より根本的な修正が必要です。
• 偽装 — 異なる種類のオブジェクトが同じように見えます。表面的な修正：視覚的な表現を区別します。モデルでオブジェクトを区別できていない場合は、より根本的な修正が必要です。
• 分断 — オブジェクトのデータとアクションが画面上に散らばり、相互にリンクされていません。インタラクション構造の問題 → /layers-interaction-flow。
• 孤立 — オブジェクトが、ほかのオブジェクトとの関係を視覚的に示されないまま存在しています。概念モデルの問題 → /layers-conceptual-model。

Nielsen のヒューリスティクス — 根本レイヤーへの対応： 「システムと現実世界の一致」に関する違反は、ほとんどの場合、表層ではなく概念モデルに起因します。「ユーザーのコントロールと自由」は、インタラクション構造に関する決定です。これらを表層で取り繕うのは、原因ではなく症状への対処です。

---

作業内容の記録

記録はデフォルトで任意かつ簡易なものです。早い段階で一度だけ尋ねてください：

「このセッションで決めたことを短くまとめて保存しますか、それとも会話の中に残しますか？保存する場合は、プロジェクト内の Markdown ファイル（Mermaid 図は Markdown Preview Mermaid Support 拡張機能を使うと VSCode でそのまま表示できます）、Notion（MCP が接続されている場合）、またはほかの場所に保存できます。」

保存先にかかわらず、簡潔さを重視してください（原則 9）。議論を再現するのではなく、決定事項を記録します。何度も読み返される 1 ページは、一度だけ流し読みされる 10 ページに勝ります。より詳細な記録が本当に役立つ場合は提案してください。必要だと決めつけないでください。

Mermaid 図を書く際、ノードラベル内の改行には <br/> を使ってください。\n は文字列としてそのまま表示されるため、使わないでください。

---

どこから始めるか

• どこに焦点を当てればよいかわからない場合 → /layers-orient — 7 つすべてのレイヤーを対象とした迅速な診断
• 対象のレイヤーがわかっている場合 → そのスキルに直接移動

スキル：/layers-observed-behaviour · /layers-domain · /layers-user-needs · /layers-product-strategy · /layers-conceptual-model · /layers-interaction-flow · /layers-surface