Gathering Requirements Through User Research: Interviews, Surveys and Observation
Requirements gathering is where any requirements analysis starts. Nielsen Norman Group (NN/g) points out that nearly every project benefits from combining several user research methods, yet many teams rely on only one or two they know best. The real question is not "which method is best" but "when to use which." NN/g lays out a three-dimensional framework: attitudinal vs. behavioral, qualitative vs. quantitative, and context of use.
Attitudinal vs. behavioral: what people say vs. what people do
Attitudinal research answers "what people say" and measures stated beliefs, but it is limited by what people are aware of and willing to report. Behavioral research answers "what people do" by observing real use. The two often diverge sharply. Usability studies and field studies sit between them — they collect both self-reported and behavioral data, and NN/g recommends leaning toward the behavioral side.
- Interviews: a researcher meets participants one-on-one to explore motivations, pain points and decisions in depth — a classic attitudinal method.
- Field studies / contextual inquiry: observe and question users in their real work or home environment to understand tasks and processes — closer to the behavioral side.
- Surveys: structured questions that measure attitudes and collect self-reported data, useful for surfacing and tracking important issues, but they should stay short.
Qualitative vs. quantitative: explaining "why" vs. answering "how many"
Qualitative research produces data about behavior or attitudes through direct observation or listening, and is best at answering "why" and "how to fix it." Quantitative research gathers data indirectly through measurement or instruments such as surveys or analytics, and answers "how many" and "how much." Those numbers help teams allocate resources to the issues with the biggest impact.
- Card sorting and tree testing: help users organize information according to their mental models, used to build or validate information architecture.
- A/B testing: presents different designs to random samples while holding everything else constant, to see the effect on behavior.
- Analytics: analyzes behavior logs such as clicks and form fills, which requires proper instrumentation in advance.
Context of use and product phase
The third dimension is whether and how participants use the product: natural use, scripted use, limited use, or no use (decontextualized). Methods also shift across the product-development timeline — generative research (explore direction), formative research (improve design), and summative research (measure performance). NN/g maps 20 popular methods across this framework, for example:
| Stage | Goal | Representative methods |
|---|---|---|
| Strategize / generative | Find new directions and opportunities | Field studies, diary studies, interviews, surveys, concept testing |
| Design / formative | Improve design usability | Card sorting, tree testing, usability testing, remote testing |
| Launch / summative | Measure against itself or competitors | Usability benchmarking, A/B testing, clickstream/analytics, surveys |
Two methods deserve special mention. Diary studies ask users to log their usage over days or weeks, capturing daily details that a one-off interview misses — great for exploring friction in long-term use. Remote usability testing uses screen sharing so users in different cities can complete specified tasks, at a fraction of the cost of an in-person lab, making it the highest-value formative research tool for small teams.
How small site-building teams get started
Small teams building a website or SaaS product do not need to run every method at once. Treat "requirements gathering" as a low-cost pipeline:
- Interview 5-8 target users with open-ended questions to understand real scenarios (attitudinal side).
- Use surveys or on-site feedback to widen the sample and quantify which pain points matter most.
- Validate with observation and analytics: check back-end clicks, retention and support tickets to confirm behavior matches what people said.
- Turn the findings into a requirements list, then move on to PRD writing and prioritization.
An interview script does not need to be elaborate — five to eight open-ended questions are enough. For a "site-building tool for indie developers," for example, try questions like:
- How do you build websites today, and how long does the whole process take?
- Where did you get stuck last time, and for how long?
- If you could improve one thing, what would it be?
- What would your ideal site-building flow look like?
Open-ended questions let users describe their own context instead of steering them with "do you need feature X." After the interviews, transcribe the recordings and tag them by "pain point / scenario / expectation." With five to eight people, highly repeated patterns usually emerge — those are the requirements worth building first.
After launch, support tickets and user feedback are the cheapest source of behavioral data — see the Customer Service Platform Guide. In the AI era you can also turn "what good looks like" into a runnable acceptance standard with an evaluation dataset, so requirements keep being validated on every iteration.
16IDC perspective
For website and SaaS projects, the value of requirements gathering is in turning fuzzy ideas into testable hypotheses. The useful part of NN/g's framework is that it forces you to answer three questions at once: what users say, what they do, and in what context. For a more systematic workflow, see the Requirements Analysis category on this site.
Source: https://www.nngroup.com/articles/which-ux-research-methods/; more methods in NN/g's UX research cheat sheet https://www.nngroup.com/articles/ux-research-cheat-sheet/; usability testing 101 https://www.nngroup.com/articles/usability-testing-101/