The Hidden Complexity Behind Simple Dashboards

Designing a dashboard might seem straightforward, just add charts, metrics, and a few visualizations. But the dashboards that actually help businesses make decisions often look surprisingly simple.

In this episode of The Dashboard Effect, Brick and Landon talk about why the most effective dashboards are usually the simplest to read, and the hardest to build. Behind a clean dashboard is often a lot of complex data modeling, business rules, and engineering work that makes the information accurate and easy to understand. 

They walk through real examples, including salesperson ROI dashboards, accounts receivable reporting, and price-volume-mix analysis, to show how much work happens behind the scenes to create dashboards that people actually use.

If you’ve ever wondered why some dashboards get ignored while others become essential tools for decision-making, this episode explains the difference.

Learn more about Blue Margin:
https://bluemargin.com

Transcript

SPEAKER_00 0:04

Welcome to the Dashboard Effect Podcast. I'm Brick Thompson. And I'm Landon Oaks. Landon, we wanted to talk in this episode about simplicity in designing dashboards and why often it might seem like a complex-looking dashboard with lots of colors and lots of visualizations and all sorts of things going on is a higher value dashboard than one that is simple, maybe has three or four or five visualizations and a couple of bright KPIs. Often that simple one is actually far more value, or brings far more value and is a lot more valuable for the company. When we think about designing dashboards here, our analytics engineers are trying to figure out how do they get the information to the viewer as intuitively as possible. Sometimes we say, could you show it to your elderly grandparent? And they would know maybe not exactly what's going on in the business, but they definitely would know how it's going. And so the business user is able to look at it and really quickly infer how it's going and it can drive decisions and actions quickly. Those are the dashboards that end up getting adopted well by businesses and actually giving ROI. But there's sort of a an unexpected thing, which is those simple dashboards are often the most complex to put together behind the scenes. And so I thought we'd just talk about a couple examples of that.

SPEAKER_01 1:37

Yeah, definitely. I think um to your point, the simpler the better. And I am uh I'm a bit of a I I have a bit of this problem where you know it's very easy for me to of to ignore all the dashboards and work on my day-to-day work. But I have this one specific one, really, really simple, um, that just simply shows me how much hours my team logged and what they should have. I reference it all the time because I look at it for about two minutes.

SPEAKER_00 2:06

And it should it, you know, very quickly whether they're meeting utilization targets and that type of thing. Yeah. So you can have a simple dashboard. Uh uh, we went and looked for a couple of examples of what might look simple but take a lot behind the scenes. One of the ones that we did for a client one time was a salesperson ROI dashboard. And so they wanted to be able to see how is a new salesperson performing against an expected baseline over their first 36 months in the business. Um, and one of the complicated things they had was that the new salesperson often inherited existing accounts from a departed salesperson or someone that moved to a different uh division or uh group. And the logic to make that work correctly so that you could give the new person credit for the old person's sales and show that correctly on the sort of the line chart against the baseline and give good numbers about what is the actual profitability of this salesperson, at least profitability contribution, took a lot of work. There was a lot of modeling, a lot of getting the data right, a bunch of sort of sorting through business rules, working with the business managers and the owners of these uh areas to figure out what's the right way to re represent this and then do that correctly in the data. It seemed obvious when they were laying out the requirements to us. Okay, that sounds simple enough, but when we got down to building it, we realized, oh, there's a lot more to it. And that's a that's a pretty common thing we find. And in fact, in order to make the uh report or dashboard as simple as possible and as effective as possible, you often end up with those complexities behind the scenes to get them really good and make sure they're validated and that type of thing. You you were mentioning a different example. I think it was point-in-time accounts receivable or AR reporting. That's one that you've worked on a number of times. Maybe you could tell us a little bit about that.

SPEAKER_01 4:07

Yeah, definitely. So you know, point-in-time AR is uh a bit of a word that strikes some fear into some people where you know you just want to see at what point in time did this customer what did they owe? Um, what was the aging at? And so in general, you know, some ERPs have a way to sh to go back in time and say, you know, as of last month, what did my top customer owe? Um others don't have that ability at all. You can only see your current AR of zero analysis. Um so it's one of those things where the back-end work is more than you would think, right? So there's two ways to really accomplish it. One is the kind of easier way, which is to just simply take a snapshot of your data. So you just say, yeah, what's my AR right now? Okay, I'm gonna take a copy of that, I'm gonna put it over here, and then I'm gonna stack them all on top of each other. Um the one issue with that is people make mistakes, right? Somebody will enter the wrong, they'll put an extra zero on the end of a check or something, you know, that comes in. That's a huge difference.

