User research

Start from a decision rather than a questionnaire

A user interview is a structured conversation designed to understand people's goals, experiences, constraints, and interpretations. It is not a vote on a proposed interface. Consider a university library that is considering a reservation feature for study rooms. The product team might assume that students need a map showing available rooms. A useful research question is instead: How do students currently find a room when they need to work together, and where does that process break down? The first question asks about an imagined feature; the second asks about an observable experience and leaves open whether software is the right solution. This distinction protects the team from gathering flattering answers that merely confirm its preferred design.

The interview plan should specify the decision that the evidence will inform. If the decision is whether to prioritize booking transparency over faster search, ask participants to reconstruct their most recent attempt to find a room. Request a concrete starting point: where were they, what deadline were they facing, what did they try first, and what happened next? A remembered incident is not an objective record, but it often provides more useful detail than an abstract question such as whether an app should be easy to use. Probe for artifacts when participants volunteer them: a calendar reminder, a message to a classmate, or a handwritten schedule. Obtain permission before viewing or retaining personal materials.

A semi-structured guide balances consistency with discovery. It might contain four prompts: describe the last attempt, explain how availability was judged, recount the most frustrating exception, and identify the information that would have changed the decision. Follow-up questions can clarify sequence and context without forcing a predetermined answer. Avoid the leading question, Wouldn't instant booking save you time? It embeds the designer's claim and pressures the participant to agree. Replace it with What, if anything, would have made that attempt easier? If a participant says that the real problem was noisy rooms rather than reservations, that is useful evidence even when it conflicts with the project brief.

Interviews produce accounts of behavior and meaning, not direct measurements of behavior. People can forget details, reconstruct a coherent story after the fact, or answer in ways they think the interviewer expects. A participant may say they always check room rules while observation shows that they usually skip them. Neither result alone establishes deception. The discrepancy could reflect memory, unusual conditions, or an interface whose rules are invisible. Treat the account as a hypothesis about the workflow, and triangulate it with observation, artifacts, or appropriately collected usage data. Interviews are especially valuable for inaccessible motivations, private concerns, and the reasons a user gives for a choice, but they should not be used as substitutes for a performance study.

Recruitment, consent, and respectful facilitation

Recruitment follows the research question, not convenience. If the reservation service serves undergraduate students, graduate researchers, and staff, recruiting only members of the design club will miss different schedules and expectations. Create a recruitment matrix with task frequency, device access, accessibility needs, campus location, and whether the participant has previously failed to book. Do not treat a small purposive sample as a probability sample. It can reveal mechanisms and design risks, but it does not estimate the population prevalence of a need. If the team later needs to estimate how many users encounter a problem, it needs an appropriate sampling design and measurement instrument.

Informed consent is a continuing process. Before a session, explain its purpose, expected duration, what will be recorded, who will access the data, how long data will be retained, and how a participant may withdraw. Make clear that participation is voluntary and that declining a question does not affect their access to the service. A student should not feel that their grades, financial aid, or library privileges depend on participating. Separate permission to participate from permission to record audio, video, or screen content. If recording is declined, take limited notes instead. Where research involves minors, sensitive information, or institutional requirements, obtain the relevant additional approvals before recruiting.

The facilitator should not defend the current design. If someone says a reservation page is confusing, asking But didn't you notice the blue button? converts an observation into a test of the participant. A better response is What did you expect that button to do? Allow silence; an immediate follow-up can prevent the participant from finishing a thought. Use neutral acknowledgments, check understanding, and keep the discussion guide available without reading it as a rigid script. Distinguish what the participant said from the researcher's interpretation in the notes. An observation such as participant returned to the previous screen twice is stronger evidence than the unsupported judgment participant is careless.

Protect the research record. Use pseudonymous participant identifiers, store the link between names and IDs separately if it is necessary at all, restrict access to recordings, and remove unnecessary identifiers from shared excerpts. A direct quotation about a unique medical accommodation may identify a participant even after the name is removed. Report patterns and contextual constraints rather than turning private details into promotional anecdotes. A team that cannot explain why it is retaining raw recordings should reconsider whether it needs them. Privacy and participant trust are methodological concerns as well as ethical ones: participants may withhold information if the interview feels unsafe.

From transcript to defensible finding

