Creating Future-Proof Dashboards

If you’ve worked in BI for any length of time, you’ve faced this problem:
You’re being asked to create insights before the business has the questions.

Or you’re tasked with building a dashboard to display 50+ metrics, without any understanding of which ones matter most. Which insights should you prioritize? How should you model the data to maximize value, avoid redundancy, and ensure you can answer questions that don’t even exist yet?

Why this is the hardest problem

You can write flawless SQL, model data elegantly, and build slick visualizations in Power BI or Tableau.

That’s the easy part.

The hard part is when you’re asked to build insights before the business even knows what it’s looking for.

It’s like being told to design a bridge without knowing where it’s going, how much weight it will carry, or whether it needs to survive earthquakes.

Get it wrong, and the consequences pile up fast:

Weeks of rework on pipelines that were “almost right.”
Dashboards no one uses because they don’t actually answer the right questions.
Endless loops of “just one more tweak” that drain developer time.

For the average business user, numbers are scary!

When I moved from my Statistics degree — where scatterplots were the norm — to a business environment, I was baffled. If it wasn’t a bar chart or a percentage, no one understood it. To me, bar charts felt like a huge waste of space just to show a handful of numbers. But in business, the priority is clear: dashboards must be effortless to read and take a split second to understand, or they simply won’t be used.

Not all business users are the same:

About 90% want a simple summary with a few topline metrics and a couple of bar charts.
The other 10% want a giant data table to dump into Excel… which makes you wonder why we’re building a dashboard at all.

The real challenge is context.

Why was I asked to build this? What questions do they need answered today? And what questions will they have tomorrow?

Without that context, you’re flying blind — and you’ll pay for it later in wasted hours, broken pipelines, and dashboards that gather dust.

Some don’t even realize it’s a problem. Others have learned to navigate it — I’ve had to do the same. My approach? Start with the right conversations, plan for the unknown, and build in room to adapt.

Steps to creating future-proof dashboards

1. Speak with the stakeholder 🤯

Shocking, I know. You’ve already received a request or maybe even a spec sheet. The problem? These are often painfully high-level:

“We want a dashboard to uncover insights on campaign performance and inform decision-making.”

What does that actually mean?

Before you dive into Power BI / Tableau, you need at least one or two proper conversations where you take charge and drill into specifics:

“Compare sales to last year” → For what period? Last month, last six months, last year, all of the above?
“Share of sales by demographic” → Which demographics? Age, gender, household composition, income, country, city, postcode?

These decisions shape the data model. Without them, you’ll be reworking the entire pipeline to accommodate “tiny” changes later.

And don’t stop at the present. Ask yourself: What will they ask for in six months?

2. Plan for the future 🔮

Here’s a real example: I was tasked with refreshing an outdated Power BI dashboard. The original had countless hidden pages built over time by our BI team to answer ad-hoc queries.

Why? Because the first version was designed to answer a handful of questions only — and every new question meant bolting on another hidden page. The data was there, just not optimized for the user.

The dataset had hundreds of columns. Some were redundant, some unused, and only a few were ever displayed. I audited the whole thing, removed what had no future use, grouped measures logically, and redesigned the data model.

By pivoting parts of the dataset, I reduced the number of measures needed — switching metrics became as simple as toggling a filter. Grouping measures also allowed entire report pages to switch context instantly.

The result? A dashboard that answered the original question and made it easy to handle new ones without ripping apart the model. This led to a significant reduction is ad-hoc queries and freed up developer time that had previously been spent writing calculations for each one-off request.

All the data was there from day one — it just wasn’t structured for the questions that would come later. And that was no one’s fault: the stakeholders didn’t know what they’d need in the future, and the original build had been scoped only for the initial request.

3. Iterate, iterate, iterate 🔄

No matter how well you plan, you’ll never nail it on the first try. And that’s fine.

Prototyping always reveals surprises — in the data and in the stakeholder’s understanding of it. Once they see the first version, their vision often changes completely. That’s not negligence; it’s the process of discovery.

This is why I push for frequent check-ins on bigger builds. They keep you aligned with the evolving vision and give you space to push back on unhelpful ideas. Communication here is a skill in itself — one I’ve had to consciously work on.

It’s also about UX. A chart you think is crystal clear might leave business users scratching their heads. Early user testing is vital — fresh eyes spot things you’ve gone blind to.

This is something I actually learned from music production. After looping a track 200 times, you stop hearing certain frequencies. Similarly, after staring at a dashboard layout for hours, you can no longer spot confusing labelling, awkward spacing, or misleading chart types. A fresh listener — or in this case, a fresh viewer — will pick up on them immediately.

Closing thoughts

The hardest part isn’t the SQL, it’s communication.

With strong conversations, thoughtful planning, and room for iteration, you can build dashboards that:

Deliver real value
Minimize maintenance and rework
Are intuitive for all kinds of users

In BI, the best dashboards don’t just answer questions - they spark them.

Building Dashboards for Questions That Don’t Exist (Yet)