Dashboards
Method demonstration, not findings
NimbusWiz has no users. The dashboards and numbers below are illustrative worked examples of how I'd structure docs analytics for three different stakeholders.
The deliverable is the role framing and KPI selection, not the data.
A docs analytics dashboard tells different stories depending on who's reading it. Choosing what each role sees, and what they don't, is the actual IA work.
Three roles, three questions
| Role | Primary question |
|---|---|
| Content Strategist | Where are the gaps, drop-offs, and content opportunities? |
| Product Manager | Are users finding documentation for the features they use? |
| Support Lead | Which articles deflect tickets, and where are gaps driving escalations? |
The data layer
In a real engagement, the dashboards would pull from a docs analytics provider such as Plausible, Google Analytics 4, PostHog, or a custom pipeline. The choice of provider is downstream of the role framing, not upstream.
The exhibit
Switch between roles using the tabs. Each view shows the KPI cards, charts, and signals panel I'd build for that role.
Design decisions
Structured by audience, not by metric: A Content Strategist doesn't need feature-doc correlation scores. A PM doesn't need article helpfulness ratings. Picking what each role sees, and what they don't, is an IA decision applied to data.
KPIs that connect content to business outcomes: Each role view includes at least one KPI that ties content work to a downstream signal: ticket deflection for the Support Lead, feature-doc coverage for the PM, search resolution for the Content Strategist. KPIs that only describe content (page views, time on page) belong in a fourth dashboard for the docs team itself, not in stakeholder views.
Product-agnostic structure: The role framing transfers to any SaaS docs site. The specific charts and metric thresholds would be retuned to the product.
See Insights for five worked examples of how I'd turn signals from this dashboard into content decisions.