Rocket Surgery Made Easy

Author: Steve Krug | Chapters: 16 | Generated: 2026-09-21

How to Use This Skill

• Planning a round: start from the six maxims below and the defaults in cheatsheet.md. Produce a concrete plan covering the date, what to test, three participants and how to find them, 5–10 tasks narrowed to about 35 minutes, observers, and a debrief slot.
• Early discovery or concept validation: use the napkin test, competitor testing, and wireframe tests from ch04. Push to test earlier than the user plans to.
• Writing artifacts: scenarios, invitations, scripts, observer handouts, the debrief agenda, and the summary email all have templates in test-kit.md. Adapt them to the product and language, and invent examples rather than using real user data.
• Reviewing a test plan, script, or scenarios: report only concrete defects, each with the location, the rule it breaks, and a rewrite. Typical defects: on-screen words in a scenario, opinion questions ("Do you like…?"), leading or clue-giving phrasing, too many participants per round, testing scheduled only at the end, no observers, a debrief with no fix commitment, or redesign-sized fixes. At most 5 findings. If there are none, say so in one line.
• Interpreting findings or choosing fixes: rank by severity (how many people × how bad), keep the top ten, and for each ask "What's the smallest change that stops the observed problem?" Tweak and take away before you redesign or add.
• With a topic or chapter: ask about recruiting, facilitation, debrief, remote, Home page, or ch08, and I read that chapter file first.