Analysis begins by separating raw evidence, codes, themes, and design recommendations. Imagine six interviewees discussing the room-booking service. Four mention asking friends whether a room is free, three describe walking to the building to check, and two report avoiding the system because it requires a campus VPN. These counts describe only the six interviews. They do not mean that two thirds of the university ask friends. A finding might be: In this purposive sample, several students used social confirmation because published availability was not trusted. The supporting evidence is the specific incidents and quotations, not merely the count.

A lightweight coding procedure can still be rigorous. Read each account, mark meaningful episodes, assign descriptive codes such as uncertain availability or permission barrier, and compare cases for exceptions. Keep a codebook with definitions and examples so two researchers do not silently use the same label for different behaviors. Revisit codes that overlap. Record contradictory cases: a student who trusts the calendar may have access to a newer system or a different building. Negative cases are not nuisances to discard; they help bound a finding. When the team recommends showing last-updated timestamps, connect the recommendation to the observed trust problem and mark the design effect as a hypothesis to test, not a proven result.

Interviews are most useful when the output changes a decision. A team may discover that booking availability is accurate but difficult to interpret because room capacities are not visible. The next step could be a low-fidelity prototype showing capacity, equipment, and update time, followed by task-based evaluation. Another finding might show that students without reliable internet cannot use an app at the moment of need. The appropriate response may involve a physical display or an offline-friendly fallback. Research quality is measured partly by whether it reveals such alternatives, rather than by the number of colorful quotations in a slide deck.

Behavior occurs in a setting

Observation studies what people do in the context where a task occurs. A campus room reservation is not only a sequence of taps. Students may be carrying equipment, moving between buildings, coordinating with teammates, dealing with poor connectivity, or checking accessibility of a route. These conditions shape which interactions are feasible. Contextual inquiry combines observation with occasional questions that clarify the participant's intentions. The researcher learns from the participant as an expert in their own activity, but must avoid interrupting so often that the workflow becomes artificial.

Before observing, define the activity boundary. For example, begin when a group decides it needs a room and end when it starts working or abandons the attempt. If observation begins only after the booking screen loads, the study may miss the most important failure: people cannot find the booking link. Record the sequence of actions, artifacts consulted, interruptions, communication with others, and visible errors. Distinguish the environment from the interface. A delayed booking might be caused by a weak network, an unavailable elevator, an ambiguous room label, or a system timeout. Fixing the wrong cause wastes development effort.

A field-note format can include timestamp, action, participant statement, researcher interpretation, and uncertainty. For instance: 14:02 — participant searches email for a room link; 14:03 — opens last week's message; 14:04 — says “I never know which site is current”; interpretation: entry-point discoverability may be poor; alternative explanation: participant missed an onboarding message. Keeping interpretation separate makes it possible for another analyst to challenge the conclusion. It also prevents a single dramatic moment from dominating the report. Notes should include ordinary successful paths as well as breakdowns, because the successful paths reveal practices worth preserving.

The presence of a researcher can change behavior. Participants may read instructions more carefully, avoid shortcuts, or seek permission before acting. The researcher can reduce some distortion by explaining that the task, not the participant, is under evaluation; remaining unobtrusive; and allowing enough time for ordinary behavior to resume. It cannot remove the effect entirely. In remote observation, screen sharing may conceal off-screen work and make sensitive notifications visible. Agree in advance which screens or locations are in scope, provide a pause mechanism, and stop recording when private information appears. Never capture bystanders without appropriate authorization.

Sampling activity, not just people

Observational samples vary across time and situation. A quiet morning session may not reveal the congestion that occurs before examinations. Plan observations at meaningful times and places, including unsuccessful attempts. A researcher may use event sampling to record every booking failure, or interval sampling to capture activity at predetermined moments. These methods answer different questions. Event sampling can describe the variety of failures but not necessarily their prevalence; interval sampling may estimate time allocation in the sampled context but miss brief rare events. State which method was used before interpreting the resulting counts.

Suppose a researcher observes twelve attempts, eight successful and four unsuccessful. The observed success proportion is 8/12, approximately 66.7 percent. This is a description of the observed attempts. It is not an unbiased campus-wide estimate when attempts were selected near one building during a busy hour. Nor are twelve attempts necessarily twelve independent people; one student may retry several times. The unit of analysis matters. If the design question concerns unique students who cannot complete a reservation, counting attempts as independent observations inflates the apparent amount of evidence. Report both attempt-level and participant-level summaries when feasible.

