The Real Challenge in Data Storytelling: Getting Buy-in for Simplicity
I have always had a knack for telling stories. You know, finding patterns and building pictures that make sense.
I had read the principles, and honestly, I thought I had it all figured out.
Ask the right questions before you open your visualization tool, and focus on telling one clear story rather than a collection of metrics.
With all of these, I felt like I had broken the code.
I didn't know it was that simple.
The hard part was getting others to buy into that simplicity.
What surprises me is how often the parties back down. In the sense that they will ask for more metrics, more classifications, and more of everything.
And suddenly, you're stuck between the principles you just learned and the realities of deploying a dashboard.
This is the part they don't tell you about in lectures.
This article addresses that gap.
I'll walk you through what happened when I tried to secure a simple dashboard in a real organization, why stakeholders always want to “add everything”, and the strategies I've learned to navigate that tension.
Not theory, but real tactics that survive in real meetings.
If you've ever made a dashboard so easy to watch it snowball over and over again, trust me, this is the one for you.
The problem of stakeholders
I went into the meeting feeling confident.
My new dashboard had three neat visuals: a line chart that shows the trend, a bar chart that breaks down key drivers, and one KPI card with a metric that really matters.
My boss took it out on the big screen. Ten seconds of scrolling, maybe less.
“This is good,” he said.
“But can you add regional segmentation? And maybe customer lifetime value? Oh, and what about a conversion funnel by product category?”
Oh.
My stomach dropped.
I left that meeting with seven new applications. Write down every sticky note. I still have that note somewhere, actually.
Math is not my strongest skill, but even I could see where this was going. From three to ten charts. That is quite a lot.
I got to work quickly and somehow timed my way back to my first attempt.
It reminded me of an uncomfortable truth: knowing data is one thing, but communicating well is an entirely different skill in itself.
So I did something dangerous. I created two versions.
Version A has everything you ask for: all ten charts, every metric, and many filters.
On the other hand, version B remained simple (just the way I wanted it): three observations, one narration, and a clear paragraph.
The next morning, I showed him both.
Version A first. He flipped over, and frowned slightly. “This has everything… but I don't know what to focus on.”
Then it was version B. He leaned over. “Wait. This tells me something.”
He went with version B. But he asked me to keep version A “just in case.”
That moment taught me something important: to defend simplicity is not to be stubborn. It's about helping stakeholders see what they lose when you add too much.
The signal-to-noise ratio principle applies here in the same way it does in machine learning. If you add too many factors, your model becomes overloaded and loses predictive power.
If you add too many charts, your dashboard becomes cluttered with individual stakeholder requests and loses its narrative focus.
Same problem, different background.
At least, that's how I think about it. I may be overthinking the analogy.
It's Not About the Charts
It took me longer than I'd like to admit to realize this, but the participants are not trying to make your life difficult. The truth is that they are afraid.
They are afraid to be in a meeting without an answer and maybe worried that the one metric they missed is the very one that someone will ask about.
I finally found out that my boss wasn't asking for ten charts because he thought it would be better. He was covering his bases and minimizing risks. You know, protecting yourself from uncertainty and stuff like that.
And it didn't end there.
There is also this issue of trust that I didn't think about at first.
Here's the thing.
When you simplify a dashboard, you make judgments about what is important and what is not.
Makes sense, right? But here is where it gets difficult.
If participants don't know, or haven't seen you make a good phone call before, they won't trust those decisions. That's when they volunteered to “show me everything so I can decide.”
It took a while, but when I understood that the requests for extras weren't really off the charts, I started to face what people were really worried about.
People were afraid of being caught and left unanswered. Furthermore, they no longer trusted my current judgment, which was appropriate.
This took me a very long time to understand. But at least now I know what I'm dealing with.
Strategies That Worked
Understanding why stakeholders want more is one thing. Knowing what to do with it is completely different.
It took me a while to figure this out, but I've found a few methods that really help. None of them are perfect, but they work more often than not.
Start a Conversation Before Building Anything
This sounds obvious, but I kept skipping over it. I would build the dashboard first, then try to secure my selection later. Back.
Now I start with a 15 minute interview. However, sometimes it can be less when people are busy.
Time doesn't need to be specific, it's enough to ask: What decision are you trying to make with this data? Who else will be watching it? And what happens if this is wrong?
Those questions help in several ways.
First, they show that you are thinking about their problems, not just your design principles. Empathy is an important skill in data science, especially when you need people to use what you're building.
Additionally, they give you something to reference later.
For example, if someone asks for another chart, you can bring the conversation back to the original goal, and remind them of the decision it supports, the audience it serves, and the risk of getting it wrong.
That change is important.
There is a lot.
Because now the conversation doesn't matter anymore it can be added, it's about what earns its place.
Build Trust by Showing, Not Telling
At the beginning of my career, I was trying to convince people about principles. Things like 'best practices' for solving problems or navigating specific topics.
It appeared? No one really cares. Or maybe they have a little concern, but not enough to overcome their fear of losing something.
So I stopped trying to convince people with words and started showing them the impact instead.
I started keeping the full version, but made the simple version the default.
Later, I tracked how the participants actually used them. And nine times out of ten, they'll use the simple one and never touch the backup.
At one point, the VP told me that he actually forgot the full version was there. That's when I knew we were onto something.
Know When to Compromise (And When You Shouldn't)
This one is easier than it sounds.
After enough meetings like this, I've learned to pick my battles. Not all requests are worth fighting for.
If someone wants to add one chart and it doesn't break the narrative? Good. Add it. Save your credibility for big issues.
But what if an application could turn your cluttered dashboard into a data dump? This is where I back off.
My approach now is to agree to add what they ask, but say I'm worried it might confuse the big question. Add everything, review it together, and see if it still works.
Final thoughts
Creating clear dashboards is one skill, but keeping them clear when everyone wants more? Now that's a whole different challenge.
I used to think it was about the charts. That's not the case. It's about understanding what people are really concerned about and addressing those concerns without turning your dashboard into a mess.
Some days I still fumble. I bow quickly or fight battles that don't matter. But I'm still learning.
If you're stuck between what you know works and what your organization will accept, don't worry, you're not alone. We all understand this.
