A UX researcher investigates how people use a product or service, what they need to accomplish, and what gets in their way. The work includes planning studies, recruiting suitable participants, gathering evidence, analyzing it, and helping a team decide what to change. It is broader than asking whether someone likes a screen.
The methods in UX research help a team understand people and their context before committing to a design. This guide explains the researcher's role, the skills to develop, and how a small study can demonstrate those skills.
What is UX research?
UX research is a systematic investigation of users, their needs, and the experience of using a product or service. It gathers information that can expose gaps, challenge assumptions, and reveal opportunities for design. Research can inform decisions from an early idea through to improvements to an existing service.
A researcher selects a method for the question. Interviews explore people's accounts of their experience; observation shows what happens in a particular setting; a usability study examines people attempting tasks. None of these methods automatically tells you every requirement or represents every user.
The researcher's contribution is the connection between the question, evidence, and decision. A finding should explain what was observed, under which conditions, and why it matters. The designer and product manager then work with the researcher and other colleagues to consider possible responses.
For example, a library team may want to know whether readers understand when a renewed book is due. “Do readers like our renewal page?” is less useful than “Can readers identify the new return date after renewing a book?” The narrower question suggests a task that a study can examine.
How to become a UX researcher
Backgrounds such as psychology, marketing, economics, cognitive science, and information science can offer relevant experience. They are not the only routes. Read the requirements of the role you want and identify where you need practice, guidance, or additional training.
A researcher needs analytical skills and the ability to work thoughtfully with people. Listening carefully does not mean claiming to read someone's mind. Ask for examples, distinguish what a participant says from what you infer, and check interpretations against the evidence.
The UK Government user researcher framework provides one concrete career model, from associate to head of user research. It describes developing competence in methods, analysis, inclusive research, and working with stakeholders. Its levels are specific to that framework; other employers organize roles differently.
Build evidence of the skills through a small, responsibly conducted project:
- Research planning: explain the decision, the question, and why the chosen method can help.
- Participant work: prepare neutral prompts, explain the session and data handling, and obtain the appropriate agreement.
- Analysis: connect a finding to notes or observations, retaining contradictory evidence and important limitations.
- Collaboration: explain the finding to designers, engineers, and product colleagues without prescribing a solution the study did not establish.
- Communication: show the team's next decision and what still needs investigation.
A practice project can demonstrate your reasoning, but describe it honestly as practice. Do not invent participants, quotes, or business results to make a portfolio look complete. Protect identities and confidential material when presenting work from an actual organization.
Pay depends on location, seniority, responsibilities, and employer. Compare dated job advertisements or salary sources for the relevant market, including whether a figure is base pay or total compensation. A single undated global salary does not provide a reliable expectation for an individual role.
A practical UX research process
A useful process moves from objectives and assumptions to a suitable method, evidence collection, and synthesis. The steps below retain that sequence while making the decisions explicit. They are a working structure, not a requirement that every study use exactly five steps.
- Set an objective. Identify the decision the team needs to make. In the library example, the question is whether the renewal confirmation communicates the new return date clearly.
- Expose assumptions. Write down what the team believes. A testable design hypothesis can connect a proposed change with the behavior you expect, while making room for evidence that challenges it.
- Choose a method and participants. To explore understanding of a confirmation screen, a task-based prototype session can be appropriate. To learn about borrowing habits outside the interface, interviews or observation answer a different question.
- Gather evidence. Use a consistent task and neutral follow-ups. Record what the person does and how they explain the date, including any help they need.
- Synthesize and discuss. Separate observed behavior, possible explanations, and proposed changes. The study may support a change, challenge it, or leave a question unresolved.
GOV.UK's research-planning guidance connects research questions, user groups, methods, and the team's development work. Plan analysis before collecting a large set of notes that nobody knows how to use.
Interviews, questionnaires, surveys, and usability studies collect different kinds of evidence. Research-based user personas can summarize relevant patterns after that work; a persona is not itself a way to collect observations from users. Likewise, a polished report does not make a weak study stronger.
For the library study, keep a compact record for each session: the task, the route taken, the participant's explanation of the return date, and any assistance. If someone reads the old date as the new one, record that behavior before deciding whether the cause was the label, layout, or wording. Do not turn one person's difficulty into a population-wide percentage.
Use a prototype to prepare research material
Research tools and design tools serve different purposes. Use an interactive prototype in Mockitt to make a proposed experience available for review. Choose separate arrangements for recruitment, consent, recording, and analysis as the study requires.
For a practice version of the library example, prepare Book details, Renew book, and Renewal confirmed screens. Use fictional book and account details. Display the current return date and a proposed new date consistently, and include a Cannot renew state so the review is not limited to a successful path.
Arrange the text, buttons, and other interface elements, then connect the relevant actions between screens. Preview the route before the session. The screens represent a proposed library interface; they do not extend a real loan or establish that the underlying service can approve the renewal.
Give a reviewer a task such as “You need to keep this book longer. Renew it, then tell me when you would return it.” Observe the actions and ask the person to explain the result. Avoid pointing to the new date or asking a leading question such as “Is the larger date clearer?”
Share the intended prototype version with appropriate viewing access and test that access before the session. Keep the study question alongside the material so collaborators know what they are reviewing. A design comment, a participant's behavior, and a researcher's interpretation are different records.
The useful portfolio artifact is the complete chain: a research question, a justified method, evidence handled responsibly, a finding with limits, and a decision or next question. That shows more of a researcher's work than a collection of attractive screens.
