3. User Research and Requirements Discovery

Introduction and Context

A digital product may be technically impressive and visually attractive yet fail because it solves the wrong problem, addresses the wrong audience, or fits poorly into users’ lives. User research reduces this risk by creating a disciplined way to understand people, their goals, behaviours, environments, constraints, and expectations. Requirements discovery then converts that understanding into a defensible description of what a product should enable, how it should behave, and how success will be evaluated.

In UI/UX design and responsive web development, research is not a preliminary activity that ends before design begins. It is an evidence-generating practice that informs information architecture, interaction patterns, content, visual hierarchy, accessibility, responsive behaviour, and technical priorities. Research findings also remain useful during development, testing, deployment, and product improvement.

This chapter treats research as both a methodological and organisational capability. It explains how to frame research questions, choose appropriate qualitative and quantitative methods, recruit participants ethically, analyse evidence, formulate personas and jobs-to-be-done, and validate requirements. The emphasis is on practical judgement: no method is universally superior, and the quality of a study depends on the relationship between its purpose, design, participants, analysis, and decisions.

Learning Objectives

After studying this chapter, learners should be able to:

1. Explain the role of user research in product and responsive web design.

2. Distinguish qualitative, quantitative, generative, evaluative, and behavioural research.

3. Formulate focused research questions and an appropriate sampling plan.

4. Plan and conduct interviews, observation, contextual inquiry, surveys, and competitive analysis.

5. Analyse evidence using coding, affinity mapping, triangulation, and prioritisation.

6. Develop evidence-based personas, jobs-to-be-done, and user requirements.

7. Identify ethical, legal, organisational, and methodological risks.

8. Translate validated requirements into actionable design and development decisions.

Research as a Design and Decision-Making Practice

User research is the systematic collection and interpretation of evidence about users and the contexts in which they interact with a product or service. It differs from casual feedback because it uses explicit questions, planned methods, documented evidence, and reasoned interpretation.

Two broad research traditions are particularly important. Qualitative research seeks depth and meaning. It asks how people act, what they experience, why they make choices, and how a situation is understood from their perspective. Interviews, observation, contextual inquiry, diary studies, and usability sessions are common qualitative approaches. Quantitative research describes measurable patterns, such as frequency, proportions, completion rates, ratings, or relationships between variables. Surveys, analytics, and controlled experiments are typical quantitative approaches.

The distinction is useful but not absolute. An interview can produce simple counts, and a survey can reveal open-ended explanations. More important is the kind of claim being made. Qualitative evidence can illuminate motivations and mechanisms, but usually cannot estimate prevalence reliably. Quantitative evidence can indicate how widespread a pattern is, but may not explain its causes. Mixed-method research combines both forms when decisions require breadth and depth.

Research may also be classified by purpose. Generative research explores needs and opportunities before a solution is defined. Evaluative research examines an existing design, prototype, or service. Descriptive research documents what happens, while explanatory research investigates why it happens. Foundational research develops understanding of a domain; continuous research monitors changing behaviours and product performance.

A useful research decision begins with the organisational decision rather than the method. A team might ask: Should the service support guest checkout? Why are users abandoning an application form? Which content should appear first on a mobile screen? Which competitors establish user expectations? The method follows from the uncertainty and the decision at stake.

From Business Problem to Research Question

A business problem is often too broad to guide data collection. “We need more engagement” is a business concern, not a research question. A research question narrows the concern into something observable and answerable. For example: “What difficulties do first-time applicants experience when locating eligibility information on a mobile device?”

A strong research question identifies a population, behaviour or experience, context, and information need. It should not assume the solution. “Would users prefer a chatbot?” presupposes a particular intervention. “How do users currently seek help when they cannot find an answer?” is more open and diagnostically useful.

A research brief normally records:

• the decision that research must inform;
• known evidence and important assumptions;
• target user groups and contexts;
• primary and secondary research questions;
• proposed methods and rationale;
• recruitment and sampling criteria;
• ethical and data-protection requirements;
• schedule, resources, outputs, and success criteria.

