🎯 Learning Objectives
By the end of this lesson, you will:
- Apply the "follow it literally" technique to test any user guide
- Identify the 4 most common failure modes in user documentation
- Verify that screenshots in documentation match the current product UI
- Assess whether a guide's reading level matches its intended audience
📖 Why User Documentation Needs Testing
Here's a scenario: your product ships a polished new feature. The developer is proud. The PM is happy. But six months later, the #1 support ticket is: "I can't figure out how to use [that feature]."
The feature worked. The documentation didn't.
User guides, FAQs, and help articles are part of your product. They fail in predictable, testable ways. Your job is to find those failures before users do.
🔍 The 4 Failure Modes of User Documentation
Failure Mode 1: Screenshots Out of Sync 📸
What happens: The UI changes. The screenshots in the help article don't.
Result: User follows the guide, can't find the button in the position shown, gives up and calls support.
How to test: Open the guide. Open the product. Follow the screenshots side-by-side. For every screenshot:
- Does the button/menu/field shown actually exist?
- Is it in the same location?
- Does it look the same? (Same label, same icon?)
This check is often neglected after each release. Flag outdated screenshots immediately.
Failure Mode 2: Incomplete Steps 📋
What happens: The guide says "click Save" but forgets to mention you first need to scroll down to see the Save button, or that you need to switch to Advanced mode first.
Result: User gets stuck at step 3 of 5 and doesn't know why.
How to test: Follow the guide literally and mechanically — as if you've never seen the product before. Perform exactly what each step says, nothing more, nothing less.
Ask yourself after each step: Could someone with no product knowledge have completed this step?
Failure Mode 3: Terminology Mismatch 📝
What happens: The guide says "go to your Workspace" but the product calls it "Dashboard". Or the guide says "click the Settings gear" but the icon is actually labeled "Preferences".
Result: User looks for "Workspace" but only sees "Dashboard". They assume they're in the wrong place.
How to test: For every noun in the guide, check that the same word appears in the product. If the product calls it "Dashboard", the guide should call it "Dashboard".
Failure Mode 4: Wrong Audience Level 🎓
What happens: The guide was written for advanced users but the feature is for beginners. Or vice versa — the guide over-explains to power users.
Result: Beginners get lost, advanced users get annoyed.
How to test: Read the guide with the target persona in mind. Ask: Would a first-time user of this product understand every term? Every step?
Technical jargon check: "Navigate to the API endpoint configuration" vs "Go to Settings > Integrations". Same action, very different clarity levels.
🛠️ The "Literal Follow" Technique
This is the most effective way to test a user guide:
- Clear your knowledge. Pretend you've never used this product.
- Open the guide in one window, the product in another.
- Execute step 1 literally. Do exactly what it says.
- Note any friction. Did you have to guess anything? Scroll unexpectedly? Click something not mentioned?
- Continue through every step. Don't skip ahead.
- At the end, ask: Did the guide deliver the promised outcome?
Anything that required guessing is a guide defect.
🌍 Real-World Example
Guide step: "Click the user icon in the top-right corner to access your account settings."
What the tester found: The icon is in the top-right corner — but clicking it opens a dropdown with four options: Profile, Settings, Billing, and Log Out. The guide doesn't say which option to choose.
Bug: Incomplete step — guide doesn't specify which dropdown option to select for "account settings."
Suggested fix: "Click the user icon in the top-right corner, then select Settings from the dropdown menu."
💡 Pro Tips
💡 Tip 1: After every product release, review help articles that reference the changed features. Outdated screenshots are the number-one source of support tickets.
💡 Tip 2: If you're testing documentation for a feature that hasn't been released yet — screenshot it right after the feature is deployed. Don't wait for docs to fall behind.
💡 Tip 3: FAQ articles are often written reactively (from support tickets). They're usually accurate but may be incomplete. Check if the FAQ covers the top 3 scenarios for each feature.
📋 Summary
- User documentation fails in 4 predictable ways: outdated screenshots, incomplete steps, terminology mismatch, wrong audience level
- The "Literal Follow" technique is the most reliable way to test a guide
- Any step that requires guessing is a defect
- Verify every screenshot, every product term, every step against the current product state
Up next: release notes — the documentation that announces what changed, and how to verify it's accurate.