📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The single best thing ever written on customer conversations. It teaches you to ask about the customer's life and past behaviour, not your idea, so you can't be lied to. If a founder reads one thing before talking to a single customer, it's this.
From
momtestbook.com
by Rob Fitzpatrick
~130 pages
- Talk about their life, not your idea.
- Ask about specifics in the past, not opinions about the future.
- 'That's so cool, I'd totally buy it' is a compliment, not data, dig for commitment and evidence.
Open
momtestbook.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The most accessible, practical intro to usability ever written, you can read it in a weekend and immediately fix your product. The definition of 'make it obvious, not clever.'
From
sensible.com
by Steve Krug
~200 pages
- Self-evident design is the goal, kill anything that adds thinking.
- Users satisfice: they scan and click the first reasonable option.
- Cheap, frequent usability testing beats large formal studies.
Open
sensible.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
This is the short, practical manual for actually doing a test yourself, no training required. Krug walks you through running a simple session in a morning a month, and hands you the scripts, checklists, and a recording setup so you are not inventing the process from scratch. It pairs perfectly with the Nielsen article: one tells you why five users is enough, this one shows you exactly how to sit down and run it.
From
Steve Krug (New Riders)
by Steve Krug
About 168 pages
- You can run a useful test in roughly a morning a month, no lab and no research team needed
- Comes with ready-to-use scripts and checklists so you copy a working process instead of guessing
- Focus on finding the few most important problems, then fix them with the least you can do
Open
sensible.com →
📖 Book
✓ Link checked
Paid
Beginner
Why we picked it
The foundational text on human-centered design that every product person should read once. It rewires how you see every product, including your own.
From
jnd.org / Basic Books
by Don Norman
~350 pages
- Make affordances and signifiers obvious, users shouldn't guess.
- Give clear, immediate feedback for every action.
- Design out errors rather than blaming users ('human error' is usually design error).
Open
jnd.org →
📄 Article
✓ Link checked
Free
Beginner
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.
From
Nielsen Norman Group
by Jakob Nielsen
~15 min read
- Visibility of system status, always tell users what's happening.
- Match the real world, use the user's language and mental models.
- Prevent errors, and make consistency and standards the default.
Open
nngroup.com →
✍️ Essay
✓ Link checked
Free
Intermediate
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.
From
Nielsen Norman Group
by Jakob Nielsen
- Watch behavior, do not act on what users say they want
- Self-reported reasons and predictions are often wrong
- Collect opinions only after someone has actually used the thing
Open
nngroup.com →
📄 Article
✓ Link checked
Free
Beginner
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.
From
Nielsen Norman Group
by Jakob Nielsen
~6 min read
- Ask users to say what they are thinking as they go
- Their wrong guesses point straight at unclear labels and flows
- It is cheap, flexible, and needs no special equipment
Open
nngroup.com →
📄 Article
✓ Link checked
Free
Beginner
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.
From
Nielsen Norman Group
by Kate Moran
~12 min read
- Give realistic tasks, not questions about opinions
- The facilitator observes and never rescues the user
- Recruit people who resemble your actual target users
Open
nngroup.com →
📄 Article
✓ Link checked
Free
Beginner
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.
From
Nielsen Norman Group
by Jakob Nielsen
About a 10 minute read
- Five users find about 85 percent of usability problems, so you do not need a large sample to learn what is broken
- Running three small tests and fixing between them beats a single big study
- The rule holds for qualitative testing of a fairly similar user group, so split into small groups if your users are very different
Open
nngroup.com →
📖 Book
✓ Link checked
Freemium
Intermediate
Why we picked it
When 20 interviews each surface a slightly different problem, the fix is not more interviews, it is a structure to sort them. Teresa Torres's opportunity solution tree gives you exactly that: a way to map every pain point you heard against one desired outcome, so real, recurring opportunities separate themselves from one-off noise. This guide is the clearest free explanation of the method, and it points to the full book if you want to go deeper.
From
Product Talk
by Teresa Torres
~10 min read (companion to a full book)
- Group each interview finding as an opportunity (a customer need, pain, or desire) and place it under a single desired outcome, so patterns become visible instead of a flat list of quotes.
- A problem that keeps recurring across interviews earns a spot on the tree, a one-off mention does not, which is a concrete rule for pattern versus noise.
- The tree is meant to keep changing as you keep talking to customers, so treat your 20 interviews as a starting point, not a finished map.
Open
producttalk.org →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A founder-friendly crash course on planning and running discovery interviews, with tactics from researchers at Zoom, Zapier, and Dropbox. It is especially good on picking the one or two things you must learn and writing questions that do not lead the answer. Concrete and skimmable.
From
First Round Review
by Jane Davis
20 min read
- Decide the two things you must learn before the call.
- Reframe important questions from several angles.
- Check your own bias before interpreting answers.
Open
review.firstround.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This is the bridge from a diagnosed problem to a concrete design change. The When / I want to / So I can format forces you to state the situation, motivation, and outcome, which pins down exactly what a fix must achieve. Use it to translate one clunky moment into a precise, testable change rather than a vague polish pass.
From
Intercom Blog
by Alan Klement / Intercom
- Frame the fix as a job story: situation, motivation, desired outcome
- Focusing on the situation keeps you from guessing at solutions
- A clear job story makes it obvious whether a change actually helped
Open
intercom.com →
📄 Article
✓ Link checked
Freemium
Intermediate
Why we picked it
This is the canonical piece that put jobs to be done on the map, written by the people who coined it. It uses the famous milkshake story to show that customers do not buy products, they hire them to make progress in a specific situation, which is the exact lens this question is about. Read it as the clearest short starting point before going deeper into JTBD.
From
Harvard Business Review
by Clayton Christensen et al.
~20 min read
- Customers hire a product to make progress in a specific circumstance, so the job, not the customer profile, is the unit of analysis.
- The same product can be hired for very different jobs, which changes how you build and market it.
- You find the job by studying the struggle and the context, not by asking people to rank features.
Open
hbr.org →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A thorough, free guide to the full range of usability tests, from moderated sessions to unmoderated remote tasks and five-second tests. Useful when you want to match the right method to your specific clunky complaint (first impression, navigation, or a full task flow). Practical templates and task-writing advice included.
From
Maze
- Match the test method to the kind of friction you are chasing
- Unmoderated remote tests let you gather feedback quickly and widely
- Write clear, non-leading tasks and pilot them before you run
Open
maze.co →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Very often clunky means slow, and slow is as much about perception as raw milliseconds. This explains how loading states, skeleton screens, and instant feedback make the same speed feel faster. If your walkthrough finds a slow load behind the complaint, this gives you concrete changes to make it feel responsive.
From
MDN Web Docs
- Clunky frequently means the interface felt slow or unresponsive
- Skeleton screens and instant feedback improve how fast it feels
- Responsiveness matters as much as actual load time
Open
developer.mozilla.org →
