How I Research

The first job is to validate the reason for the work. A collaborative workshop turns a broad request into an agreed problem, identifies the decisions the research must support and exposes assumptions that need evidence.

What happens here

• Ask why the work is needed: underperformance, comprehension, conversion, retention, accessibility, new opportunity or something else.
• Review existing analytics, search terms, funnels, device use, feedback, support queries and earlier research, where reliable tracking exists.
• Map stakeholders, audiences, constraints, known risks and competing expectations in FigJam, Miro or in person.
• Review competitors and adjacent services, using moodboards and pattern analysis to understand expectations without blindly copying them.
• Re-brief the challenge as a clear problem statement, agreed research questions and practical measures of success.

A sound plan connects each research question to a method and a decision. I define who needs to take part, what we need to learn, how sessions will be run and what evidence will count as success.

Finding the right people

• Start with a short Typeform survey to understand current users and invite suitable respondents to further research.
• Use email or client mailshots, existing marketing channels and relevant local Facebook or community groups to reach real audiences in context.
• Supplement recruitment through UserInterviews.com when we need carefully screened candidates beyond the existing user base.
• Screen for behaviour, familiarity, geography, circumstances and accessibility needs, rather than assuming the recruitment channel defines the participant.
• Use fair incentives, plan for cancellations and offer formats that do not exclude people with lower digital confidence.

Choosing the method

• Moderated interviews and task-based testing through Google Meet or Teams with screen sharing.
• Prototype testing through Figma links, Maze or UserTesting.com when scale or unmoderated feedback is useful.
• Surveys and questionnaires for broader directional evidence, without confusing volume with depth.
• Clear task-success baselines: completion without help, completion with help, comprehension, confidence and ability to explain the next step.

Research is valuable when it changes the system, not just one screen. I look for repeated barriers across content, navigation, interaction patterns and handovers, including the needs of people who may interpret or access the experience differently.

Turning evidence into structure

• Test comprehension as well as navigation: can people explain the offer, recognise whether it is for them and understand what happens next?
• Review accessibility through keyboard, screen-reader, zoom and mobile journeys, with supported research formats when remote testing would exclude participants.
• Connect findings to affected journeys, components and content patterns so recommendations can scale across the product.
• Structure each finding as: user problem, evidence, affected journey, severity, recommendation and indicative effort.
• Create a prioritised findings register that can become the team’s actionable backlog and be retested after improvements.

Once the problem is understood, I make ideas tangible. That might mean testing an existing site, mapping a proposed journey or building a prototype that allows people to react to something concrete before development becomes expensive.

Test, learn, improve

• Define realistic user flows and tasks around the decisions people actually need to make.
• Build the lowest-fidelity prototype capable of answering the question, then increase fidelity only when it adds useful evidence.
• Capture observations, session notes and recordings consistently, with informed consent and appropriate privacy controls.
• Synthesise findings through human judgement, supported by tools such as Condens, Maze and carefully reviewed AI-assisted pattern finding.
• Group behaviours, common themes and barriers, then return to the team for brainstorming, redesign, re-prototyping and another focused round of validation.
• Measure the outcome against the original why, rather than declaring success because a new interface has been delivered.