User research is the practice of gathering evidence about a target audience—their needs, behaviors, attitudes, and problems—so a website or application solves a real need rather than an assumed one. An idea can begin as a hypothesis, but assumptions are not data. Research helps teams choose a solution based on what prospective or current users actually need and then check whether later changes improve the experience. section 4.1 section 3.3.1
Use research as a foundation before design, not as a final approval step. Early findings define the audience, clarify needs, and inform site objectives. They feed into user experience design decisions such as content organization, labels, navigation, page flow, wireframes, and eventually visual design. Starting late can reveal that a finished interface is difficult to navigate or addresses the wrong problem, forcing expensive redesign and rebuild work. section 4.1.2 section 4.1.1 section 5.4
Figure 1.3 The iterative process this book covers for a web design or web application project—from identifying the problem to user research, user experience design, design and build phase, and test and evaluate
Research begins an iterative cycle: identify a problem, learn from users, shape the experience, design and build, then test and evaluate. When results show unmet needs, return to research and refine rather than treating launch as the end. section 1.2.1 section 4.2.4
Choose methods according to the question and the project stage. Research can be qualitative or quantitative, and can focus on what people say they think or on what they actually do. A new product may begin with conversations because it has little numerical data. An established product may have analytics that reveal a problem but still need qualitative work to explain it. Compare the results: disagreement between methods is a signal to investigate a possible user disconnect. section 4.2 section 4.3
A practical research cycle can be kept lightweight:
- Define the target audience and the problem or need to investigate; for a new product, gather initial evidence before designing. section 4.1.2
- Use interviews, focus groups, or surveys to collect early qualitative information and form hypotheses. section 4.1.2
- Review competitors when there is no prototype yet, asking what they provide or fail to provide for potential users. section 4.1.2
- Pair numerical measures such as analytics with qualitative questions, using each to check the other. section 4.3
- Test designs, prototypes, launched features, or an MVP with the target audience; use feedback and measures to guide the next iteration. section 3.3.1 section 4.2.4
Card sorting for navigation
Card sorting is a low-cost way to research information architecture. Put main content topics on cards or sticky notes and ask at least three users to group them as they expect to find them. In an open card sort, users also name each group; those names can suggest navigation labels. In a closed sort, users place topics into predefined categories. Look for repeated groupings and differences to shape the site’s content structure. section 4.2.3
Avoiding late discovery
Imagine building a client web application from interface to backend without research, then interviewing users just before launch. If they say the solution misses their needs and is hard to use, the team may need to revise the design and architecture, delaying launch and increasing cost. Research earlier in the cycle reduces the risk of this kind of rework. section 4.1.1
Research is continuous rather than a one-time discovery phase. After release, watch whether people adopt a feature, abandon it, or leave quickly, and keep interviewing target users when a product evolves. This keeps users central through development and helps teams decide what to change next. Even teams without a dedicated researcher or a formal research budget need a plan to test and gather feedback before judging an experiment successful. section 3.3.1 section 11.2.5 section 1.1.5
