One-on-ones with decision-makers to surface the project's history, politics, constraints and definitions of success — before any of it surprises you later.

Interviewing people where they actually use the product — their desk, their home, their commute — because behaviour in context beats recollection in a lab.

Observation paired with conversation over time, to learn what people do rather than what they report doing. The gap between the two is usually the insight.

Structured sessions with domain specialists to compress months of learning into hours — essential when the domain is genuinely hard, like research or health.

Mining existing reports, analytics and past studies before commissioning anything new. Half the answers are usually already in the building.

A structured pass through published knowledge and emerging trends to find what's known, what's contested and where the genuine gaps are.

Systematic comparison of competing and comparable products to spot table-stakes, weaknesses and the space where differentiation is possible.

Analytics, funnels and heatmaps at scale — the "what happens" that tells you where to point the qualitative "why" research.

Comparable data from many participants at once — best for measuring attitudes and priorities, dangerous when used to ask what people would hypothetically do.

Participants log an experience over days or weeks, revealing patterns and pain points no single interview session could capture.

The team experiences the service as customers — signing up, calling support, hitting the dead ends. Empathy you can't get from a report.

Deciding who to recruit and how many, so findings represent real users rather than whoever was easiest to reach.

An ongoing plan for consulting the people a project affects — and the people with power over it — so support is built, not assumed.

Visualising who influences whom across teams and agencies — the political map that determines whether good design ever ships.

A deliberate, sometimes uncomfortable conversation about what problem we're actually solving, for whom, and what we don't yet know. Cheapest phase to get right.

Aligning everyone on goals, outputs, timelines and constraints in one session — so month three doesn't discover that month one meant different things to different people.

Clustering research observations until themes emerge from the data itself — done live with the team, so insights are owned rather than delivered.

Turning raw data into insights, theories and design recommendations. Now AI-accelerated in my workflow — Dovetail clusters, I interrogate.

Users group and label content their way, exposing the mental models an information architecture should follow — not the org chart's way.

Structured divergence: getting a group from research insights to a wide field of candidate solutions before anyone falls in love with the first idea.

Designing with users and stakeholders in the room, not for them from a distance. Slower per session, dramatically faster to adoption.

A compressed multi-day cycle — map, sketch, decide, prototype, test — that answers a big product question before committing a big budget.

Sketches, paper flows and Crazy-8s that make ideas testable in minutes. The cheaper the prototype, the easier it is to hear criticism of it.

Pixel-accurate Figma or working HTML/CSS prototypes to resolve final details — interaction, motion, accessibility — before engineering commits.

Expert review against established usability principles — a fast, cheap sweep that catches the obvious failures before users have to.

Real people attempting real tasks on the thing you built. The final gate everything ships through — and the source of every number on this site.

The team's honest best guess at how the work unfolds — phases, activities, decision gates — written to be revised as evidence arrives, not defended against it.

Who we'll involve, when, how and why — so consultation is designed rather than improvised, and nobody influential discovers the project at launch.

The researcher's script: objectives, questions, prompts and timing for every session — consistent enough to compare sessions, loose enough to chase surprises.

The experience as it actually is today — steps, channels, emotions and breakdowns — giving the whole team one shared picture of the problem worth solving.

Every actor, process, relationship and exchange in a service space on one canvas — because you can't simplify a system you haven't seen whole.

Research distilled into findings, stories and opportunities — every claim traceable to evidence, every insight paired with a "so what".

A population broken into groups that share needs — but only groups that would change a design decision. If two segments get the same design, they're one segment.

One page stating what needs to happen, for whom, and why it matters — the sentence every later decision gets tested against.

Research-based archetypes representing users with shared needs and behaviours — built from interview data, never from stereotypes around a meeting table.

The prioritised "so whats" of research — what deserves attention, what action it implies, and what evidence says so.

A plain statement of what the product offers users that alternatives don't — if the team can't agree on this, the interface can't say it either.

Short statements capturing the intent of the design without prescribing the solution — the tie-breakers for every argument that follows.

The future-state experience the organisation is working towards, written to outlive any single project or release.

The journey as it should be — same rigour as the current-state map, applied to the experience you're committing to build.

A journey map with the machinery exposed: frontstage experience on top, backstage processes, systems and staff actions underneath. Where service problems hide.

Short narratives of a user accomplishing a real task — concrete enough to design against, human enough to keep the team honest.

Early, deliberately rough expressions of ideas from ideation — made to be compared, challenged and mostly discarded before prototyping begins.

Structural skeletons of screens — layout, hierarchy and interface elements without visual polish, so feedback targets the thinking, not the colours.

Simulations users can actually try — from clickable Figma to working HTML/CSS — because testing an idea should always be cheaper than building it.

Token-based component libraries with accessibility built in — the deliverable that keeps every future screen consistent, including ones I'll never see. My signature output.

User needs written in first person, sized for a sprint backlog — the bridge between research findings and what developers build on Monday.

One page showing how the work moves from today to the future state — sequenced, dependency-aware, and honest about what ships when.

What we tested, with whom, what broke and what to do about it — findings ranked by severity, each tied to a recommendation and evidence clip.

A WCAG-mapped review combining automated scans (Axe, WAVE) with manual screen-reader testing — issues prioritised by user impact, not just compliance risk.