Menu
Framework orientation for Layers of Product Design — load this first; provides the context all other skills depend on
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Techniques for defining the product's objects, relationships, states, and vocabulary independently of any interface — the most load-bearing layer
Techniques for mapping a domain's concepts, terminology conflicts, and bounded contexts — the raw material the conceptual model is built from
Techniques for mapping interaction structure and flow — places, affordances, edge cases, and failure paths — without committing to visual form
Techniques for planning user research and synthesising it into grounded, confidence-rated findings about what users actually do
Diagnostic audit across all seven layers — identifies the bottleneck layer and recommends where to focus
Techniques for connecting user opportunities to business outcomes and solution bets, and testing the riskiest assumptions cheaply
| name | layers-intro |
| description | Framework orientation for Layers of Product Design — load this first; provides the context all other skills depend on |
Load this skill at the start of any design session. It provides the framework context that all other /layers-* skills depend on.
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:
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 = 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:
The job of every skill is to help the designer make better decisions — not to make decisions for them.
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:
/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.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.
Temporal decisions are frequently overlooked. They cluster at two layers:
Conceptual model layer:
Interaction structure layer:
OOUX object failure modes (Sophia Prater):
/layers-interaction-flow./layers-conceptual-model.Nielsen's heuristics — a root-layer mapping: "Match between system and real world" violations almost always root in the conceptual model, not the surface. "User control and freedom" is an interaction structure decision. Patching these at the surface treats symptoms, not causes.
Capture is opt-in and lightweight by default. Ask once, early:
"Do you want me to save a short summary of this session's decisions, or keep it in the conversation? If saving: a Markdown file in your project (Mermaid diagrams render natively in VSCode with the Markdown Preview Mermaid Support extension), Notion (if the MCP is connected), or somewhere else?"
Whatever the destination, bias to brevity (principle 9): capture the decisions, not a retelling of the discussion. A page someone rereads beats ten pages they skim once. If a fuller write-up would genuinely help, offer it — don't assume it.
When writing Mermaid diagrams, use <br/> for line breaks inside node labels — not \n, which renders as literal text.
/layers-orient — rapid diagnostic across all seven layersSkills: /layers-observed-behaviour · /layers-domain · /layers-user-needs · /layers-product-strategy · /layers-conceptual-model · /layers-interaction-flow · /layers-surface