Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks address a problem that accumulates gradually in almost every reporting environment: dashboards that started with a clear purpose and slowly became cluttered with additional visualizations until they serve no one particularly well. The conversation covers why over-reporting happens, what the cost of it actually is, and how developers can push back constructively on requests that compromise a report’s usability without damaging the relationships those requests come from.
For any BI developer who has felt the tension between accommodating every stakeholder request and maintaining a report that actually works, this episode offers a practical and principled framework for navigating it. See how Blue Margin’s Managed Analytics & Insights builds the right scope and purpose discipline into every dashboard engagement, ensuring that what gets delivered is focused enough to be trusted and simple enough to be used.
What This Episode Covers
The Problem with Over-Reporting (0:57 – 3:40)
Adding too many visualizations to a single page does not make a report more useful. It makes it harder to read, slower to interpret, and more expensive to maintain. Users confronted with an overwhelming amount of information on a single page often disengage rather than work through it, which means the data the report was built to surface never reaches the decisions it was supposed to inform.
Striking the Right Balance (4:10 – 5:50)
The hosts offer a practical starting point: around six visualizations per page. The number is not a rigid rule but a useful heuristic for keeping a page focused and navigable. The more important principle is that every element on a page should serve a specific, shared purpose, and the page as a whole should be immediately legible to a user who encounters it without a tutorial.
Defining the Goal Before Building (6:50 – 7:10)
Before a single visualization is built, the purpose and value of the report should be clearly defined. That definition becomes the filter through which every subsequent request is evaluated. If a new visualization does not clearly support the primary goal of the report it is being added to, the right answer is not to find a way to fit it in. It is to recognize that the request belongs somewhere else.
Handling User Requests Collaboratively (7:36 – 9:35)
Saying yes to every request to add elements to an existing report is the path of least resistance and one of the primary reasons reports become cluttered over time. The hosts recommend a different approach: a collaborative conversation that explains why creating a dedicated page for a new topic is a better solution than adding it to an existing one. That conversation is not a refusal. It is a more useful response to the underlying need.
User-Centric Design as a Trust Builder (9:39 – 10:28)
Developers who push back on over-complication are not being difficult. They are doing their job well, and users tend to recognize that over time. Building a reputation as someone who says no to bad ideas because they care about the outcome rather than just the request is what establishes a BI developer as a trusted partner rather than an order taker. That distinction matters for how the data function is perceived and for the quality of the work it produces.
Who It’s For
This episode is worth your time if you are a Power BI developer whose reports have grown cluttered through accumulated requests and you are looking for a principled framework for managing that pressure going forward, a BI team lead trying to establish design standards that keep reports focused and maintainable across a growing report library, a business stakeholder who wants to understand why a developer might recommend a separate page rather than adding to an existing report, or anyone involved in a reporting project where the scope of a single dashboard keeps expanding beyond what a single page should contain.
Why It’s Worth a Listen
The over-reporting problem is almost universal, and it is rarely the result of bad intentions. Stakeholders have legitimate needs, developers want to be responsive, and the path of least resistance is to add rather than restructure. This episode reframes that dynamic in a way that gives developers both the language and the justification to handle those situations differently without it feeling like a confrontation.
The goal definition advice is the most preventative part of the conversation. Reports that start with a clear, documented purpose are significantly more defensible against scope creep than those that start with a general brief and accumulate requirements over time. Establishing that definition upfront is a small investment that changes the entire trajectory of how a report evolves.
And the trust-building framing at the end is worth taking seriously as a long-term career and relationship principle. The developers who are most valued by business stakeholders are rarely the ones who said yes to everything. They are the ones who cared enough about the outcome to say no when no was the right answer.
