Published 17 October 2026 · By Jonathan Jones
How to Find Unclear Pages in Your SaaS Documentation
Learn how to invite readers to flag unclear SaaS documentation, capture the page they were reading, and use their comments to improve the right help pages.
Find unclear docs
To find unclear pages in your SaaS documentation, add a discreet feedback option to the docs, invite readers to say what was unclear, and check each submission’s page title and path. This gathers voluntary feedback from people who choose to send it. It does not track what readers do or automatically detect confusion.
Make it easy to comment on the page
A reader who gets stuck may not know where to send a comment, or may leave the documentation to find your contact details. A small feedback bubble on help pages gives them a direct way to ask a question while the confusing instructions are still in front of them.
Keep the prompt specific to documentation. For example: “Was anything unclear on this page? Tell us what you were trying to do.” That asks for a useful explanation without making the reader complete a long form.
Set up the feedback option
Place the widget on your documentation pages. Use a position that is easy to find without covering navigation or instructions. If your docs use a separate site or subdomain, check that the widget is configured for the website origin where those pages load.
Enable Questions. Readers can use this category to ask what a step means or where to go next. Enable Issues as well if you want to hear about broken links, errors, or instructions that do not match the product.
Customise the form prompt. Ask what was unclear and, if useful, what the reader was trying to accomplish. Avoid wording that assumes the page is confusing; the aim is to invite an honest response.
Send a test submission from a documentation page. Open it in your inbox and confirm that the recorded page title and path identify the page you were testing. Check this before relying on the context to sort future comments.
With Feedback Bubble, you can edit the feedback types and form wording in the bubble editor. Each submission includes the current page title, path and full URL, alongside available device and browser context. The installation uses a site key, so ordinary wording and appearance changes do not normally require you to paste a new script. See the Feedback Bubble overview or the installation guide for the relevant setup details.
Turn comments into documentation improvements
Review messages in Dashboard > Inbox > Needs review. Start with the reader’s exact words and the page they came from. A comment such as “I don’t understand this” is a signal to investigate, not proof that the whole page needs rewriting.
For example, suppose a reader asks what “workspace key” means on a setup page. Check whether the term is defined nearby, whether the instructions show where to find the key, and whether the wording matches the current interface. Then make the smallest change that addresses the actual gap.
If a comment is useful but you need more evidence before deciding what to change, move it to Saved. Archive messages that no longer need attention. If several readers raise the same underlying problem, you can consider them together; repeated requests are evidence to weigh, not a requirement to make every suggested change.
Know what this feedback can and cannot tell you
A feedback bubble tells you what a willing reader chose to report and which page they were on. It cannot show how many people read a page, where they stopped, or whether someone was confused but decided not to comment. A quiet inbox is not evidence that every page is clear.
Use comments alongside other signals when you have them, such as recurring support questions or issues you observe during usability checks. Page context helps you locate the relevant instructions, but the reader’s message still matters: it may not explain precisely what they expected or where they got stuck.
Start by adding a short, page-specific prompt to your docs and submitting a test comment. Then check that the recorded page context points to the right place before you invite readers to use it.