Researchers should distinguish assumptions from findings. An assumption is a belief held before investigation; a finding is an interpretation supported by collected evidence. Maintaining an assumption log helps the team identify which beliefs were confirmed, revised, or rejected.

Research questions should be prioritised according to risk and value. A question deserves early attention when its answer could substantially alter product direction, when the team has little reliable evidence, or when the cost of being wrong is high. This risk-based approach prevents teams from spending time on attractive but low-consequence questions.

Sampling and Recruitment

Sampling determines whose experiences enter the study. In qualitative work, purposive sampling is generally more useful than attempting statistical representativeness. Participants are selected because they possess relevant characteristics, experience a particular workflow, or represent an important variation. In quantitative research, probability sampling is preferable when the goal is to generalise to a defined population, although practical product studies often use non-probability samples and must state that limitation clearly.

A sampling plan should specify the population, inclusion criteria, exclusion criteria, desired variation, sample size rationale, recruitment source, incentive, and screening procedure. Relevant dimensions may include experience level, device ownership, accessibility needs, geography, language, role, frequency of use, or whether a person is a purchaser, administrator, or end user.

Sample size is not determined by a universal rule. Qualitative studies often continue until additional sessions produce little new insight, a condition commonly described as saturation. Saturation should be treated as a reasoned judgement rather than a mechanical guarantee. Quantitative sample size depends on the desired precision, population, expected variation, analysis plan, and acceptable risk of error.

Recruitment can introduce serious bias. Recruiting only from an existing customer list may exclude former users and non-users. Recruiting through social media may overrepresent digitally confident people. Incentives may be necessary, but excessive incentives can pressure economically vulnerable participants or attract people who do not genuinely fit the criteria. Recruitment materials should describe the study honestly without revealing a hypothesis in a way that encourages particular answers.

Core Methods for Discovering User Needs

Interviews

A semi-structured interview uses a discussion guide while allowing participants to explain experiences in their own terms. The guide normally begins with background and recent behaviour, moves to specific episodes, and ends with reflection. Questions should favour recall of actual events over abstract opinion. “Tell me about the last time you submitted a reimbursement claim” is usually more informative than “Would you use an easier claims system?”

Good interviewers listen actively, use neutral probes, tolerate silence, and avoid correcting or defending the product. They distinguish stated preference from demonstrated behaviour. Participants may sincerely say they value security, speed, or accessibility, but decisions are better supported by examining what they actually did in a relevant situation.

Interviews are useful for motivations, language, expectations, and sensitive experiences. Their limitations include recall error, social desirability, interviewer influence, and the difficulty of inferring frequency from a small sample. Interview data should therefore be treated as evidence about meanings and experiences, not automatically as population statistics.

Observation

Observation examines behaviour as it occurs. It may be overt, with the researcher explaining the activity, or unobtrusive where appropriate and ethical. Researchers record actions, sequence, interruptions, workarounds, environmental conditions, tools, and interactions with other people. An observation protocol should define what is relevant without becoming so rigid that unexpected behaviour is missed.

Observation is especially valuable when people cannot easily articulate tacit practices. A user may report that a form is completed in one sitting, while observation reveals interruptions, copied information from paper records, and repeated attempts caused by unclear validation. Field notes should separate description from interpretation: “participant opened three browser tabs” is an observation; “participant was confused” is an interpretation requiring supporting evidence.

Contextual Inquiry

Contextual inquiry combines observation with questions asked in the setting where work occurs. The researcher adopts a partnership stance: the participant demonstrates real work, explains decisions, and corrects the researcher’s interpretations. The method is powerful for understanding tools, handoffs, physical constraints, organisational rules, and informal workarounds.

A contextual inquiry should avoid turning into a conventional interview conducted away from real activity. Questions are anchored to events: “What made you choose this option?” or “What happens after you save this record?” Researchers must also obtain permission from employers, customers, or other people who may appear in the environment.

Surveys

