User Research

A useful research question connects an uncertainty to a decision.

How do people choose between these services? What do they need before they can complete this task? Why does work continue outside the application? What are we assuming someone already understands?

Those questions are different from asking whether people like a design or would use a proposed feature. Preferences can contribute, but we also need context: what someone is trying to accomplish, what happened in a real situation, and what influences their choices.

We begin by identifying what is already known, where that knowledge came from, and what remains uncertain. The purpose, risk, time, budget, and available evidence help determine which questions deserve attention now.

The scope can be focused. The obligation to understand does not disappear because a project is small.

Empathy gives us a reason to ask; research gives us a way to listen.

Clients and their teams bring experience that an outside partner does not have. Customer questions, support conversations, previous studies, observed workarounds, analytics, and the knowledge of people delivering the service can all provide useful starting points.

Stakeholder Interviews are an important part of Abstraction's discovery work. They help us understand the organization, its objectives, constraints, and different perspectives. We synthesize what we learn so it can inform project needs and decisions about the first useful version.

That knowledge is valuable, but it is not automatically the same as hearing from or observing end users. A team's account of what customers need may be accurate, partial, or shaped by which customers they encounter most often.

We keep the source of each perspective visible. Where a question needs direct investigation, we plan the appropriate work rather than relabel an internal discussion as user research evidence.

Conversations and context

User interviews can explore experiences, expectations, decisions, and the circumstances surrounding a task. Questions about a specific recent situation often give us more to examine than a general prediction about future behavior.

Observation can reveal parts of the experience people do not think to describe. A workaround, a pause, a conversation with a colleague, or a document used beside an application can change our understanding of what the product needs to support.

Contextual inquiry combines observation with questions in the setting where the activity happens. These methods offer different perspectives; they do not need to be included in every engagement.

Behavior and patterns

Analytics and other appropriate behavioral records can show where activity occurs, where a sequence changes, or where further investigation may be useful. They do not necessarily tell us why.

Surveys and structured measures can contribute when their questions, participants, and interpretation suit the purpose. A number is only as useful as our understanding of what was measured and who was included.

We distinguish a pattern seen in the available information from a claim about every user or an entire market. Small qualitative studies can expose meaningful problems without establishing how common those problems are across a whole population.

Evaluation through use

Usability Testing examines what happens when representative people attempt relevant tasks with a product or prototype. It can help us understand whether an explanation, structure, interaction, or proposed direction works as intended.

It is one part of User Research, not a substitute for learning about the need in the first place. An interface can be easy to operate and still offer something people do not find useful.

We can help frame the research questions, review existing evidence, define an appropriate approach, prepare materials, coordinate collaborators, and synthesize what is learned into design implications.

Our regular discovery practice draws strongly on stakeholder conversations and existing organizational knowledge. Direct end-user interviewing and specialist participant testing can be planned and coordinated with research partners. Responsibilities for recruitment, sessions, analysis, and reporting are agreed for the engagement rather than implied to be the same on every project.

The client remains part of the learning. Participation can bring context to a finding, expose a mistaken assumption, or help the team understand why a small interaction has a larger consequence. We encourage that involvement while recognizing that people have different capacities to participate.

Expertise should add perspectives to the work, not erase the contributions of the people closest to the business or the people experiencing it.

When you bring us an inquiry form that people appear to start but do not submit, we begin with what the available information can tell us. Reducing the number of fields is a possible response, not yet an explanation.

The form might ask for information people do not have. The offer might be unclear. Someone may need approval before proceeding, worry about an unexpected sales call, or encounter a technical barrier.

We check what the data actually records, review the form and surrounding content, and bring your team's knowledge of the inquiries they receive into the discussion. Together, we identify the uncertainties those sources cannot resolve and plan appropriate direct research, with specialist collaborators where needed.

The question becomes more useful when we ask what prevents someone from making an informed inquiry, rather than how to persuade more people to submit this particular form.

Depending on what is learned, the design response might involve fields, explanations, an alternative contact route, technical work, or a clearer offer. The people participating in research do not need to design the solution for us. Their experiences help us understand what the solution should address.

Research produces material that needs interpretation. Notes, recordings, measurements, and comments are not interchangeable with findings or recommendations.

We look for relevant patterns, differences, contradictions, and gaps. We ask whether several observations support the same explanation and whether another interpretation remains possible. A memorable comment deserves context rather than automatic priority.

A useful findings deliverable can distinguish:

• What was investigated and how.
• What was observed or contributed, with its source and context.
• What we believe it means, and how confident we can reasonably be.
• What the team could change, explore, or investigate next.
• What the work does not yet establish.

A Discovery Findings Report can bring that synthesis together with useful knowledge contributed by the client. The output should help people make decisions and remain understandable when they revisit it later.

Personas and other representations may help organize what is learned. They should be grounded in relevant evidence. An assumption-based profile can be a starting hypothesis, but giving it a name and photograph does not turn it into research.

Research asks people for their time, attention, and sometimes sensitive information. We need to explain the purpose, what participation involves, what will be recorded or retained, and how the material is intended to be used.

We consider who is included, who may be missing, and what would help people participate comfortably. Relevant access needs and different circumstances should inform recruitment and session planning rather than be treated as exceptions afterward.

Participants should have room to decline a question or stop. We should not collect information simply because it is available, or turn a private account into public marketing material without appropriate permission.

The care expressed in the product should also be present in the way we learn about the people using it.

Learning about people begins with respecting their contribution.

Can we begin with research our team already has? Yes. We examine its purpose, context, methods and relevance before commissioning more. A change in the product or audience may reopen a question; useful prior learning should not disappear just because a new engagement begins.

How do we decide what needs direct research? We connect the uncertainty with the decision it affects. Where internal knowledge cannot answer it, we can frame and coordinate an appropriate study with specialist partners. Recruitment, sessions, analysis and interpretation need clear responsibilities.

Research can support incremental improvement, reveal the need for a larger redesign, or suggest that an idea should be abandoned. It may also leave an important question unresolved.

We still need imagination and judgment to decide what to make. Content Design, Information Architecture, Interaction Design, and other disciplines turn understanding into possible responses. Those responses can then be examined through further research and use.

Design Research is the wider umbrella, extending into competitors, technology, content, organizational conditions, and the business. User Research keeps a specific focus on the people experiencing the result.

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover

Within Design Thinking, research contributes before, during, and after production. Learn and Advance carry the findings into Discover again. Product Intelligence preserves that growing body of knowledge with the client, so the next decision does not have to begin from memory alone.

You may need a focused research-and-findings engagement, help making sense of information you already have, or a learning plan within a larger design project.

Bring the question, the uncertainty, or the behavior you have not been able to explain. We can decide what is worth investigating and how to turn what we learn into useful work.

Contact Us