liveBook · Manning

User testing

As explained in Design for Developers

User testing is the evaluation of a product or design by observing representative users perform tasks and collecting their responses.

User testing checks whether people can use a design or product as intended. It replaces guesses with feedback: watch people work through tasks, ask about their experience, and use what you learn to improve the next version. For websites and web applications, this makes user experience part of development decisions rather than something considered after code ships. section 1.1.5 section 4.2.3

Usability testing is a task-based form of user research. Participants use a product while you observe them. Testing can happen before development with clickable wireframes or mock-ups, or on an existing site when data suggests that people are struggling. Starting before implementation can expose design problems before they require code changes. section 4.2.3

A practical testing cycle is:

  • Check that the design meets the project’s initial requirements and that the MVP has approval; do not wait for a perfect design. section 11.1.3
  • Choose the experience and task flow to test, such as finding a call to action or completing a step in a user flow. section 11.2.1
  • Give people a task, observe the steps they take, and ask follow-up questions about confusion, navigation, hierarchy, or visual elements. section 11.1.1 section 11.2.1
  • Record detailed notes, or record the session with permission, so feedback can be reviewed accurately. section 11.2.1
  • Prioritize the problems found, update the design, and test again as needed before release. section 11.1.1 section 1.1.5

Testing a replacement design

When replacing a live experience, ask users to complete task flows in a staging environment. Observe how they use the new design and ask questions, then prioritize problems before release. The goal is not simply to collect opinions; it is to confirm that the new experience does not make tasks harder, increase negative feedback, or harm outcomes such as sales. section 11.1.1

Testing also helps explain quantitative signals. If telemetry shows people opening a tool and leaving within 10 seconds, use that pattern as a starting point for a qualitative usability study. Prepare tasks and questions that help reveal why the behavior occurs. Surveys can reach more people, but their questions should not lead participants toward a favorable answer, because biased responses can distort later decisions. section 4.2.3 section 4.2.3

Testing belongs in an iterative process that connects research, design, prototyping, development, and measurement. Even teams without a dedicated researcher or a large budget need a plan for gathering feedback and using it to adjust a feature. Testing early and revising deliberately can support faster pivots, fewer production bugs, and a more user-centered product. section 1.1.5 section 3.3

How Design for Developers covers it

How deep it goes
Explains task observation, prototype and live-site testing, interview prompts, notes, prioritization, and retesting without implementation internals.
Examples
Uses clickable wireframes, PowerPoint screen flows, telemetry-driven tool abandonment, and staging tests of replacement designs.
What it assumes
Starts from project requirements and MVP approval while introducing testing practices for teams without formal research resources.
What you can do after
Apply it by preparing tasks, observing users, gathering feedback, prioritizing problems, and revising a design before release.
How it connects
Connects user testing with user research, usability testing, prototyping, telemetry data, surveys, A/B testing, and user flows.

Also explained in

Compare how 3 books explain user testing →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Design for Developers. The section links point to the parts of the book it draws on.