Tag: Documentation

  • How to Use Examples and Screenshots Effectively in Documentation

    How to Use Examples and Screenshots Effectively in Documentation

    Reading Time: 3 minutes

    One of the fastest ways to improve your documentation is simple:

    Show more. Tell less.

    Examples and screenshots bridge the gap between explanation and understanding. They take something abstract and make it concrete.

    Used poorly, they can clutter your content, confuse readers, or even make things harder to follow. Used correctly, they provide clarity.

    This guide will show you how to use examples and screenshots the right way.

    Why Examples and Screenshots Matter

    People don’t learn well from explanations alone.

    They learn when they can:

    • See what something looks like
    • Understand how it behaves
    • Recognize patterns

    Examples and screenshots:

    • Reduce confusion
    • Speed up learning
    • Increase confidence

    If your goal is clarity, they’re not optional; they’re essential.

    When to Use Examples

    Use examples anytime you’re explaining something that could be misunderstood.

    1. When Explaining Concepts

    Abstract ideas need concrete examples.

    Without example:

    A variable stores a value.

    With example:

    A variable stores a value. For example:
    name = "John"

    The second version is instantly clearer.

    2. When Showing Input and Output

    Users need to see both what goes in and what comes out.

    Example:

    Input:
    HelloOutput:
    HELLO

    This removes guesswork.

    3. When Demonstrating Patterns

    Examples help users recognize structure.

    Example:

    email = "user@example.com"
    username = "user123"

    Now the reader sees how values are typically formatted.

    4. When Clarifying Edge Cases

    Examples can show what not to do.

    Example:

    Correct: user_name
    Incorrect: user name (spaces are not allowed)

    This prevents common mistakes.

    How to Write Good Examples

    Not all examples are helpful. Here’s how to make yours effective.

    Keep Them Simple

    Don’t overload examples with unnecessary detail.

    Bad:

    userAccountName = "JohnDoe1987_admin_user_primary"

    Better:

    username = "johndoe"

    Focus on clarity, not realism.

    Make Them Relevant

    Use examples that match the reader’s situation.

    If you’re writing for beginners, avoid complex scenarios. If you’re writing for developers, use realistic data.

    Label Them Clearly

    Tell the reader what they’re looking at.

    Example:

    Command:
    npm install

    Result:
    Packages installed successfully

    Don’t make users guess.

    Place Them Immediately After the Explanation

    Don’t separate examples from the concept they explain.

    Bad structure:

    • Explanation (top of page)
    • Example (far below)

    Good structure:

    • Explanation
    • Example (immediately after)

    Keep them connected.

    When to Use Screenshots

    Screenshots are most useful when text alone isn’t enough.

    1. When the Interface Matters

    If users need to click something specific, show it.

    Example:

    • Complex menus
    • Multiple buttons
    • Unfamiliar layouts

    A screenshot can prevent wrong clicks and frustration.

    2. When There’s Visual Feedback

    Show what success looks like.

    • Confirmation messages
    • Error messages
    • Completed forms

    This helps users verify they’re on the right track.

    3. When Steps Are Hard to Describe

    Some actions are easier to show than explain.

    If your instructions feel long or awkward, a screenshot might simplify everything.

    How to Use Screenshots Effectively

    Screenshots should clarify the instructions, not overwhelm the reader.

    Keep Them Focused

    Crop out unnecessary parts of the screen.

    Highlight what matters:

    • Buttons
    • Fields
    • Menus

    If everything is visible, nothing stands out.

    Add Annotations

    Use arrows, boxes, or highlights to guide attention.

    Don’t assume users will “just see it.”

    Match the Step Exactly

    Each screenshot should correspond to a specific step.

    Example:

    1. Click Settings

    Avoid generic screenshots that don’t match the action.

    Example Steps

    In the screenshot below, I’ve used an arrow and numbered steps to highlight the location of specific settings for the WS Form plugin. The numbers correspond to the steps in the instructions. See the article How to Control WordPress Blocks with PersonalizeWP for context.

    Keep Them Updated

    Outdated screenshots are worse than no screenshots.

    If the interface changes:

    • Update images
    • Or remove them

    Nothing confuses users faster than mismatched visuals.

    When NOT to Use Screenshots

    More screenshots do not equal better documentation.

    Avoid screenshots when:

    • The step is simple (“Click OK”)
    • The interface is obvious
    • The image adds no new information

    If the screenshot doesn’t help, remove it.

    A Simple Rule to Follow

    Before adding an example or screenshot, ask:

    Does this make the content easier to understand or follow?

    If yes, include it.
    If not, leave it out.

    A Practical Workflow

    Here’s a simple process you can use:

    1. Write the explanation
    2. Add a simple example
    3. Identify steps that might confuse users
    4. Add screenshots only where needed
    5. Review for clarity and remove anything unnecessary

    Common Mistakes to Avoid

    • Overloading examples with too much detail
    • Using irrelevant or unrealistic examples
    • Adding too many screenshots
    • Using blurry or cluttered images
    • Letting screenshots become outdated

    Final Thoughts

    Examples and screenshots are tools, not decorations.

    Used well, they make your documentation clear, practical, and easy to follow.

    Used poorly, they create noise.

    The goal isn’t to show everything.

    It’s to show just enough to help the user succeed.

  • What Makes Documentation “Good”? (A Practical Checklist)

    What Makes Documentation “Good”? (A Practical Checklist)

    Reading Time: 3 minutes

    Most documentation isn’t terrible, but it can be hard to use.

    It might be accurate. It might even be complete. But if users can’t quickly find what they need and understand it without effort, it fails its purpose.

    Good documentation isn’t about volume or technical depth.

    It’s about helping people get things done correctly.

    This article gives you a practical checklist you can use to evaluate and improve any documentation you write.

    What “Good” Documentation Really Means

    Good documentation is:

    • Clear (easy to understand)
    • Usable (easy to follow)
    • Findable (easy to navigate)
    • Relevant (focused on the user’s goal)

    Users will struggle if any of these are missing.

    The Practical Checklist

    Use this checklist to review your documentation before publishing.

    1. Is the Purpose Clear?

    Can a reader quickly answer:
    “What is this, and why should I care?”

    • Is there a clear title?
    • Does the introduction explain the goal?
    • Is the outcome obvious?

    Good:

    “How to Install the App and Get Started”

    Weak:

    “Application Setup Notes”

    2. Is It Written for the Right Audience?

    • Does it match the reader’s skill level?
    • Are terms explained if needed?
    • Are assumptions kept to a minimum?

    Good documentation meets the reader where they are, not where the writer is.

    3. Is the Structure Easy to Follow?

    • Are sections logically organized?
    • Are headings clear and descriptive?
    • Can users scan the content?

    A good structure breaks up the text. Look for:

    • Short sections
    • Clear headings
    • Helpful bullet points

    If everything blends, users will get lost.

    4. Are the Steps Clear and Actionable?

    For instructional content:

    • Are the steps numbered?
    • Does each step contain one action?
    • Do steps start with strong verbs?

    Good:

    1. Open the app
    2. Click Settings
    3. Select Account

    Weak:

    Open the app and go to settings to change your account

    5. Is the Language Simple and Direct?

    • Are sentences easy to read?
    • Is jargon minimized or explained?
    • Are unnecessary words removed?

    Good documentation sounds natural, not robotic.

    6. Are Examples Included?

    Examples make abstract ideas concrete.

    • Are there real-world examples?
    • Do they match the reader’s context?

    Even one simple example can dramatically improve understanding.

    7. Are Key Details Highlighted?

    • Are warnings, notes, and tips included where needed?
    • Are important actions easy to spot?

    Look for:

    • Note: Helpful context
    • Tip: Shortcuts or best practices
    • Warning: Potential risks

    These guide users and prevent mistakes.

    8. Can Users Find What They Need Quickly?

    Ask yourself:

    • Can someone scan this and find the right section fast?
    • Are headings specific enough?
    • Is unnecessary content in the way?

    Good documentation respects the user’s time.

    9. Does It Show What Success Looks Like?

    After instructions, users should know:

    • What should happen next
    • What a correct result looks like

    Example

    After clicking Submit, you should see a confirmation message.

    This reduces uncertainty and builds confidence.

    10. Has It Been Tested?

    This is the most important, and most ignored, step.

    • Have you followed the instructions yourself?
    • Has someone else tested it?
    • Were there any points of confusion?

    If users struggle, the documentation needs improvement.

    A Quick Scoring Method

    To evaluate your documentation, rate each item from 1 to 5:

    • 1 – Needs major improvement
    • 5 – Excellent

    If most of your scores are:

    • 4–5 – You’re in good shape
    • 3 or below – Focus on improving those areas

    This gives you a simple, repeatable way to improve your work over time.

    Common Signs of Poor Documentation

    Watch for these red flags:

    • Long, dense paragraphs
    • Missing steps
    • Unexplained jargon
    • No clear structure
    • Outdated or inaccurate information

    If users frequently ask questions, your documentation likely needs work.

    Final Thoughts

    Good documentation doesn’t try to impress.

    It tries to help.

    If someone can quickly find what they need, understand it, and complete their task without frustration, then you’ve succeeded.

    Everything else is secondary.