layers-conceptual-model
jamiemill/layers-skills
Define your product's objects, relationships, states, and vocabulary as a load-bearing foundation layer.
What is layers-conceptual-model?
The conceptual model layer establishes what objects your product recognizes, how they relate, what states they can be in, and the vocabulary to describe them—independent of any interface. Use this skill to avoid UX and technical debt by making deliberate, evidence-based decisions about your domain model before designing flows or building systems.
- Extract and validate real objects from domain research using noun foraging and the OOUX method
- Define object attributes, relationships (cardinality and role names), and actions in a single place
- Identify when generic verbs hide genuinely different operations and name them precisely
- Catch attributes that should be relationships and instances mistaken for objects
- Map objects and relationships visually to expose missing, reversed, or spurious connections
- Document state transitions for objects whose status changes what users can do
How to install layers-conceptual-model
npx skills add https://github.com/jamiemill/layers-skills --skill layers-conceptual-model- Familiarity with `/layers-intro` (the parent skill introducing the layers framework)
- Access to domain research, user research notes, or naturalistic language describing the product
- Willingness to defer implementation details and focus on user-facing decisions
How to use layers-conceptual-model
- 1.Identify which conceptual decisions are live (objects, relationships, states, vocabulary, or actions) for your product.
- 2.Choose the technique that fits: noun foraging if you have material to mine; object definition if objects are known but their shape is open; state diagrams if status changes what users can do; relational maps to visualize connections.
- 3.Apply the disciplines (real objects only, attributes vs relationships, role naming, no speculation, verb precision) to whatever you produce.
- 4.Capture only the residue: settled object definitions (marking any as provisional), diagrams encoding real relationships or lifecycles, vocabulary decisions, and open questions.
- 5.When objects and actions stabilize, move to `/layers-interaction-flow` to design how users move through them.
Use cases
- Starting a new product: establish the conceptual model before designing any interface or database schema
- Redesigning an existing product: walk the current UI to reveal the implicit model and compare it to how users actually think
- Resolving naming conflicts: use ubiquitous language lists and card sorting to align teams on vocabulary
- Identifying scope creep: trace every object and attribute to a stated user need, not strategy vocabulary
- Deciding whether something should be persistent: sketch the interaction flow to see what must hold state or be returned to
- Product designers defining a new product's domain model
- Engineering leads auditing technical debt from misaligned conceptual models
- Teams with contested vocabulary or unclear object boundaries
- Redesign projects needing to understand the current implicit model
- Domain-driven design practitioners formalizing ubiquitous language
layers-conceptual-model FAQ
No. The conceptual model is independent of implementation—it defines what the product recognizes and how users think about it, not how it's stored or computed. The gap between the conceptual model and what engineers build creates both UX and technical debt.
A real object is instanceable (you can have many), structured (has attributes), and useful (users care about it). But being a real object doesn't mean it should be persistent or stateful. Justify elevation to first-class by concrete use: what flow forces this thing to persist and be returned to? If nothing does, it's transient or premature.
Mark an object provisional when it exists only because of an unvalidated strategy bet. Model it as a hypothesis, don't lock it, and don't build the layer above on it until the bet is tested.
Noun foraging extracts objects from research or domain notes—use it when you have naturalistic language to mine. Walking the existing product reveals the implicit model in the current UI—use it for redesigns to compare what the product models against how users actually think.
If none of the decisions this layer makes (objects, relationships, states, vocabulary, actions) is genuinely open, you may not need it yet. Say so rather than working it for the sake of it. The layer is most valuable when there's real uncertainty or misalignment to resolve.
Full instructions (SKILL.md)
Source of truth, from jamiemill/layers-skills.
name: layers-conceptual-model description: Techniques for defining the product's objects, relationships, states, and vocabulary independently of any interface — the most load-bearing layer
/layers-conceptual-model
Assumes /layers-intro has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.
The conceptual model is the most neglected load-bearing layer. It defines the objects the product recognises, how they relate, what states they can be in, and the vocabulary for all of it — a deliberate decision about how the product models its domain, independent of any interface.
It is not the users' messy mental model (that's the domain layer), and not a database schema, wireframe, or flow. But the gap between this model and what engineers build matters: a large, unexamined gap is both UX debt (users meet a product that contradicts the model) and technical debt (the system is hard to evolve).
The decisions this layer makes
- What objects the product recognises, and where each object's boundary is
- How those objects relate — cardinality, and named roles where an object plays several
- What a user can do to or with each object
- What states an object can be in, and which transitions matter
- The product's vocabulary — one name per concept, one concept per name
If none of these is genuinely open, you may not need this layer right now. Say so rather than working it for the sake of it.
Disciplines — what keeps the model honest
Apply these to whatever you produce, in any order. They are the high-value part of this layer.
- Real objects only. A true object is instanceable (you can have many), structured (has its own attributes), and useful (the user cares about it in its own right). This catches two errors: an attribute promoted to an object, and — more often — instances mistaken for objects: "CAC" and "ROAS" aren't objects, they're instances of one object, Metric. When several nouns are of-a-kind, model the type as the object; the specific names are instances or values.
- Attributes that are really relationships. If an attribute is just the name or ID of another object in the model, model it as a relationship — don't duplicate it.
- Name the role when an object plays several. "belongs to one User (as referrer)", not "belongs to one User."
- No speculative additions. Every object, attribute, action, and relationship should trace to a stated user need. Scope creep here propagates through every layer above. (Tracing to strategy vocabulary doesn't count — strategy words aren't yet objects.)
- Can-be-an-object ≠ should-be-first-class. The "real objects only" test tells you something can be an object — not that the product should commit to it as a first-class, persistent, stateful entity. That elevation is a design bet with a cost. Justify it by concrete use: what flow or job forces this thing to persist, hold state, and be returned to? If nothing does, it's transient, or it's premature. And when an object exists only because of an unvalidated strategy bet, mark it provisional — model it as a hypothesis, don't "lock" it, and don't build the layer above on it until the bet is tested.
- Verb precision. Does a generic verb (Edit, Delete, Update) hide operations with different real-world consequences? "Edit address" conflates correcting a typo (overwrite is fine) with recording a house move (which should preserve history). When a generic verb could mean genuinely different things, name the operations separately — "Correct address" vs "Register change of address" isn't verbose, it's precise.
- Implementation is not design. When talk drifts to how something is stored, generated, or computed, redirect to what the user can do and what happens to things that referenced it. Flag genuinely entangled questions for an engineering conversation rather than forcing a premature answer.
Techniques
Pick the one that fits the live decision — don't run them all.
| Technique | Use it to |
|---|---|
| Noun foraging + OOUX (Sophia Prater) | Extract objects from research or domain notes. The default when you have naturalistic language to mine. Sort nouns into objects / attributes / instances-or-values / set-aside (UI elements, vague abstractions, actions dressed as nouns), using the "real objects only" test above. |
| Object definition | Pin down one object: what it is (one sentence, the user's view), its attributes, its relationships (cardinality + role names), and its actions. |
| Sketch the flow first (push forward, pull back) | Objecthood is uncertain — whether something should be a persistent object depends on how it's used. Breadboard the flow (/layers-interaction-flow) to see what must persist, hold state, or be returned to, then come back and formalise only those. Often the fastest way to tell a real object from a transient one. |
Relational object map (erDiagram) | See objects and relationships together and catch missing, reversed, or spurious connections. ||=exactly one, o{=zero-or-many, |{=one-or-many; crow's foot on the many side; labels read first entity → second. |
State transition diagram (stateDiagram-v2) | For an object whose status changes what users can do — name the states, the transitions, and what each state forbids. |
| Action (CTA) inventory | List every action a user can take, across all objects, in one place — the product's call-to-action vocabulary. Listing them together (not object by object) is what exposes inconsistency (Add vs Create vs New for one operation) and over-flattening (one verb hiding distinct operations). |
| Ubiquitous language list | Resolve naming. For each contested concept: the chosen term, rejected alternatives, and why. One name per concept, one concept per name — in UI, help text, API names, and internal talk alike. |
| Semantic IxD / action grammar (Rosenberg) | Audit verb consistency and precision across many actions and objects. |
| Event storming — commands/policies (Brandolini) | Process-heavy domain: start from what happens, work back to the objects involved. |
| Card sorting | Vocabulary is unclear or contested across users or teams. |
| Walking the existing product | Redesign: the current UI reveals the implicit model — compare it to how users actually think. |
Also probe the temporal decisions from /layers-intro — intermediate action states, read-model lag, relationship temporality, deletion semantics, history — for any object where they bite.
Working with the designer
Find which of the decisions above are live. Offer the technique that fits: noun foraging if there's material to mine, walking the product if redesigning, or straight to object definition if the objects are known and only their shape is open. Do the next useful thing, not the whole toolkit.
Capture only the residue — the object definitions that got settled (and which are still provisional, pending a bet or a flow), any diagram that encodes a real relationship or lifecycle, the vocabulary calls, and the open questions (objects that felt thin, decisions deferred to engineering). Don't write a report the designer won't reread.
If domain work hasn't been done, say plainly: this model is a hypothesis until there's evidence.
When the objects and actions are stable, the natural next move is to design how users move through them — /layers-interaction-flow.
Related skills
More from jamiemill/layers-skills and the wider catalog.
layers-domain
Map domain concepts, terminology conflicts, and bounded contexts before building the conceptual model.
layers-interaction-flow
Map interaction structure and flow—places, affordances, edge cases—without committing to visual form.
layers-intro
Framework orientation for Layers of Product Design — foundational context for all related design skills.
layers-observed-behaviour
Plan and synthesize user research into grounded, confidence-rated findings about actual user behavior.
layers-orient
Rapid diagnostic to identify which design layer needs attention most urgently.
layers-product-strategy
Connect user needs to business outcomes and test strategic bets with minimal cost.