Documentation should prioritize user needs and problems over technical implementation details. Start with the “why” - what problem does this solve and when would users need it? Provide clear use cases and benefits before diving into technical specifics.
Structure documentation to guide users through their journey:
Move implementation details, technical architecture, and contributing guidelines to separate technical documentation when they don’t directly serve user goals.
Example structure:
# Feature Name
## What problem does this solve?
Help users understand when they need this feature...
## Use cases
- Run this when you want to...
- Use this for...
## Quick start
Simple example with expected output...
## Benefits
What you can accomplish after setup...
Avoid documentation that “reads more like internal technical documentation than a user guide” by consistently asking: “Does this help users accomplish their goals?”
Enter the URL of a public GitHub repository