Surveys are appropriate when the team needs structured responses from a larger group or wants to measure the prevalence of a previously identified issue. A well-designed survey has a clear target population, concise wording, mutually intelligible response options, and an analysis plan prepared before collection.

Questions should avoid double-barrelled wording, leading language, unnecessary technical terms, and ambiguous timeframes. “How satisfied are you with the speed and clarity of the service?” asks about two attributes at once. A better design separates speed and clarity. Response scales should be balanced and labelled consistently. Pilot testing can reveal confusing wording, missing options, excessive length, and technical problems.

Survey results are affected by coverage error, non-response, self-selection, recall error, and question order. A large sample does not automatically create valid evidence. Researchers should report who responded, how the sample was obtained, missing data, and limitations on generalisation.

Competitive and Comparative Analysis

Competitive analysis examines direct competitors, substitutes, adjacent services, and established conventions. It should go beyond listing features. Researchers compare user journeys, terminology, onboarding, content structure, pricing communication, accessibility, responsive behaviour, trust signals, error recovery, and service integration.

A comparison matrix can distinguish parity requirements from opportunities for differentiation. However, competitors are not proof of user need. Copying a competitor may reproduce its weaknesses or ignore a different audience and business model. Comparative analysis is strongest when combined with user evidence and contextual understanding.

Analysing Evidence and Building Understanding

Analysis begins during collection. After each session, the researcher should record notable observations, emerging hypotheses, contradictions, and questions for later sessions. This prevents memory loss and allows the study to adapt responsibly.

Qualitative analysis commonly involves coding. A code is a concise label assigned to a meaningful segment of data, such as “relies on printed confirmation,” “uncertain about eligibility,” or “shares account with family member.” Codes may be descriptive, interpretive, or linked to a research question. Researchers then group related codes into themes. A theme is not merely a repeated topic; it is a meaningful pattern that explains an aspect of experience.

Affinity mapping supports collaborative synthesis. Individual observations are first written as separate evidence statements, then grouped by similarity and named. Teams should preserve traceability by linking themes to interview excerpts, field notes, recordings, or survey results. Without traceability, a polished insight can become an unsupported opinion.

Triangulation compares evidence from different methods, researchers, participant groups, or data sources. If interviews, observation, and analytics point to the same difficulty, confidence increases. Contradictions are also valuable. A participant may report satisfaction while analytics show repeated failed attempts; this discrepancy should prompt further investigation rather than selective reporting.

Quantitative analysis may include frequencies, distributions, cross-tabulations, averages, medians, and relationships between variables. The chosen statistic must fit the measurement scale and study design. Descriptive results should not be presented as causal findings unless the design supports causal inference. A survey showing that mobile users report more difficulty does not by itself establish that the device caused the difficulty.

An insight connects evidence to an implication. For example: “Applicants often leave the form to locate information because eligibility rules are presented after the first commitment step.” The associated design implication might be to expose eligibility criteria earlier, not simply to “make the form easier.” Insights should be specific enough to guide decisions and cautious enough not to exceed the evidence.

Personas, Jobs-to-be-Done, and Requirements

A persona is a research-based representation of a meaningful user pattern. It describes goals, behaviours, capabilities, constraints, and context. A persona should not be a fictional biography decorated with stock photography. Its purpose is to help a team remember evidence when making design decisions.

Effective personas are based on behavioural variables rather than superficial demographic categories alone. Two people of the same age may have entirely different goals, confidence levels, access conditions, and usage patterns. A persona should state its evidence base, distinguish observed characteristics from hypotheses, and be revised when new evidence changes the understanding.

The jobs-to-be-done perspective focuses on the progress a person is trying to make in a situation. A job statement often follows the pattern: “When [situation], I want to [motivation], so I can [expected outcome].” For example: “When I receive a service notification while travelling, I want to confirm its legitimacy quickly, so I can decide whether action is required.” The job is not a feature such as “use push notifications”; it is the outcome sought by the user.

