layers-observed-behaviour
jamiemill/layers-skills
Plan and synthesize user research into grounded, confidence-rated findings about actual user behavior.
What is layers-observed-behaviour?
This skill provides techniques for planning user research studies and synthesizing research material into concrete observations about what users actually do. Use it to move from team assumptions to evidence-based understanding of user behavior, with explicit confidence ratings and identified research gaps.
- Plan research studies matched to specific learning goals using methods like JTBD interviews, contextual inquiry, diary studies, and analytics review
- Extract concrete observations from research material—what users said, did, or felt—staying close to raw data and raw quotes
- Group observations into patterns by recurring situations, motivations, anxieties, and workarounds
- Generate candidate job stories with confidence ratings (observed/inferred/assumed)
- Identify and flag research gaps explicitly rather than papering over unknowns
How to install layers-observed-behaviour
npx skills add https://github.com/jamiemill/layers-skills --skill layers-observed-behaviour- Assumes /layers-intro skill has been loaded
- Access to research material (interviews, recordings, tickets, analytics) or ability to plan new research
How to use layers-observed-behaviour
- 1.Determine whether you are in Plan mode (no research yet) or Synthesise mode (research material exists)
- 2.If Plan: define 2–3 specific learning goals, then select the research method that fits (JTBD interviews, contextual inquiry, diary studies, support ticket analysis, analytics review, or usability observation)
- 3.If Synthesise: extract concrete observations from your material using prompts (most surprising thing, what recurred, unexpected struggles), then group observations by situation, motivation, anxiety, or workaround
- 4.Generate candidate job stories in the form 'When [specific situation], I want to [motivation], so I can [outcome]' and mark confidence level
- 5.Flag research gaps explicitly and decide whether to plan follow-up research or move forward with current confidence levels
Use cases
- Planning a user research study when you have specific questions but no data yet
- Synthesizing interview recordings and support tickets into actionable patterns and job stories
- Validating whether team assumptions about user behavior are grounded in evidence or remain assumptions
- Identifying which research gaps matter most before investing in follow-up studies
- Extracting domain language and candidate objects from user research to feed into domain modeling
- Product managers planning research
- UX researchers synthesizing qualitative data
- Designers grounding product decisions in user evidence
- Teams moving from assumptions to evidence-based understanding
layers-observed-behaviour FAQ
Observed means you have quotable verbatim evidence from users. Inferred means you've drawn a conclusion from observations but it's not directly stated. Assumed means it's a team belief not yet grounded in research. Mark each claim accordingly.
6–10 qualitative interviews usually reach saturation for a specific learning goal, where new interviews stop surfacing new patterns.
Synthesize what exists first to see what patterns emerge and what gaps remain, then plan targeted follow-up research to fill the most important gaps.
A workaround is when users improvise a solution because the product doesn't meet their need. Workarounds signal real, strong needs—strong enough to motivate extra effort.
Stay close to raw data: use verbatim quotes, not summaries; extract what users said/did/felt, not what you think it means; and explicitly mark confidence levels so interpretation is visible.
Full instructions (SKILL.md)
Source of truth, from jamiemill/layers-skills.
name: layers-observed-behaviour description: Techniques for planning user research and synthesising it into grounded, confidence-rated findings about what users actually do
/layers-observed-behaviour
Assumes /layers-intro has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.
The observed behaviour layer is the closest we can get to reality — what users actually do, not what we think they do or wish they would. Everything above it is interpretation; this layer is the source.
It splits into two situations. Detect which applies and say so:
- Plan — no research yet; design a study.
- Synthesise — research material exists; make sense of it.
With partial research, synthesise what exists first, then plan to fill the gaps.
The decisions this layer makes
- What specific questions we most need to answer about our users
- What evidence already exists, and how reliable it is
- How to gather what's missing
- What patterns hold with confidence vs. what remains assumption
Disciplines — what keeps observation honest
- Stay close to raw data. Observations should be specific and near the source — what users said, did, felt — not summarised into conclusions.
- Ground in something seen or heard, not in team beliefs.
- Mark confidence: observed / inferred / assumed. If you mark something observed, the verbatim that supports it should be quotable in the same note — an observed claim with no quotable evidence is really inferred.
- Name research gaps explicitly rather than papering over them.
- Workarounds are signal. A need real enough to motivate improvisation is a strong one.
Techniques
To plan a study
| Technique | Use it when |
|---|---|
| Define the learning goal | Always start here. Push past "understand users better" to 2–3 specific questions — "what triggers someone to refer a friend, and what makes them hesitate." |
| JTBD interviews | Understanding triggers, motivations, anxieties. Interview about a real past experience, not hypotheticals. Guide: opening ("tell me about the last time you…"), timeline (what triggered it, what you tried), motivations (what you hoped, what worried you), closing. |
| Contextual inquiry / observation | What users say differs from what they do — watch real work for tacit behaviour. |
| Diary studies | Behaviour is distributed over time or infrequent — users self-report as events occur. |
| Support ticket / review analysis | Existing product with accumulated signal — pain points at scale without recruiting. |
| Analytics review | What users do (not why). Complements qualitative; doesn't replace it. |
| Usability observation | Where people struggle or succeed with an existing product. |
For interviews, plan synthesis up front: one observation per note, tagged with the question it speaks to, raw quotes over summaries. (6–10 qualitative interviews usually reach saturation.)
To synthesise material
| Technique | Use it to |
|---|---|
| Extract observations | Pull out concrete things users said, did, or felt — no interpretation yet. From memory, prompt: most surprising thing? what recurred? what did they struggle with unexpectedly? |
| Pattern grouping | Group observations by recurring situations, common motivations, shared anxieties, and workarounds. |
| Candidate job stories | When [situation], I want to [motivation], so I can [outcome]. Check the "When" is specific and the "want" is a motivation not a solution; mark confidence. |
| Gap-flagging | What do the observations not yet answer? These become a follow-up Plan session. |
Working with the designer
First find out what exists — interviews, recordings, tickets, analytics — and state the mode. Listen for nouns (candidate domain objects) and the natural language users use; that feeds the domain layer.
Offer the technique that fits: in Plan, the method matched to the learning goal; in Synthesise, extraction → patterns → candidate stories. Do the next useful thing, not a full battery.
Capture only the residue — key raw observations, the patterns with their supporting evidence, candidate job stories with confidence ratings, and the named research gaps.
Candidate job stories are ready to refine at /layers-user-needs.
Related skills
More from jamiemill/layers-skills and the wider catalog.
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.
layers-surface
Audit and refine UI/UX surface against underlying conceptual models, interaction flows, and accessibility standards.
layers-user-needs
Elicit and prioritize user needs, pains, and desires to ground product strategy in evidence.
agent-pulse
Inspect local AI-agent activity across 13+ platforms with tokens, costs, budgets, and health checks.
architect
Think through what you're building like a senior engineer before writing code.