Feedback on your developer docs

Readers who get stuck in your docs rarely open an issue. Let them say what was unclear on the page, and fix the docs where people actually struggle.

Short answer: “Was this page helpful?” tells you a page is bad, not why. A Feedback button on each docs page lets readers say what was unclear, what failed, or what’s missing, with the page attached. You learn which pages to rewrite first.

What readers tell you

• A code sample that no longer compiles.
• A step that skips an install.
• A parameter that isn’t explained.
• A page that answers a different question than the one they came with.

Set up in minutes

Add one line to your docs site. For Docusaurus it’s a config entry; for other generators, the base layout. See Docusaurus, Astro and Hugo.

What docs feedback looks like

• “This code sample uses the old API.”
• “Step 3 assumes I already created a key, but the page doesn’t say how.”
• “The Python example fails with an import error.”
• “What’s the rate limit for this endpoint?”

Each of these costs someone an hour if nobody fixes it. A thumbs-down widget tells you a page is bad, not why. A sentence from the reader, with the page and section attached, tells you exactly what to change.

Make it easy for developers

• Keep Feedback in the corner of every docs page, out of the way of code blocks.
• Ask an optional, specific question on key pages, such as the quick start: “Did you get your first request working?”
• Reply when you fix something. Developers remember docs teams that listen.

Turn feedback into a weekly docs fix

Read new reports once a week, mark each one in progress when you start the edit and resolved when it ships. Related reports are grouped, so a page that confuses many people stands out. Grouping and statuses.