--- name: convention-user-modelling type: convention description: >- The shared definitions for the user-modelling toolkit Sonar uses to understand who a venture serves and why they do or don't convert — the artefacts (segment, archetype, persona, JTBD, forces, opportunity solution tree, behavioural modes, scenarios, journey map, service blueprint), what each is for, when to reach for it, and the pitfalls that blur them. Read before producing any user-modelling artefact (skill-user-modelling, skill-conversion-diagnostic, skill-service-blueprint) so the same terms and artefacts are used at the right time and one artefact is never overloaded with the job of several. Surfaced by the a1.Muse engagement; grown as the toolkit is reused. --- # User-modelling toolkit The vocabulary and artefact set for modelling who a venture serves and why they progress or stall. It exists so the same words mean the same things across engagements, and so each job gets its own artefact rather than being compressed into one overloaded one-pager. Owned by Sonar (the design-strategy and discovery capability); read by anyone producing modelling, diagnostic, or blueprint work. > *This is the canonical copy of this convention. Any human-readable A1 client version is a downstream rendering — edit here.* ## The hierarchy — Why / What / How The toolkit splits into three layers. Naming the layer keeps an artefact in its lane. * **Why — the motivation layer.** What drives a person to act, switch, or stay. Holds *Jobs to be Done* and *Forces*. Answers "what progress is the person trying to make, and what moves or blocks the switch?" * **What — the definition layer.** Who the person is, in stable terms. Holds *Segment*, *Archetype*, and *Persona*. Answers "who are we serving, and how do we describe them?" * **How — the building layer.** How the service meets them over time. Holds *Behavioural Modes*, *Scenarios*, *Opportunity Solution Tree*, *Journey Map*, and *Service Blueprint*. Answers "how do we design and build for them?" A common mistake is to do How-layer work (a journey, a blueprint) before the Why is settled. The layers are a sequence as much as a taxonomy: settle the Why, define the What, then build the How. ## The artefacts Each artefact has one purpose. The owner column names who holds the source of truth for it; reach for an artefact only when its job is the job in front of you. | Artefact | Layer | Based on | Used for | Format | Owner | | -- | -- | -- | -- | -- | -- | | **Segment** | What | Needs / behaviour, not demographics alone | Dividing the market into groups that need different things | Named groups with the need that defines each | Sonar | | **Archetype** | What | A recurring *pattern* of behaviour or attitude | Talking about a behavioural type without inventing a whole person | Short pattern label + defining trait | Sonar | | **Persona** | What | A specific, named exemplar of a segment | Making a segment concrete and memorable for the team | One-pager: who, context, goals, frustrations, the job they hire for | Sonar | | **Jobs to be Done (JTBD)** | Why | The progress a person is trying to make | Anchoring everything to the outcome the user wants | Job statements at three altitudes (below) | Sonar | | **Forces** | Why | The four forces of progress | Explaining why a switch happens or stalls | Push / Pull / Anxiety / Habit, per decision | Sonar | | **Opportunity Solution Tree (OST)** | How | Teresa Torres' OST | Connecting an outcome to opportunities to solutions to experiments | Tree: outcome → opportunities → solutions → tests | Sonar | | **Behavioural Modes** | How | The *state* a context puts a user in | Designing for the user's current state, not an average | Named modes + what each needs from the service | Sonar | | **Scenarios** | How | A mode plus a context plus a trigger | Walking a concrete path through the service | Short narrative: trigger → steps → outcome | Sonar | | **Journey Map** | How | The user's traversal across stages | Seeing the experience end to end from the user's side | Stage spine × the user's actions, thoughts, feelings | Sonar | | **Service Blueprint** | How | Journey map plus the service stack behind it | Connecting the front-stage experience to what delivers it | Stage × lane grid (see skill-service-blueprint) | Sonar | ## The JTBD job hierarchy A job is stated at three altitudes; keeping them distinct stops a feature being mistaken for a need. * **Higher job** — the broad life progress the person ultimately wants. Stable, rarely changes. * **Core job** — the main functional job in this venture's domain. The one the venture competes on. * **Lower jobs** — the smaller sub-jobs and tasks that make up the core job. Where features attach. Design for the core job; let the higher job set the framing and the lower jobs set the backlog. ## The insight flow — from job to backlog One chain carries a modelling insight through to something buildable, so research does not stop at description: **JTBD → Problem → How-Might-We (HMW)** State the job, name the problem that blocks it, then reframe the problem as a How-Might-We that opens solution space without prescribing the solution. The HMW is the unit that hands off to prioritisation and the opportunity solution tree. ## Pitfalls — the distinctions that blur * **Archetype vs persona vs behavioural mode.** An *archetype* is a recurring pattern (a type of behaviour). A *persona* is a specific exemplar of a segment (a described person). A *behavioural mode* is a transient *state* the context puts someone in (the same person moves between modes). Confusing them produces personas that are really modes, or archetypes treated as real users. Keep: pattern, person, state. * **Forces vs Modes.** *Forces* are the directional drivers of a switch decision — Push (away from today), Pull (toward the new), Anxiety (fear of the new), Habit (inertia of today). A *Mode* is the state those forces, plus context, put the user in. Forces explain the *decision*; modes describe the resulting *state*. Don't fold one into the other. * **Don't overload one artefact.** Each artefact does one job. A single "ICP one-pager" that tries to be segment, persona, JTBD, and forces at once is overloaded — decompose it into a needs-based Segment, a Persona, the JTBD layers, and the Forces. (This is the first fix Sonar applies; see skill-user-modelling.) * **Demographics are not a segment.** Segment on need and behaviour; demographics describe, they don't divide by what people need. ## Relationship to skill-audience-icp Reach's `skill-audience-icp` produces a *marketing-targeting* ICP and segments for go-to-market — who to reach, with what message, on which channel. Sonar's modelling produces the *full diagnostic* set for strategy and service design. They share the ICP/segment artefact: `skill-audience-icp` should reference this convention for the segment and persona definitions so the two stay consistent rather than diverging. Where both are in play, model once here and let Reach's skill consume it. ## Quick checklist before producing a modelling artefact - [ ] Right layer named (Why / What / How), and the layers below it settled first? - [ ] One artefact per job — nothing overloaded? - [ ] Segments defined by need/behaviour, not demographics alone? - [ ] JTBD stated at the right altitude (higher / core / lower)? - [ ] Forces and Modes kept distinct? - [ ] Each claim tagged known / assumed / unknown (per standard-prioritisation's confidence overlay)? - [ ] Tone clean per `cos.tov`?