What DIY Testing Is (and Isn't)

Usability testing = watching people try to use what you're building. Actual use, not opinions, which is what separates it from surveys, interviews, and focus groups. Krug's kind is qualitative: the goal is insight to improve, not statistics to prove. That permits three users, an unscientific process, and changing tasks mid-round. It always works because every product has problems, the serious ones are obvious to outsiders, and watching makes the team better designers. Analytics tell you what; testing tells you why.

When someone asks for statistical validity, the answer is: you're right, three users prove nothing; the point is to find and fix obvious problems, which need no proof.

The Six Maxims (the whole method)

1. A morning a month, that's all we ask. A fixed recurring date with three users in the morning and a debrief over lunch, done by early afternoon. The routine removes the decision about when. Monthly is the floor. In Agile, run a round per sprint, perhaps with two users and some remote rounds, testing last sprint's code and a paper prototype of the next. (ch03)
2. Start earlier than you think makes sense. The worse shape it's in, the less you want to show it, and the more you gain by showing it. Test your current product, competitors' products (free prototypes), napkin sketches ("What do you think this is supposed to be?", never "Do you like it?"), wireframes (navigation and naming), and comps (does each page read?). You're in it for the surprises. (ch04)
3. Recruit loosely and grade on a curve. Most serious problems don't depend on domain knowledge. Roughly match your audience, add one outsider "ringer" per round, and discount failures caused only by missing jargon. Three per round: more rounds beat more users. First Law: one user is 100% better than none. (ch05)
4. Make it a spectator sport. Get everyone, executives included, to watch live from a separate room. Seeing is believing: skeptics convert, and everyone learns that users aren't like them. Each observer writes their top three problems per session. (ch09)
5. Focus ruthlessly on a small number of the most important problems. You'll always have more problems than resources, and easy minor ones crowd out the worst. The same-day debrief (attendees only) distills a ranked top ten, works down it without skipping, and stops at this month's capacity. (ch10)
6. When fixing problems, always do the least you can do. Make the smallest, simplest change likely to prevent the problem you observed, not its inflated version ("redesign the menu system"). Tweak, don't redesign. Take something away before adding. Don't wait for the big redesign. (ch11)

Core Techniques

Tasks → scenarios (ch06). Pick from 5–10 key user goals by criticality, worry, and support or analytics signals. Write each as a short "You are… you need to…" card with the data they need, without the interface's own words ("Choose the kind of music you want to listen to", not "Customize your LAUNCHcast station"). Ban search unless you're testing it. Pilot, then print one per sheet, unnumbered.

The session (ch08), 50 minutes: welcome read verbatim (we test the site, not you; think aloud) · a few warm-up questions · Home page tour ("tell me what you make of it", no clicking) · tasks, ~35 min, each scenario read aloud · probing (observers' questions first) · wrap-up · a 10-minute reset.

Facilitator as therapist. Keep them talking: if you're not sure what they're thinking, ask "What are you thinking?" Stay neutral: no clues, answer questions with questions ("What would you do if you were at home?"), no opinions, poker face. Save the whys for the probe. Move on when the task is done, they're miserable ("it's not a crash test"), time is short, or learning stops, after a little overtime. Participants leave in no worse shape than they came, with privacy protected.

Severity (ch10) = how many people × how bad. The hard calls are corner cases (rare but severe) and ubiquitous nuisances (common but minor). Keep the debate on evidence: "Did anybody in the tests have that problem?"

Tweak loop (ch11): simplest change → did it work? If not, the same tweak louder, then a different tweak, then check nothing else broke. Verify by looking at it, a hallway test, an unmoderated remote test, or an A/B test.

Usual suspects (ch12): getting off on the wrong foot, where wrong first-seconds assumptions snowball (fix Home page orientation and tour it every session), and failure to shout, where important things are too subtle (make them stand out more than feels right).

Making fixes stick (ch13): reports don't cause change. Keep commitments small, give observers a voice, and convert management by demonstration rather than ROI decks.

Remote (ch14): moderated remote gives ~80% of the benefit for ~70% of the effort, with easier recruiting and less control. Do about three in-person rounds first. Unmoderated services suit quick questions and fix retests but can't probe.

Chapter Index

Topic Index

• Agile / sprint cadence → ch03, ch14
• Analytics vs. testing → ch01, ch06
• Budget / cost → ch03, ch05
• Concept validation / discovery → ch04, ch12
• Competitor testing → ch04, ch09
• Debrief → ch10, ch13
• Domain knowledge → ch05, ch08
• Ethics / privacy / consent → ch08, test-kit
• Facilitation / think-aloud → ch08
• Fixing problems / tweaks → ch11, ch12
• Home page → ch08, ch12
• Management buy-in → ch09, ch13
• Observers → ch09, ch10
• Prioritization / severity → ch10
• Probing → ch08
• Quantitative vs. qualitative → ch01, ch03, ch15-16
• Recruiting / number of users → ch05, ch14
• Redesign → ch10, ch11, ch13
• Remote / unmoderated testing → ch14, ch11
• Scenarios / tasks → ch06
• Scheduling / logistics → ch03, ch07
• Test script → ch08, test-kit
• Wireframes / comps / prototypes → ch04

Supporting Files

• cheatsheet.md: start here while planning or reviewing. Defaults and thresholds, if-then decision rules, tells and smells.
• test-kit.md: adaptable invitation, screener, scenario template, facilitator script, neutral phrases, consent form, observer sheet, debrief agenda, summary email.
• patterns.md: 18 named techniques, each with when, how, and trade-offs.
• glossary.md: every term with a one-line definition and chapter.

Scope & Limits

This skill covers the book's method only: evaluative, qualitative, small-sample usability testing. For discovery it covers testing concepts early (napkin tests, competitor tests, wireframes). It does not cover generative research such as user interviews, contextual inquiry, surveys, or jobs-to-be-done. Krug explicitly contrasts testing with opinion-gathering methods. Say so when a question needs those methods, and don't stretch the book to cover them.

Not for proving things (benchmarks, statistical comparisons) or for safety-critical systems. Both need rigorous quantitative studies.

The book is from 2009 and web-focused. Tool names (Camtasia, GoToMeeting, Google Website Optimizer) and dollar figures are dated; the method and ratios still hold. Krug says it applies to anything people use (apps, forms, devices, documents). Substitute "first screen" for "Home page" where needed. Screenshots and cartoons in the source (about 100 images) were not read, except the maxims, comparison tables, neutrality chart, and tweak flowchart, which were transcribed.