Behavioral logs can complement observation by showing event timing across many sessions, but they do not reveal motivation automatically. A log entry saying that a user closed a page after thirty seconds cannot distinguish confusion, a phone call, a successful alternative route, or an intentional pause. Instrumentation must have a purpose, and collection must respect privacy and retention limits. Avoid logging raw typed search strings or sensitive room details unless the research question requires them and collection is authorized. A small, well-structured field study can explain what an aggregate drop-off rate means; a large event table cannot replace that explanation by itself.

Turning field evidence into a journey map

A journey map is an analytical representation of stages, goals, actions, barriers, and supporting systems. It should be traceable to evidence rather than an invented customer story. For the room-booking case, stages might be decide to meet, discover options, compare constraints, reserve, and arrive. Under each stage, record what the person is trying to accomplish and which information they need. A map might reveal that the booking page is adequate but the confirmation email omits the building entrance, causing late arrivals. That insight would be invisible in a study limited to the booking form.

A journey map is not a process specification. It can include feelings, social negotiation, and parallel activities that a workflow diagram would simplify. Conversely, a precise workflow diagram is needed when implementing error handling and state transitions. Keep the two artifacts connected: a pain point in the journey map should point to one or more concrete tasks, and each proposed task change should identify the evidence that motivates it. Mark uncertain or hypothesized steps. A polished illustration with no traceable observations may persuade stakeholders, but it does not become research evidence through visual polish.

Construct behavioral profiles carefully

A persona is a compact representation of a meaningful pattern of user goals, behaviors, constraints, and context. It can help a team remember whom a design serves, but it is easy to misuse. Giving a fictional character a name, age, photograph, and favorite coffee does not make the persona evidence-based. If the research suggests that some students reserve rooms well in advance while others need a space immediately between classes, the meaningful distinction is planning horizon. Age or major may be irrelevant. The persona should center on the variables that predict design needs, and it should cite the interviews or observations that support each claim.

A defensible profile might be the time-constrained coordinator: frequently organizes short group sessions, uses a phone while moving between classes, needs reliable capacity information, and has little time to recover from a failed booking. Another could be the equipment-dependent researcher: books less often, requires a projector and accessible entry, and can plan ahead but cannot substitute an arbitrary room. These are provisional patterns, not universal personality types. The team should include evidence strength, relevant counterexamples, and a note about which segments were underrepresented in recruitment. A persona is a working model to be revised, not a permanent identity assigned to users.

Personas become harmful when teams infer needs from stereotypes. An assumption that older staff dislike technology or that first-year students never read instructions may lead to exclusionary design. Ask whether the attribute was observed, whether it matters to the task, and whether it is stable across contexts. People can move between behavioral modes. A careful planner becomes an urgent seeker when a meeting is rescheduled. A screen-reader user may also be an expert who uses keyboard shortcuts more efficiently than a novice sighted user. Design requirements should follow capabilities and tasks rather than broad labels.

Accessibility should not be relegated to a single persona called the disabled user. People with disabilities have different goals, tools, and expertise, and many accessibility requirements apply across profiles. Include relevant access needs within the research matrix and across behavioral patterns. For example, a participant who relies on a screen reader may need the room-capacity selector to expose an accessible name and state; a participant with limited dexterity may need generous touch targets and keyboard alternatives. These requirements must also be checked against standards and tested with relevant users. One participant's preference cannot stand in for an entire population.

Keep a chain of evidence

Each persona claim should be traceable to a coded episode, quotation, observation, or documented limitation. A practical evidence table contains the claim, supporting cases, contradicting cases, confidence, and design implication. Needs a reliable confirmation before traveling might be supported by three field observations and contradicted by one participant who routinely walks to the building without booking. The confidence statement should explain why the pattern is useful despite the exception. Avoid replacing this with a fabricated percentage or a pseudo-statistical score. Qualitative evidence can support an actionable design hypothesis without claiming precise prevalence.

When two personas lead to the same design requirement, consider whether the distinction is necessary. If both need an accurate availability timestamp, building separate interfaces for them adds complexity without clear benefit. Conversely, if one group can wait for email confirmation while another needs immediate offline proof, a single default flow may be insufficient. Use scenarios to test persona usefulness: place each profile into a concrete task with constraints, then ask whether the proposed design supports that task. If the persona changes no decisions, it may be decorative rather than analytical.

Personas should be reviewed when new evidence arrives. A launch may reveal users who coordinate reservations on behalf of others, a group omitted from the initial study. That is a reason to revise the model and recruit appropriately, not to force the new users into the closest existing character. Document version dates and unresolved assumptions. A team can also use job stories or task segments instead of personas when behavioral context matters more than stable user categories. The method is a means of making evidence usable, not a required deliverable for every project.

