The "I Want it All" Problem: an issue that comes up when developing a new dashboard where the audience requests the visualization of every data point available, which disregards best practices and results in uninformative dashboards.
The two solutions to the "I want it all" problem in dashboarding is to give it all (somewhere else) or make the discussion about business problems, not data. Yeah, it can be that simple.
Problem Scenario
Whenever you're designing a new dashboard or report you'll inevitably try to decide what the most important points are to emphasize to the end user and it may come out similar to the following questions:
"Do you want to see this over time?"
"Do you want to compare one period to another?"
"Do you want to see all the categories combined or one versus another?"
"Do you want to see this as a map?
Ultimately, the response you're most likely to get is "Yes, yes, yes, yes, and anything else you can add". This is the kitchen sink approach and it's not because the end user hates design. It's because they're scared that there's a question they might miss and if they miss it now they'll never be able to ask it again. This fear is another reason why companies will often stick with their wall of numbers than to work towards visualizations.
Solution
There are two ways to get past this problem:
Support any dashboard with detail or
Change the way you talk about data and reporting.
Support with Detail
Most dashboarding and reporting platforms provide an ability to drill in. This means that if the audience sees something in a visual they want to know more about, they have the ability to look at the data behind it. For instances where this isn't built in, I will normally build "Detail Dashboards" which act as a view of the lowest granularity of the data.
What's even more important than providing this detail is how you communicate its availability. If you just casually mention it, the user is more likely to just bypass what you've built and go straight to what they know. An approach that's more likely to work for you is to communicate the benefits of the dashboarding process (e.g. faster and deeper insight), while providing the relief that the data is all still there. I will normally say something along the lines of:
"I don't have any interest in taking information away from you. In fact, just the opposite. When were done the data will still be there, but what I hope we can do is help you identify what you're looking for so you don't have to dig through piles of numbers. If you find yourself digging, we'll revisit the purpose of the dashboard."
Remember, dashboarding is an additive process. We do it because it helps the way we approach business.
Change Your Process Approach
One of the most popular reasons you'll find yourself looking at the kitchen sink is because you started with the kitchen sink. Insight from data is rarely gained from throwing everything at the wall and hoping something sticks. It starts with questions, business questions.
When you start a new dashboarding project, the first requirements gathering session you have with your end users (formal or informal) will dictate the remainder of the process. I always start with a basic outline of what I want to accomplish:
I want to know the business questions that you need answered every day and how you would rank them by importance.
That's it! By looking at the dashboarding process as the creation of a business solution, instead of a data organization exercise you can change the way the process is viewed by everyone involved, including yourself(!). It will be important to caveat this discussion by saying that you can only provide answers where the data is available, but now you have your audience thinking about the future as well. What other data should we collect? How can we answer a new business question tomorrow?
So, make sure you give them detail somewhere and try to solve problems instead of just reorganizing there data.