Skip to content
tezvyn:

Describe heuristic evaluation and two heuristics that guide UI components

Source: nngroup.comEasyHow cards are made

Describe heuristic evaluation and two heuristics that guide UI components

Tests if you bridge UX research and frontend decisions. Define heuristic evaluation as expert review against rules of thumb, cite two NN/G heuristics, and map each to a concrete component behavior. Red flag: listing heuristics without code impact.

What's really being asked

This question checks whether you treat usability as an engineering constraint rather than a design afterthought. Senior engineers are expected to know how to evaluate interfaces systematically and to justify component-level choices with established UX principles instead of personal taste.

The full answer

First, define heuristic evaluation as an expert review method where trained evaluators or developers inspect a user interface against a set of broad rules of thumb to find usability problems without running a full user study. Second, select two heuristics from the Nielsen Norman Group ten and map each directly to a component decision. A strong pairing is Visibility of System Status and Error Prevention. For Visibility of System Status, explain that the component must communicate its state immediately through appropriate feedback within a reasonable time, such as showing a loading skeleton during data fetch, a progress bar during file upload, or a success toast after completion, so users know the system received their input and is working. For Error Prevention, explain that the component should add guardrails rather than relying solely on error messages after the fact, such as disabling a submit button until form validation passes, using constraints to prevent invalid input, or adding a confirmation dialog before a destructive delete action. Third, briefly note that heuristic evaluation is inexpensive and fast compared to user testing, making it useful early in the development cycle when you want to catch obvious issues before shipping code to users.

The mistakes people make

Confusing heuristic evaluation with A/B testing, analytics, or user interviews. Naming vague principles like make it intuitive or keep it clean that are not among the established NN/G heuristics. Listing heuristics without connecting them to concrete component states, props, event handlers, or interactions. Claiming that heuristics replace user research rather than complement it, since expert reviews do not capture real user mental models or edge cases.

What usually comes next

How would you prioritize fixes if a heuristic evaluation surfaces twenty issues? When would you choose heuristic evaluation over usability testing with real participants? Can you give an example where following a heuristic too rigidly actually hurt the user experience? How do you apply these principles consistently across a design system or component library?

A concrete example

Consider a bulk delete button inside a data table. Applying Visibility of System Status means the button enters a processing state, the affected rows dim immediately after click, and a toast confirms completion so users know the system is working and when it is done. Applying Error Prevention means the button is disabled when no rows are selected, a confirmation modal requires typing the number of items to be deleted, and the modal defaults to cancel rather than confirm, preventing accidental data loss.

Interview question

Which approach best represents heuristic evaluation when auditing a file-upload component without running a user study?

  • a.Split-test two upload button colors and compare conversion rates
  • b.Track click-through rates on the upload button to identify drop-off points
  • c.Have an expert check the component against NN/G heuristics like showing a progress bar and disabling submit for invalid filesCorrect
  • d.Interview five users about their upload workflow frustrations
Why?

Heuristic evaluation is an inexpensive expert review against established NN/G heuristics that maps directly to component behaviors such as progress bars and disabled states. Interviewing users is a tempting distractor because it gathers feedback without a full study, but it is a distinct research method rather than an expert audit against rules of thumb.

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

Read the original → nngroup.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