SPEAKER_00 5:10

Aaron Powell And so they'll have to go back and correct that, but your snapshot maybe doesn't get it.

SPEAKER_01 5:14

It's solid, it's stuck in time.

SPEAKER_00 5:16

Yeah.

SPEAKER_01 5:16

So, you know, where where a lot of the complexity will come is you ideally want to avoid those mistakes. Um so what you can do is you know, you you actually go look at like, okay, here are my invoices, here are my payment history. I'm gonna merge these two up. I'm going to recreate history over time. And what that does is when somebody makes an update, it also updates your history. And that can be quite complicated. You know, you have invoices, credit memos, um, returns, all kinds of different transactions that can go into it that you need to figure out how do I handle these specific transactions, what do I need to ignore, et cetera? Um that yeah, it turns into a bit of a back and forth. And a lot of times we'll we'll kind of show data to the to the customer that they didn't even know was happening. They'll be shocked by it.

SPEAKER_00 6:03

Aaron Powell It is interesting. So you do all that work. The snapshot does seem pretty straightforward, but there's still some implementation issues. Doing it the way to reconstruct it so that you catch those changes uh is a lot more complicated. The end result, though, often looks pretty simple. You might see um AR balance over time on a line chart. Um you might see, you might want to be able to see how does that balance change by um the the buckets, the aging buckets. So my 30 to 60 days, how is that how's that bucket changing? How is my 60 to 90 day bucket changing, that type of thing? It looks simple on the page, but to make that happen really well can be really challenging. You can get your DSO out of it, and how is my DSO changing over time? Again, usually a pretty simple line chart. But the engineering that goes into the back end to make that happen and to make it actually correct and useful takes a lot of work.

SPEAKER_01 6:59

Yeah, absolutely.

SPEAKER_00 7:00

So another example we thought of was uh price-volume mix. This is a pretty common thing that people want to see. How are changes in price and changes in mix, changes in volume, how are all those things affecting our top line, our sales. And so very often that uh chart or report looks like a waterfall chart. Um pretty simple, simple chart to look at, simple to interpret, but to get that right on the back end so it's actually reporting the right data takes a lot of work. And it usually comes in the form of the fact that every company thinks about those calculations a little bit differently. And so you can't just apply a simple template to that. You really need to go deep with the people in the business that understand the business rules around that, and then code that into both the data modeling and into the measures and the KPIs so that it comes out correctly. This is one where I've definitely had the experience with a client where they're saying, how hard could it be? I'll just drag a waterfall chart under the table, connect it to the data, and it's there. It's not that simple. There are so many things that can make it go wrong. And uh and in fact, that example I was thinking about, um, you know, the client showed the client an example of that. He said, well, that's not how I want it at all. And then it all sort of clicked. Okay, we need to do all the groundwork to make this come out right. So I guess that's just another another example of uh of how that can happen. And this happens all over the place. I mean, maybe not every report. Some truly are simple, but pretty much.

SPEAKER_01 8:39

Yeah. Yeah. And I mean, even to add on to it too, is um at the at behind all these reports, you have what's called a model, right? It's the backbone of everything. Um so you're not just building a model specifically for salesperson ROI, specifically for AR. Ideally, you want that thing to be able to be used for other areas of the business too. Right. Because part of the issue is is, you know, if you have like in this case, we have three different completely separate models, that's a lot of work to keep those updated and maintained over time. Um so, you know, it's almost like complexity for simplicity, right? You're you're gonna make it a little more complicated to be able to make this thing reusable, however, your your future self is gonna thank you.

SPEAKER_00 9:21

Yeah. It's almost like if you see a complex report, even though they can look pretty and sort of fancy with lots of dials and things going on, it's probably an unfinished report, an untested report. It hasn't been tested in you know, in an actual live fire. Because if people were using it that way, they would immediately request changes to make it simpler to read. So yeah, complicated in terms of the final view is not necessarily better, almost always worse.

SPEAKER_01 9:51

Yeah, absolutely.

SPEAKER_00 9:52

So all right. Well, great. Just wanted to cover that. Thanks for the discussion. It was interesting.

SPEAKER_01 9:57

Yeah, thank you. All right. Uh one final note if you uh like our content, what we're discussing here, don't forget to like and subscribe for for more to come. Or uh navigate on over to blue margin.com where we have uh a history and other useful articles you might like.