/layers-intro

name: layers-intro
description: Framework orientation for Layers of Product Design — load this first; provides the context all other skills depend on

/layers-intro

Load this skill at the start of any design session. It provides the framework context that all other `/layers-*` skills depend on.

---

The framework

**Layers of Product Design** organises design work into seven layers across three zones. Layers have *logical dependency*: lower layers are foundations for upper ones. Weak lower layers create UX debt that propagates upward.

**Reality** — complex, contradictory, evolving. Source of all learning.

**Problem space** — knowledge gathered from reality: 1. **Observed behaviour** — what users actually do 2. **The domain** — concepts, terminology, and mental models that exist independently of any product 3. **User needs** — what we think users are trying to achieve, and why

**Solution space** — deliberate decisions about what to build: 4. **Product & service strategy** — which needs to serve, and what business outcomes to target 5. **Conceptual model** — objects, relationships, states, vocabulary — independent of any interface 6. **Interaction structure and flow** — places, affordances, connections, and flow logic 7. **Surface** — words, visuals, feedback, hierarchy — what users actually encounter

The layers are not a linear process. Enter anywhere — but always check whether the foundations below are sound.

*Inspired by Jesse James Garrett's* The Elements of User Experience *(2000).*

---

Design is decision-making

Design = making decisions about the form of a solution (Christopher Alexander). Form is the solution; context is the requirements, constraints, and environment it must fit. Good design is good fit.

**Four kinds of progress:** 1. **Making decisions** — resolving something undecided 2. **Uncovering unmade decisions** — discovering what hasn't been decided yet (often more valuable than 1) 3. **Evaluating decisions** — identifying decisions already made that are risky, inconsistent, or wrong 4. **Prioritising decisions** — lower layers are more foundational and carry more risk if wrong

The job of every skill is to help the designer make better decisions — not to make decisions for them.

---

How to use these skills

Each `/layers-*` skill is a **library of techniques for one layer — not a script to run start to finish.** Don't march through every step and emit a stack of artefacts. Instead:

1. **Find the live decisions.** What at this layer is genuinely undecided, risky, or worth surfacing? (`/layers-orient` finds these across all layers if you're not sure.) If nothing here is live, say so and move on — don't manufacture work to fill the structure. 2. **Offer a technique that fits the decision.** Each skill lists techniques with the situations they suit. Suggest one or two and let the designer choose. A technique is a way to make a specific decision, not a box to fill. 3. **Work the decision; capture only the residue.** Produce what the decision needs — usually a few lines, sometimes a diagram — not a full report. The conversation is the working surface; the capture is what survives it.

Each skill names **the decisions that layer makes** and the **disciplines** that keep it honest. Those are the spine. The wording of any individual prompt is disposable; the decision it serves is not.

---

Principles — apply across all sessions

1. **Decisions, not outputs.** Artefacts are useful only insofar as they represent decisions made or surfaced. Name the decision, not just the diagram. 2. **Uncover before you resolve.** Surfacing decisions the designer didn't know they needed to make is often more valuable than answering the ones they did. 3. **Work at one layer at a time.** Conflating problem space and solution space, or surface and conceptual model, produces confused outputs. 4. **Check foundations before building upward.** Before working on an upper layer, audit the layer below. Flag instability. 5. **The conceptual model is the most neglected load-bearing layer.** Give it more attention than feels comfortable. 6. **Flag bad decisions, not just missing ones.** A decision already made that's risky or inconsistent needs to be named, not worked around. 7. **Steer, don't be steered.** Don't jump to surface output before foundational decisions are made. 8. **Design principles vs. implementation decisions.** Some decisions can be stated without knowing system constraints — *what should happen from the user's perspective*. Others are entangled with implementation: articulate the user experience requirement, form a well-shaped question, and carry it into a design+engineering conversation. Don't force a premature answer. 9. **Capture decisions, not transcripts.** Default to lightweight output: the decisions made, the decisions surfaced, and the open questions — nothing more. Don't generate a document longer than the user will actually reread; the conversation is already a record. A diagram earns its place only when it encodes a decision. The "Produce" list in each skill is a menu of what *can* be captured — not a mandate to write all of it. Offer to expand only if asked. 10. **Push forward, pull back.** The layers aren't a one-way climb. When the work at a layer feels unjustified or floating — you're elaborating structure with no clear reason to — it's often because you can't yet see what will depend on it. Probe a layer or two up (sketch a flow, a screen, a bet) to discover what the lower layer actually needs, then come back down and do that work, now clearer and connected to a path. Probing upward to *learn* is not the same as committing upward to *build*: don't finalise an upper layer on an unstable lower one, but don't refuse to glance up either.

---

The time dimension — probe proactively

Temporal decisions are frequently overlooked. They cluster at two layers:

**Conceptual model layer:**

• *Intermediate action states* — does an object pass throug