Personas provide a human and contextual view, while jobs-to-be-done emphasises purpose and progress. Used carefully, they complement rather than replace one another. Neither should be treated as an objective truth independent of evidence.

Requirements translate user and organisational needs into conditions the product must satisfy. Common categories include:

• functional requirements: capabilities the system must provide;
• content requirements: information, labels, instructions, and messages needed;
• usability requirements: learnability, efficiency, memorability, and error recovery;
• accessibility requirements: support for diverse sensory, motor, cognitive, and technological conditions;
• responsive requirements: behaviour across screen sizes, input modes, orientations, and network conditions;
• performance and security requirements: speed, reliability, privacy, authentication, and protection of data;
• business and governance requirements: policy, compliance, operational, and measurement needs.

A useful requirement is clear, testable, prioritised, and traceable to evidence. “The mobile form should be user-friendly” is vague. “A returning applicant using a mobile viewport should be able to save progress and resume without re-entering previously validated information” is more actionable and testable.

User stories can express requirements from a user perspective, but they should not replace acceptance criteria. A story such as “As an applicant, I want to save my form so that I can finish later” should be accompanied by conditions covering save behaviour, confirmation, data security, resumption, expiry, and error handling.

Prioritisation methods such as MoSCoW, opportunity scoring, risk-based ranking, or value-versus-effort mapping help teams make trade-offs. Prioritisation should consider user impact, business value, evidence strength, technical effort, legal obligations, and consequences of failure. Legally or ethically essential requirements must not be treated as optional merely because they are difficult.

Validating Requirements

Requirements are validated through multiple forms of evidence. Stakeholder review checks organisational fit; user walkthroughs test whether the wording reflects real goals; prototypes reveal interaction problems; usability tests examine whether people can complete tasks; technical spikes assess feasibility; and analytics or experiments evaluate outcomes after release.

Validation should address at least four questions: Is the requirement needed? Is it understood consistently? Is it feasible within relevant constraints? Can its fulfilment be verified? A traceability matrix can connect each requirement to its source evidence, owner, priority, design artefact, implementation item, and validation method.

A requirement may be valid but incomplete. For responsive web products, validation should consider narrow and wide viewports, touch and keyboard input, zoom, orientation changes, slow connections, assistive technologies, and content expansion. The aim is not to design separate products for each device, but to ensure that the underlying task remains usable across changing conditions.

Ethical and Governance Considerations

Ethical research respects autonomy, privacy, dignity, safety, and fairness. Participants should receive understandable information about the purpose, procedures, risks, recording, data use, withdrawal rights, incentives, and contact arrangements. Consent must be voluntary and appropriate to the participant’s capacity and situation. Researchers should obtain additional safeguards when working with children, employees who may feel pressured, or people discussing sensitive experiences.

Data minimisation is central to responsible research. Collect only information necessary for the stated purpose, restrict access, remove direct identifiers where possible, establish retention periods, and use secure storage. Recordings and transcripts can contain names, account details, health information, or workplace secrets. Researchers should not casually upload such material to third-party AI services or transcription tools without checking contractual, legal, and organisational controls.

Privacy regulations differ by jurisdiction, but sound practice generally includes purpose limitation, transparency, appropriate security, and respect for data-subject rights. Research teams should consult institutional policies and applicable law rather than assuming that anonymisation is automatic. Small samples can be re-identifiable when unusual roles or circumstances are described.

Research ethics also includes interpretive fairness. Teams should avoid deficit-based personas, stereotyping, selective quotation, and designing only for the most vocal participants. Accessibility is both an ethical responsibility and a quality requirement. Users with disabilities should be included as participants where relevant, and their experiences should not be treated as edge cases without examining the assumptions built into the product.

Technology, Analytics, and AI in Research

Digital tools support recruitment, scheduling, remote interviews, transcription, survey distribution, analytics, repository management, and collaborative synthesis. Product analytics can reveal funnels, repeated errors, search terms, device patterns, and abandonment points. Analytics shows what happened at scale, but usually not why. Combining event data with interviews or observation creates a stronger explanation.

