Skip to content
tezvyn:

Generative versus evaluative research: when to use each

Source: lyssna.comMediumHow cards are made

Generative versus evaluative research: when to use each
Summary

Knowing when to explore problems vs validate solutions by phase.

Key points

Generative precedes design to find needs; evaluative follows a build to test it.

Watch out for

Treating research as one phase or saying testing only happens last.

What's really being asked

This question checks if you understand research as a strategic timing decision rather than a checkbox. Senior engineers are expected to know that generative research explores user needs and behaviors before solutions exist, while evaluative research measures how well a product meets those needs after something is built. The interviewer wants to see that you can align research phases with design and development milestones, and that you know why skipping generative work leads to building the wrong thing efficiently.

The full answer

First, define generative research as exploratory or discovery work that happens before any technical design to uncover problems, user mental models, and opportunity spaces. Second, define evaluative research as assessment or validation work that happens once an initial version exists to test usability, task success, and solution fit. Third, explicitly map them to the project timeline: generative before initial technical design to inform requirements, evaluative after a build to refine and iterate. Fourth, note that the two are complementary, not interchangeable, and that combining them prevents wasted engineering effort.

The mistakes people make

A major red flag is saying all user research is the same or that testing only happens at the end. Another is claiming generative research is unnecessary because product managers or engineers already know the user problem. Some candidates describe evaluative methods like usability testing but cannot explain what generative methods look like, such as ethnographic interviews or diary studies. Treating research as a single phase rather than an ongoing discipline also signals inexperience.

What usually comes next

The interviewer may ask which specific methods fit each bucket, such as contextual inquiry for generative versus usability testing for evaluative. They might ask how to advocate for generative research when leadership wants to ship fast, or how you would run evaluative research on a backend-heavy feature with no UI. Another follow-up is how you measure the ROI of generative research when it takes four to eight weeks.

A concrete example

Imagine your team wants to build a money-saving app for millennials. Before writing any technical design documents, you conduct generative interviews and diary studies to learn how millennials think about savings, what triggers their financial anxiety, and what tools they currently hack together. This shapes the feature set and architecture. After releasing an MVP budget tracker, you run evaluative usability tests and analyze task completion rates to see if users can set savings goals without confusion. The generative phase prevented building a feature nobody needed; the evaluative phase fixed interaction bugs before scale.

Interview question

After releasing an MVP export feature, a team wants to know if users can successfully complete exports. Which research approach fits best?

  • a.Interviewing users about how they currently share data before the feature existed
  • b.Measuring task success and observing friction while users try the export flowCorrect
  • c.Observing users in their offices to understand how exported reports fit into workflows
  • d.Having users keep a diary about their overall reporting needs over two weeks
Why?

Once an MVP exists, evaluative research such as usability testing measures task success and solution fit. Observing how reports fit into workflows is a generative method meant to uncover needs before design begins, so it does not validate whether the new export flow actually works.

Just read this? Test yourself on what you have been reading.

Read the original → lyssna.com

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on ux research — each one lists the topics its interview covers.

See open roles