Decompose a goal without losing its context

Task analysis describes what people are trying to achieve and the actions, decisions, and information required along the way. Start with a goal such as secure an appropriate study room for a group of four. A high-level decomposition might include identifying time constraints, finding candidate rooms, checking capacity and equipment, submitting a request, verifying confirmation, and communicating the location to the group. This decomposition is not yet an interface specification. The existing process might use email, a noticeboard, and conversation rather than a single app. Good task analysis captures that reality before suggesting screens.

A hierarchical task analysis can express alternative plans. Task 0 is secure a room. Subtask 1 establishes date, time, group size, and accessibility needs. Subtask 2 checks availability. Subtask 3 compares candidate rooms. Subtask 4 reserves or contacts a coordinator. Subtask 5 confirms the outcome. A plan might say: perform 1–3; if an acceptable room exists, perform 4–5; otherwise revise the time or use an alternative location. This conditional structure is important. A linear list that ignores the no-room-available branch will produce a brittle implementation and misleading usability tasks.

Distinguish user goals from system actions. Understand whether the room is accessible is a goal; open the accessibility tab is one possible interface action. A new design may satisfy the goal by placing access details directly in search results, eliminating the tab. If task analysis begins with the current button sequence, it can accidentally preserve avoidable friction. Record information dependencies: to compare two rooms, a user needs comparable capacity, location, equipment, availability, and booking conditions. Inconsistent units or missing labels can make the comparison impossible even when every button functions correctly.

Exceptions deserve explicit treatment. What if a booking request times out after payment or confirmation? What if another person reserves the room before the user finishes? What if the user cannot authenticate while offline? For each failure, specify what the user knows, what the system knows, and which recovery options are available. A safe workflow avoids silent duplicate reservations and exposes the status of pending requests. Task analysis can reveal that confirm reservation is not a single click but a state transition that needs idempotent handling, an audit trail, and clear feedback. The technical solution should follow the identified risk, not be imposed before research.

Estimate effort and identify leverage points

Time-on-task can be decomposed into stages, but the result must preserve uncertainty. Suppose an observed attempt takes 20 seconds to find the entry point, 35 seconds to compare rooms, 15 seconds to submit, and 40 seconds to confirm with teammates. Total elapsed time is 110 seconds. A prototype that reduces submission time to 8 seconds saves only 7 seconds if every other stage is unchanged. Improving confirmation may matter more than optimizing the submit button. This simple arithmetic prevents teams from concentrating on the most visible screen while ignoring the largest bottleneck.

A task model should include error cost as well as time. Accidentally booking a room at the wrong campus can be more consequential than spending ten extra seconds comparing options. Define success criteria from the user's perspective: the reservation is valid, the room fits the group, accessibility requirements are met, and the confirmation is understandable. Count errors such as selecting the wrong date or overlooking equipment, but also note near misses and recoveries. A user who notices a mistake and corrects it before submission has completed the task, yet the interface may still need improvement.

When prioritizing changes, separate frequency, severity, and confidence. A rare but serious accessibility failure can deserve urgent attention even if it appears in only one observed session. A frequent cosmetic annoyance may be lower priority. A high-severity finding based on weak evidence can justify a focused follow-up study before a large redesign. Use a decision log: state the evidence, proposed intervention, expected mechanism, and a measurable test that could disconfirm the hypothesis. That record makes design reasoning inspectable and protects against treating a single workshop opinion as settled research.

Integrated case: a research-to-design handoff

Consider a fictional campus service team with six interviews, four contextual observations, and an existing booking log. Interviews suggest uncertainty about room availability; observation reveals that students often check messages from classmates; logs show repeated search visits without a confirmed reservation. These sources converge on a possible trust and confirmation problem, but they do not establish that every repeated visit represents failure. The team writes a task model covering discovery, comparison, reservation, and verification, then prototypes a clear status message and a shareable confirmation. It measures whether participants can correctly explain the booking state and whether they send fewer clarification messages in a controlled test.

The team should recruit participants who differ in planning horizon, accessibility requirements, and familiarity with the service. It should report what was observed and what remains unknown, rather than announcing that the prototype solves the problem before evaluation. The research output includes an interview guide, de-identified field notes, a codebook, an evidence table, a provisional persona set, and a task model with failure branches. None is valuable merely because it exists. Together, they form an auditable chain from user experience to a falsifiable design decision.