AI can assist with transcription, clustering, draft coding, summarisation, and identification of recurring language. It should remain an aid rather than an autonomous researcher. Researchers must check transcription accuracy, preserve context, examine minority or contradictory cases, and document how automated outputs were used. Sensitive research data should not be entered into systems whose storage, training, access, or deletion practices are unclear. Human accountability remains essential for recruitment decisions, interpretation, prioritisation, and reporting.

An Illustrative Case: Improving a Public-Service Application Portal

Background

A fictional municipal service, CityPermit, allows residents to apply online for parking permits. The service is responsive and available on desktop and mobile devices. Completion rates are lower on mobile, and support staff report that applicants frequently ask whether they are eligible before beginning.

Situation and Problem

The product team proposes adding a conversational assistant to answer questions. However, the evidence is insufficient to conclude that a chatbot is the right solution. The research objective is to understand where applicants experience uncertainty, how they gather required information, and what conditions affect completion.

Analysis and Approach

The team defines three questions: What eligibility information do applicants seek before starting? Where do users abandon or repeat steps? How do device, interruption, and document access affect the task?

A purposive sample includes first-time and returning applicants, residents who use mobile devices, people who assist another household member, and applicants with different levels of digital confidence. The team conducts eight semi-structured interviews, six contextual inquiries during actual application attempts, a survey of recent applicants, and a comparative review of three similar portals. Participants receive an explanation of recording and data use; names and permit details are excluded from research files.

Observation reveals that applicants often switch between the portal and photographs of vehicle documents. Several users interpret “residential address” differently from the policy definition. On mobile screens, the eligibility link is visually secondary and appears after a prominent start button. Interviews show that users want confidence before investing time, not necessarily a conversational interaction. Survey responses indicate that uncertainty about documents and eligibility is more common than difficulty understanding the form controls, although the survey sample is self-selected.

The team synthesises the evidence into a persona representing “the cautious first-time applicant” and a job-to-be-done: “When applying under time pressure, I want to confirm eligibility and required documents before starting, so I can avoid an incomplete submission.” Requirements are prioritised as follows: present eligibility and document requirements before commitment; allow users to save and resume; provide clear mobile validation and recovery; support keyboard and screen-reader access; and explain how submitted information is protected.

Solution and Validation

Instead of immediately building a chatbot, the team prototypes a pre-application eligibility checker, a concise document checklist, and a save-and-resume flow. Usability sessions compare the revised flow with the original. Participants complete the eligibility task more confidently and make fewer avoidable transitions away from the portal. A later pilot measures completion, support contacts, and errors while monitoring whether users understand the limits of the eligibility checker.

Outcome and Learning Points

The case demonstrates why research should precede solution commitment. The proposed chatbot might have added complexity without addressing the primary uncertainty. Triangulation revealed a problem involving content hierarchy, policy language, document preparation, and mobile interruption. The outcome is not merely a feature list; it is a set of validated requirements linked to user goals, evidence, and measurable outcomes.

Common Errors and Professional Best Practices

Several failures recur in research programmes. Teams sometimes begin with a preferred solution, recruit convenient colleagues, ask leading questions, treat opinions as requirements, overgeneralise from a small sample, or report only evidence that supports an existing strategy. Another error is producing attractive personas that lack traceable evidence. In development, requirements may be handed over as static documents without ongoing validation, causing important findings to disappear during delivery.

Professional practice counters these problems by:

• starting with decisions and uncertainty rather than features;
• combining methods according to the claim being investigated;
• recruiting for relevant variation and documenting limitations;
• separating observations, interpretations, and recommendations;
• preserving links between evidence and requirements;
• including accessibility, privacy, security, and responsive conditions early;
• involving designers, developers, product owners, and domain experts in synthesis;
• testing requirements before expensive implementation;
• revisiting findings as the product, policy, or user context changes.

