Over the last couple of months, I’ve been building a service. Like many services I work on, it has branching paths, and inevitably, someone asks for a dashboard.

As the only designer on the team, I found myself needing to understand why. Is it a legacy thing as the go-to solution? Is it a comfort blanket? Or, dare I say it out loud…

“Are dashboards just damn useful?”

The same thing keeps coming up every time I’m either running or sitting in a user research session: it’s not the dashboard they want. In fact, they want the balcony view it provides.

They want “wider” visibility.

They want to know:

What the heck is happening?
Is work moving?
Are we on track?
Do I need to do anything?
Can I whittle the data down to something I can digest or present to stakeholders?

The interesting bit is that the word “dashboard” becomes shorthand, or a “heavy-handed” label, for all those things, often from the delivery team themselves.

I’ve had conversations where someone starts with:

“We definitely need a dashboard.”

Then, 15 minutes into the chat, they’ve talked about data (in a table format), a filter of sorts, a notification or nudge to indicate someone is struggling with their allocated workload and many similar requests.

Not a dashboard, more a data dump.

I tell my teams constantly, it’s not my (or our) job to agree or disagree on the solution. It’s to initially work out the why, the ask and the reason, THEN lead into the solution from there.

The fun is always working out what’s lurking under the hallway carpet and finding out it’s nearly always beautiful Victorian tiled flooring, right?

Sometimes the answer is a dashboard, and in this case, it is, but sometimes it isn’t.