Pick the right user research method

Overview

This article walks through Decode's User Research methods and where each one fits, based on what you have and what you're trying to learn.

Prototype testing

Prototype testing works from a design that hasn't been built yet, a Figma prototype, rather than a live product. Participants navigate the prototype to complete a task, and Decode records every screen they visit, every click, and how long they spend at each step. You can either define the exact path you expect people to follow and see whether they stick to it, or let them navigate freely and discover the paths they take on their own.

This is the method to reach for early, before development, when a wrong assumption is still cheap to fix. For example, a team redesigning a checkout flow can test the Figma version first, see where people hesitate or take a wrong turn, and correct the design before a single line of code is written.

Task research

Task research works the same way as Prototype testing, participants complete a task while their session is recorded, but on a real, live website or app instead of a mockup. This matters because a prototype can behave differently from the finished product, load times, real content, and actual system behavior all affect how people navigate.

Use this once something already exists and you want to know how it performs in practice. For example, an e-commerce team with a live site can give participants the task "find a product and add it to your cart" and see exactly where the real experience breaks down, not a simulated version of it.

A/B & preference testing

This method shows participants two or more versions of something directly and measures which one they choose or complete more successfully. Unlike Prototype or Task research, which focus on the full journey through a design, A/B & preference testing isolates a single comparison, this version versus that one, so you can settle a specific decision with data rather than opinion.

For example, a team deciding between two pricing page layouts can run both versions and see which one participants engage with more, without needing to test either one's full navigation flow.

Information architecture

Information architecture testing, done through card sorting, shows you how people naturally group and label your content, rather than how your team has organized it internally. Participants sort items into categories that make sense to them, revealing the mental model your actual users have, which may not match your assumptions.

This is most useful before you build navigation or restructure a site, when getting the underlying structure right saves you from having to fix a confusing menu later. For example, a team restructuring a website's navigation can run a card sort to see whether users would naturally group "Billing" under "Account" or under "Settings," rather than guessing.

Quick UX methods

First-click and 5-second tests are lightweight, fast alternatives to a full study. A first-click test shows whether people click the right place first, when trying to complete a task, useful for testing whether a layout guides attention correctly. A 5-second test shows a screen briefly and asks what people remember, useful for testing whether a message or headline lands quickly.

Use these when you need a directional answer fast, not the full depth of Prototype or Task research, for example, checking whether a new headline draws attention before committing to a larger study around it.

Video response testing

Instead of typed answers, participants respond by recording themselves on video. This captures tone, emotion, and nuance that a text box can't, someone explaining their frustration with a feature often conveys more in how they say it than in a written summary of the same thought.

Use this when the emotional context behind a response matters as much as the content of it, for example, understanding not just that users are confused by a feature, but how confused, and what that confusion sounds like.

Moderated user research (live)

A live moderator runs the session in real time, able to ask follow-up questions based on what a participant actually says, rather than following a fixed script. This is the method best suited to genuinely open-ended exploration, where you don't yet know what the interesting question even is.

Use this when your research question is exploratory rather than confirmatory, for example, understanding why a segment of users churns, where the reasons could be anything, and a scripted survey would miss whatever you didn't think to ask about.

Still unsure?

See What is User Research in Decode for a broader description of how these methods fit together.