Research is most influential when it is integrated into decision-making. A research report that no stakeholder can connect to prioritisation has limited organisational value. The researcher’s professional role therefore includes communicating uncertainty, making evidence understandable, and helping teams act without overstating what the data proves.

Current Developments

Contemporary research practice is becoming more continuous, remote, inclusive, and evidence-integrated. Remote moderated sessions can reach geographically distributed participants, while unmoderated studies and in-product prompts support rapid feedback. Privacy-preserving analytics and improved accessibility testing are gaining importance as organisations recognise the risks of collecting excessive behavioural data.

Product teams increasingly combine qualitative repositories, quantitative dashboards, design systems, and requirement-tracking tools. This integration can improve traceability but also creates governance challenges: data may be reused beyond its original purpose, automated summaries may conceal minority experiences, and dashboards may encourage teams to optimise measurable activity rather than meaningful outcomes. Mature practice treats technology as infrastructure for judgement, not a substitute for it.

Chapter Summary

User research establishes an evidence-based understanding of users, contexts, behaviours, and needs. Qualitative methods such as interviews, observation, and contextual inquiry explain experience and motivation, while surveys and analytics help describe patterns at greater scale. Competitive analysis reveals conventions and strategic alternatives but cannot replace direct user evidence.

Effective research begins with a decision and focused research questions. Sampling should reflect relevant user variation, and ethical recruitment, consent, privacy, and inclusion are essential. Analysis requires disciplined coding, thematic synthesis, triangulation, and transparent separation of evidence from interpretation. Personas and jobs-to-be-done provide complementary ways to represent users and desired progress. Requirements must be clear, testable, prioritised, traceable, and validated through design, technical, and user evidence. In responsive web development, validation must include different devices, inputs, accessibility needs, and real-world conditions. AI and analytics can support research, but human judgement, governance, and accountability remain indispensable.

Key Terms

User research: Systematic investigation of users, behaviours, needs, and contexts to inform product decisions.

Qualitative research: Research focused on meanings, experiences, behaviours, and explanations using non-numerical evidence.

Quantitative research: Research that measures variables and patterns using numerical data.

Generative research: Exploratory research used to discover needs, problems, and opportunities.

Evaluative research: Research used to assess an existing design, prototype, or service.

Research question: A focused, answerable question that directs data collection and analysis.

Purposive sampling: Selecting participants because they possess characteristics relevant to the research purpose.

Saturation: The point at which additional qualitative data produces little substantially new insight.

Semi-structured interview: An interview guided by planned topics while allowing flexible discussion.

Contextual inquiry: Observation and questioning conducted while a participant performs real work in context.

Survey bias: Systematic distortion caused by sampling, wording, non-response, or response conditions.

Competitive analysis: Structured comparison of competing or substitute products, services, and experiences.

Triangulation: Comparing evidence from multiple methods, sources, researchers, or participant groups.

Persona: An evidence-based representation of a meaningful user pattern.

Jobs-to-be-done: A perspective that describes the progress a user seeks in a particular situation.

Requirement: A documented condition or capability that a product or service must satisfy.

Acceptance criteria: Testable conditions used to determine whether a requirement has been fulfilled.

Traceability: The ability to connect a requirement to its evidence, design, implementation, and validation.

Data minimisation: Collecting and retaining only the personal data necessary for a legitimate purpose.

Research synthesis: The process of organising evidence into patterns, insights, implications, and decisions.

Review Questions

Short Answer Questions

1. How do qualitative and quantitative research differ in the kinds of claims they support?

2. What is the purpose of a research brief?

3. Why is purposive sampling commonly used in qualitative UX research?

4. Define contextual inquiry and state one situation in which it is useful.

5. What makes a requirement testable?

Long Answer Questions

1. Explain how a product team can move from a broad business problem to focused research questions and a sampling plan.

2. Compare interviews, observation, surveys, and competitive analysis, including the strengths and limitations of each.

3. Describe a systematic process for analysing qualitative research data and developing trustworthy insights.

4. Explain how personas and jobs-to-be-done differ and how they can be used together in product planning.

