"It's in the docs" is not a solution. Here's why

We've all been there at some point: you're struggling with a product and reach out for help, only to get the dreaded response: "It's in the docs."

Is it technically accurate? Maybe. Actually helpful? Rarely.

As someone who's been on both sides of this exchange, I've come to realize that "it's in the docs" isn't just unhelpful, it's a symptom of deeper problems in how we think about user experience, product design, and customer support.

The Documentation Paradox

Here's the thing about documentation: if users are consistently asking questions that are "clearly explained" in your docs, one of three things is happening:

1. Your documentation isn't discoverable. Users can't find the answer even when they're looking for it. This might mean your search functionality is poor, your information architecture is confusing, or the relevant content is buried under layers of navigation.
2. Your documentation isn't understandable. The answer might be there, but it's written in jargon, assumes too much prior knowledge, or fails to address the actual mental model that users have when approaching the problem.
3. Your product needs a better design. If something requires documentation to be usable, you haven't actually solved the problem; you've just shifted it. Good design should make the obvious obvious and reserve documentation for the complex edge cases.

Why "RTFM - (Read The F***ing Manual)" Culture is Toxic

When we respond to user questions with "it's in the docs," we're doing several harmful things:

• We're making users feel stupid for not finding something that we, the product's experts, think is obvious. This erodes trust and creates defensiveness rather than learning.
• We're treating documentation as an insurance policy rather than a teaching tool. Documentation isn't there to protect you from user questions. It's there to empower users to succeed.
• We're missing valuable feedback. Every question a user asks is data. It tells you where your product, your documentation, or your onboarding is failing. When you dismiss these questions, you're throwing away insights that could improve your product.

What Documentation Actually Is

Documentation should be a reference, not a barrier. It's meant for users who want to dive deep, explore advanced features, or understand the underlying mechanics. It's not supposed to be the only path to basic competency.

Think about the best products you use. How often do you need to read their documentation to accomplish common tasks? Probably not often. That's not because their documentation is bad, it's because their design is good.

A Better Approach

Instead of defaulting to "it's in the docs," try this:

• Answer the question first. Even if it's in the docs, give the person the answer they need right now. They're stuck, and they came to you for help.
• Then provide the documentation link. After you've helped them, share the relevant doc link with context: "Here's the guide that covers this in more detail if you want to learn more."
• Investigate the pattern. If you're getting the same question repeatedly, don't blame users for not reading. Ask yourself: Why are so many people getting stuck here? What can we change?
• Improve continuously. Use user questions as a roadmap for improving your product, your documentation, and your onboarding. Every question is an opportunity to make things better.

The Real Solution

The goal isn't to create perfect documentation that answers every possible question. The goal is to create products that are intuitive enough that most people don't need documentation for common tasks, and to create a culture where asking questions is seen as valuable feedback, not a nuisance.

Documentation is important. It should be comprehensive, well-organized, and clearly written. But it should be a safety net, not a crutch. And it should never be wielded as a weapon against users who are simply trying to get something done.

The next time you're tempted to respond with "it's in the docs," pause. Ask yourself: Is this really about the documentation, or is it about something we need to fix? Because if users can't find it, can't understand it, or shouldn't need it in the first place, then no, it's not really in the docs. Not in any way that matters.