55 resources from Nielsen Norman Group we point founders to, and the questions each answers.
📄 Article
✓ Link checkedFreeBeginner
Why we picked it
The single most-cited usability framework in the field, from the definitive UX research authority. A checklist you can hold your product up against this afternoon.
Why we picked it
This piece sorts research methods along attitudinal versus behavioral and qualitative versus quantitative, so you can see exactly where interviews and surveys each sit. The line that matters for you: qualitative methods (interviews) answer why and how to fix, while quantitative methods (surveys) answer how many and how much. That framing tells you a survey is not good enough at the start because the start is a why question.
Interviews are qualitative and attitudinal, best for understanding why people behave a certain way and uncovering problems you did not know to ask about.
Surveys are quantitative and attitudinal, best once you already know the questions and want to measure how common an answer is across many people.
Early on you usually do interviews first to find the real questions, then use surveys later to size and confirm what you learned.
Why we picked it
This is the cleanest, most concrete catalogue of the exact question shapes that quietly steer a person to the answer you already want. It names five specific traps (rephrasing what you think you saw, assuming a problem and blaming the user, suggesting the answer, naming interface elements the user never used, and assuming their emotions) and gives a neutral rewrite for each, so you can pattern-match your own script before an interview. It stays practical rather than academic, which is the right altitude when you are about to sit across from a real customer.
Leading questions bury the answer you want inside the question, so people mirror your words instead of telling you what actually happened.
The fixes are specific: swap suggested outcomes ("how well did this save you time?") for open ones ("what was easy or hard about this?"), and never name a feature the user has not named first.
Watch for questions that assume an emotion or a problem ("when you were struggling..."), because they quietly plant a reality that may not be true for that person.
Why we picked it
This is the piece that gives you permission to stop waiting for a big study. Nielsen shows that just five people uncover roughly 85 percent of the usability problems in your app, and that running several small tests beats one large one because you can fix things between rounds. For a founder with no budget, it reframes testing from a scary research project into something you can do this week.
Why we picked it
Nielsen Norman Group is the closest thing to a standard reference in usability, and this piece is a clean, specific checklist for turning a scary or vague error into something a user can actually act on. It groups the patterns into visibility, communication, and efficiency, with concrete phrasing rules like describe exactly what went wrong, offer a fix, and never blame the user. It is a good starting point you can hold your own error copy up against, not abstract theory.
Why we picked it
This is the plain, research backed baseline for the whole question: it draws the line between translating an interface and actually localizing it, which is exactly where most multilingual apps quietly break. It walks through why the same screen behaves differently across languages and cultures, and pushes you toward testing with real users in the target language rather than guessing. Treat it as your starting frame before you touch a single string.
Translation swaps the words while the layout stays put, localization reworks the design so it still reads and feels right in each language, and the two are not the same job.
Non native speakers lean hard on visual cues (icons, imagery, layout) to navigate a screen in a language they are shaky in, so text alone is a weak crutch.
Do not trust your assumptions about a culture or language, run usability testing with people who actually live in it.
Why we picked it
Most branding advice is one designer's taste, this is the opposite: a short, research-backed walkthrough from Nielsen Norman Group of what actually makes visitors decide a site is credible enough to stay on. It gives you four concrete levers (design quality, upfront disclosure, current and complete content, and being connected to the rest of the web via reviews and social proof) that map straight onto why an early startup site reads as trustworthy or not. At roughly three minutes it is a fast starting point before you audit your own homepage.
Users judge trust in seconds, and the four factors that move it are design quality, upfront disclosure of costs and contact info, comprehensive current content, and links out to third-party proof.
People trust outside sources (reviews, press, social presence) more than anything you say about yourself, so being connected to the rest of the web matters.
These credibility signals have stayed stable for decades even as design trends changed, so they are a safe foundation to build on.
Why we picked it
A clear, jargon-free explainer that corrects the most common misuse of the term, where teams ship a broken product and call it 'minimum viable.' It stresses that viable means it still has to deliver real value, even while being small. A good grounding read if you are unsure where the line sits between too little and just enough.
Why we picked it
A two-minute explainer that frames what usability testing is and is not, so you go in with the right expectations. Useful to send a co-founder or teammate who will observe with you but has never seen a session. Quick context before you dive into the how-to resources.
Why we picked it
Eye, tracking research showing that users scrutinize real, informative photos and completely ignore decorative stock imagery. This is the evidence behind our advice to use real photos or none. It will stop you from padding your screens with the same smiling, handshake stock shots that scream template.
Why we picked it
Research, backed breakdown of what actually makes users trust a site: design quality, upfront disclosure, current and comprehensive content, and connection to the wider web. It tells you where to spend your credibility budget instead of guessing. Useful when you want to justify design work to a co, founder who thinks polish is cosmetic.
Why we picked it
A pointed case study in obvious labels over clever ones. A vague "Get Started" button reads as friendly but leaves people unsure what happens next, so they hesitate. It shows how naming the actual outcome on a button raises both confidence and clicks.
Why we picked it
A two minute explanation of one of the most practical rules for founders: users spend nearly all their time on other apps, so they expect yours to work the same way. This is your best defense against a designer or founder who wants to be clever with novel navigation. Familiar is usually the right call.
Why we picked it
The practical answer to a crowded screen: show the few things most people need first, and tuck the advanced options behind a click. This one technique reduces the thinking a user has to do and lowers error rates without cutting features. Useful the moment your product grows past a simple form.
Why we picked it
This is the how behind reduce the thinking to zero. It names the three levers you actually control: cut visual clutter, build on existing mental models, and offload work with smart defaults and re-displayed information. Concrete, checklist ready advice you can apply to any screen.
Why we picked it
Users judge attractive products as more usable, which is why polish matters and also why it can hide real problems. As a founder this cuts both ways: a clean look buys goodwill, but it can mask issues that surface once users hit a real task. Read it so you know when to trust a good looking demo and when not to.
Why we picked it
Error prevention is one of Nielsen's ten heuristics, and this unpacks how to actually do it: match the user's mental model, offer sensible defaults, and use confirmations sparingly. It also warns that constant confirm dialogs backfire and train users to click through blindly. Direct, practical support for the prevent errors part of your answer.
Why we picked it
Human short term memory is tiny, so making people remember things across screens is a hidden tax on your product. This explains why showing options beats making users recall them, with examples like visible menus over blank command lines. A concrete lens for reducing the thinking a user has to do.
Why we picked it
A clean primer if you have never run a test. It defines the three pieces that matter (a facilitator who does not lead, realistic tasks, and participants who look like your real users) and explains moderated versus unmoderated and qualitative versus quantitative in plain terms. Good to read before your first session so you set it up right.
Why we picked it
This is the technique that turns watching into understanding. Ask users to narrate their thoughts while they work, and their confusion, wrong guesses, and moments of relief become audible. Nielsen argues it is the cheapest and most valuable method you have, and this piece is a quick guide to doing it well.
Why we picked it
The quality of your test depends entirely on the tasks you give. This piece shows how to write realistic scenarios that do not accidentally hand users the answer or hint at the click you want. Get this right and your test reveals genuine confusion, get it wrong and you only confirm what you hoped.
Why we picked it
Before you even open Figma, this shows you can test a flow with paper cutouts and catch most usability problems. The research it cites found roughly three quarters of issues surface with a low fidelity prototype. For a founder short on time, it proves the thinking matters far more than the tool.
Why we picked it
This backs up the first three seconds claim with research: people judge a page in milliseconds, and that snap verdict is hard to reverse. It explains the psychology of why a cluttered or unclear first screen makes visitors bounce before they read a word. Useful when you need to justify to a cofounder why the homepage and onboarding deserve real attention.
Why we picked it
The deeper, research backed treatment from the field's most trusted usability lab. It explains the actual mechanics of target size and distance, then turns them into concrete rules for buttons, edges, and corners. Read this when you want more than a one card summary and are making real layout calls.
Why we picked it
A short, practical take on when a long menu is actually fine. Hick's Law does not mean fewer items is always better, and this clip shows how grouping and clear labels keep a long list usable. Watch it before you gut a navigation just because it looks long.
Why we picked it
A curated map of the psychology that underpins these laws, with links to go deeper on each. Rather than one principle, it connects memory, attention, decision making, and mental models into a coherent picture. Use it as a syllabus once the single law cards leave you wanting the why.
Why we picked it
Research backed rules for making forms feel effortless, which is where much of onboarding drop happens. It directly supports the defer every field you can idea in your short answer. Short and specific enough to apply the same afternoon.
Why we picked it
Concrete rules for writing the words on your buttons and menus so nobody has to decode them. It covers using a verb plus a noun (Delete Folder, not just Delete) so a label makes sense on its own. Small change, big drop in second guessing.
Why we picked it
Eye tracking evidence for how people actually scan a screen, which tells you where to put the things that matter. If your important label or action sits where nobody looks, it may as well be invisible. Use this to place headings and primary actions along the path the eye already travels.
Why we picked it
A short, clear video on why showing options beats making people remember them, with interface examples. If you prefer watching to reading, this delivers the recognition over recall idea in a few minutes. Good to share with a cofounder who owns the product.
Why we picked it
Concrete evidence for what originality in the wrong place actually costs. It shows how novel patterns confuse users and slow them down, with real examples. Read it before you decide your product's checkout, search, or menu needs to look different from everyone else's.
Why we picked it
This separates internal consistency (within your product) from external consistency (matching the wider world of apps your users already use). That second kind is exactly what the short answer is about. It gives you a clean way to reason about which conventions to inherit.
Why we picked it
This names the exact tension in your question and gives a rule for when innovation is worth its learning cost. Watch it to decide which single part of your product deserves to be new and which parts should just feel familiar.
Why we picked it
Argues for stripping the interface down to essentials, which pairs neatly with copying conventions: keep the common parts quiet and familiar so your one genuinely new idea has room to stand out. A practical rule for what to leave plain.
Why we picked it
A short, credible video from the usability research group explaining whitespace in plain terms. It reinforces that empty space is a deliberate tool, not wasted room, which is the mindset shift most first time founders need. Quick to watch and easy to act on.
Why we picked it
The useful counterpoint: shipping a stripped MVP can leave a disjointed experience that erodes trust, especially outside scrappy startup contexts. Watching it keeps you honest that just ship it has real UX costs. It sharpens where cutting corners is safe versus where it quietly loses users.
Why we picked it
Sign-up and checkout forms are where founders lose users, and this piece is a focused rulebook for the error text on exactly those screens. It covers where to put the message, when to show it, and how to phrase it so people can recover fast. Concrete enough to apply to your form this afternoon.
Why we picked it
A button or link label makes a promise, and this article gives you a simple test for whether it will be kept: specific, sincere, substantial, succinct. It is the clearest short piece on why 'Submit' and 'Click here' fail and what to write instead. Directly answers the read-it-out-loud test in our short answer.
Why we picked it
This backs the core of your answer: trust the emotion, not the diagnosis. Nielsen argues you should watch what users do rather than take their stated explanations at face value, because people are unreliable narrators of their own behavior. It is a short, sharp reminder to observe the flow instead of building whatever the last person asked for.
Why we picked it
A foundational, if older, collection of guidelines and case studies on international interface design edited by Jakob Nielsen. Much of the underlying advice on layout, symbols, and language independent design has aged well. Reach for it when you want depth and principles behind the quick tips.
Why we picked it
NN/g explains preattentive processing, the reason some numbers pop out in milliseconds and others get lost. Understanding this tells you which visual signals to spend on the one metric that matters and which to keep flat. It is grounded in usability research rather than opinion.
Why we picked it
A short, credible video on choosing visualization styles that work with how people actually scan a dashboard. It is a fast way to absorb the core idea before you redesign anything. Good if you prefer watching over reading.
Why we picked it
A concise, practical primer on structuring an interview, from writing questions to avoiding leading language to taking useful notes. It is the reference to send a cofounder or early hire who has never run an interview before. Read it alongside the Mom Test for the mechanics the Mom Test assumes you already know.
Why we picked it
This is a catalogue of the specific ways founders sabotage their own sessions, including talking too much, asking hypothetical questions, and reacting visibly to what the user does. Skim it after your first test and you'll probably recognize at least one mistake you just made.
Why we picked it
This explains why people behave differently the instant they know you're watching, which is the deeper reason your own presence in the room is already a source of bias before you say a single word. The mitigation tactics here (building rapport, giving people a real task instead of a demo, stepping back physically) are direct, practical fixes.
Why we picked it
If a cofounder or teammate is going to sit in on the session, this is the two-minute brief you send them beforehand. It spells out exactly what an observer should never do (comment, correct, answer questions, react visibly), which is often where a supposedly neutral test quietly gets ruined by the person who isn't even running it.
Why we picked it
A short video showing exactly what neutral prompting sounds like when a participant goes quiet mid-task. Watching the actual tone and phrasing is more useful than reading about it, since the hardest part of staying neutral is usually how you say the reminder, not what you say.
Why we picked it
Shows an actual demonstration of a facilitator's opening script, the part of the session most founders wing and accidentally bias with. How you introduce the test (telling them there are no wrong answers, that you're testing the product and not them) sets the tone for whether they'll behave naturally for the next 30 minutes.
Why we picked it
Nielsen Norman Group has run user research for decades, and this short video lays out plainly which questions each method answers: qualitative interviews tell you why, quantitative surveys tell you how many. It is the calmest, least opinionated resource on this list, useful for seeing the interview versus survey debate as a matter of fit rather than one method being universally better. Ten minutes well spent before you pick a method.
Why we picked it
A checklist you can run your actual call script against before you place the calls. It catches the specific phrasing habits, like double barreled or leading questions, that quietly invite a polite agreeable answer. Use it as a five minute edit pass on your questions the night before a call, not as background reading.
Why we picked it
This walks through exactly the analysis step your question is stuck on, how to go from a stack of interview notes to a small number of real themes without kidding yourself that everything is a theme. It is a practical, visual demonstration rather than theory, useful right before you sit down with your own 20 transcripts. Watch it for the specific technique of coding and clustering, which maps directly onto sorting your interviews by who and how badly.
Why we picked it
Affinity diagramming is the literal, hands on version of sorting your transcripts by who the person is and how badly they hurt: you write one note per finding, cluster similar ones, and the clusters that end up biggest and tightest are your real pattern. This article gives you the step by step process so the sorting your short answer describes is not just a mental exercise. Good to run as an actual session with a co-founder rather than doing it alone in your head.
Why we picked it
A short, plain spoken walkthrough of the same mistakes in action, useful if watching an example lands faster for you than reading a checklist. Watch it right before your first few interviews so the mistakes are fresh in your mind.
Why we picked it
A broader companion to the leading questions piece, this covers the shape of a whole interview, from opening rapport to the order of questions to how to probe without steering. Read it once the basic don't lead the witness rule is second nature and you want to tighten the rest of the conversation.
Why we picked it
Recruiting is often the actual hard part of this problem, not the conversation itself. This gives you the tactics NN/g uses across hundreds of studies for reaching people who use a specific product, including how to screen for the right participant without tipping your hand about why you're asking.