5. Discuss ethical, privacy, accessibility, and governance responsibilities in user research.

Analytical / Application Questions

1. A team believes users need a chatbot because support requests are increasing. Design a mixed-method research plan that tests the underlying problem without assuming the solution.

2. A survey reports high satisfaction, but analytics show repeated form errors and abandonment on mobile devices. Analyse possible explanations and propose follow-up research.

3. Create three evidence-based requirements for a responsive online application service, including acceptance criteria and a method for validating each requirement.

22. Multiple Choice Questions with Answers

Question 1

A product team wants to understand why users abandon a mobile application form after switching to another app. Which method is most appropriate for initially understanding the interruption and surrounding circumstances?

A. Contextual inquiry

B. A logo preference survey

C. A competitor feature list

D. A post-release A/B test only

Correct Answer: A. Contextual inquiry

Question 2

Which statement best distinguishes a research question from a business problem?

A. A research question identifies an observable uncertainty that evidence can investigate.

B. A research question is always expressed as a financial target.

C. A research question prescribes the final interface solution.

D. A research question avoids specifying a user group or context.

Correct Answer: A. A research question identifies an observable uncertainty that evidence can investigate.

Question 3

A researcher wants to learn how widespread a previously identified usability problem is across a large user population. Which approach is most suitable?

A. A structured survey with a defined target population

B. One unrecorded interview with a product manager

C. An informal design critique

D. A single contextual observation

Correct Answer: A. A structured survey with a defined target population

Question 4

Which is the strongest example of an evidence-based requirement?

A. The website should be user-friendly.

B. The interface should look modern.

C. A returning applicant should be able to save and resume a form without re-entering validated information.

D. Users should enjoy the application process.

Correct Answer: C. A returning applicant should be able to save and resume a form without re-entering validated information.

Question 5

What is the principal value of triangulation in UX research?

A. It guarantees that every participant gives the same answer.

B. It compares evidence from different sources or methods to strengthen or question interpretations.

C. It replaces the need to document research data.

D. It ensures that qualitative research becomes statistically representative.

Correct Answer: B. It compares evidence from different sources or methods to strengthen or question interpretations.

Question 6

A persona is methodologically weak when it:

A. Describes behavioural patterns supported by several participants.

B. States its evidence base and relevant user context.

C. Uses a fictional name to make a research pattern memorable.

D. Presents unsupported demographic stereotypes as if they were research findings.

Correct Answer: D. Presents unsupported demographic stereotypes as if they were research findings.

Question 7

Which job-to-be-done is best formulated?

A. Add a chatbot to the help page.

B. Use blue buttons for important actions.

C. When travelling, confirm whether a service notification is legitimate so I can decide what action is required.

D. Build a responsive website with five pages.

Correct Answer: C. When travelling, confirm whether a service notification is legitimate so I can decide what action is required.

Question 8

A survey asks, “How satisfied are you with the speed and clarity of the service?” What is the main methodological problem?

A. It asks about two attributes in one question.

B. It contains no adjective.

C. It is necessarily an open-ended question.

D. It cannot be answered by existing users.

Correct Answer: A. It asks about two attributes in one question.

Question 9

Which practice best reflects responsible use of AI in research?

A. Accepting automated themes without checking source data

B. Uploading sensitive recordings to any free tool for convenience

C. Using AI for preliminary transcription or clustering while checking accuracy, context, privacy, and minority cases

D. Allowing an AI system to make final recruitment and prioritisation decisions without human review

Correct Answer: C. Using AI for preliminary transcription or clustering while checking accuracy, context, privacy, and minority cases

Question 10

In the CityPermit case, why was a pre-application eligibility checker prioritised over immediately building a chatbot?

A. Chatbots are never appropriate for public services.

B. Research indicated that users primarily needed confidence about eligibility and documents before starting.

C. The team wanted to remove all written content from the portal.

D. The survey proved that every applicant preferred a checklist.

Correct Answer: B. Research indicated that users primarily needed confidence about eligibility and documents before starting.