Everyone wants to consume and understand large amounts of data. But how do you plan, design, and implement a good dashboard?

In this What’s Your Baseline Shorts, J-M and Roland walk you through the process and the considerations at each step, so that the next time you create a dashboard (for example as part of your Process Mining analysis) it will be stakeholder-oriented with a clear visual hierarchy that will make your users understand your message easily and quickly.

In this episode we are talking about:

  • Identify your stakeholders and information needs
  • Define KPI and measures
  • Create a solution design
  • Build the dashboards
  • Identify data stories
  • Roll-out dashboards

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Additional information

There is no additional information for this episode.

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

Roland: Hey, J-M, how are you doing today?

J-M: Hey Roland I’m doing alright! I’m excited to be recording another What’s Your Baseline Shorts!

Roland: Yeah, I see you have a different studio today.

J-M: I know. I’ve moved, but hey, it’s a different studio but the same high quality What’s Your Baseline short fun we have and today’s topic is something that’s really near and dear to me, which is all about creating dashboards. I know a lot of people do this for a ton of different reasons, but they often get it wrong or struggle to deliver the message that they’re looking to deliver to the right people at the right time. So, Roland, I know we struggle with this a lot as well, but what are some of our lessons learned – let’s start having a conversation because this is a tough topic, but it’s really important.

Roland: Yeah, so first of all, tell me: what is a dashboard? Is it the weekly status report, you know, the Powerpoint slide or the Excel that you have filled up with macros?

J-M: Well, really a dashboard can be anything! Think about dashboards as a way of visualizing data sets that tell a story. So it could be a chart in Excel; it could be a status report that has visualizations that are able to capture and showcase what’s going on. But from my perspective, what makes a dashboard really powerful is when it’s able to provide the right information at the right time, and that means that a lot of dashboards aren’t just static things; they are dynamic. They’re ever evolving as the circumstances that the dashboard is looking to measure change. How about you, Roland. What do you see is the most important thing for dashboards?

Roland: Yeah, I would have it a little bit narrower from a definition perspective. I would say a dashboard is something that you do in a dashboarding tool. It’s not just filling out your standard Powerpoint template that you’ve schlepped to the status meeting every week. But I agree, the topic here is data storytelling. And I see a lot of things where this goes south, you know, because dashboards sometimes are just an afterthought in the project. Like “oh shoot we need to put something on the screen, we need to monitor our KPIs” all these things. So what I see (and what I actually don’t like) is that one size-fits-all dashboard design where you see a gazillion KPIs and things move and you have whatever animations and what not, and that just kills me.

J-M: Yeah and that also implies something really important – one thing you need to think about when you’re looking at dashboarding: it’s not just who you have in ‘sent’ on the email trail, there needs to be some sort of permissioning and segmentation in the way you do your dashboarding. The right people need to see this. And so first and foremost, figure out who those people are because if you’re designing a dashboard for everyone, no one gets any value out of it. When you design a dashboard for one role / one particular thing they’re looking for / a family of KPIs / a collection of insights, now you’ve got a real targeted solution.

Roland: I agree. So the first thing when I do dashboarding projects is to take a step back, and just as you said, look at the stakeholders. Who is it for and what is the information needed? And then I simply create a matrix and I say “ok stakeholders here, information needs here” on a veryvery high level.

J-M: Also, remember that your information needs, aren’t the KPIs necessarily. The KPIs describe how that information is communicated to you. So if you want to understand “how often do we satisfy our SLAs”, the KPI around that might be a very specific thing like On-Time Delivery, In Full (OTIF). So it’s one level of abstraction beneath that.

Roland: Right, that’s the next step. But the first step is to rationalize who it’s for, who it’s not for, and what’s the big bucket that you see. And when you fill out that table, what you will see is that some of the stakeholder groups share information areas and they need to look at the same thing. The next question, though, is do they really have to look at this same thing or do they look at different KPIs? You know, one might be more aggregated than the other one that’s in much more detail.

J-M: Yeah, and if I’m trying to struggle for KPIs – for instance, if I’m a company that hasn’t donea lot of this measurement before, where can I find that information? Because I know that a lot of times people are kind of making it up or, using best guesses, sort of buying it off the market. What are some common places you might go to get those?

Roland: So I would look first and foremost at two areas. So if you look for operational KPIs, I think a good address is always the APQC (the American Productivity and Quality Council). They give you KPI definitions and explain why you should measure this or this. And the other one would be maybe in specific work groups. Think about the Supply Chain Council and their SCOR model. What do they look for in supply chain situations? And look at those (and this brings us to the second step), and define your KPIs. And one thing that I like to do is to create a KPI tree. Say “oh for this dashboard, we want to look at for example technical KPIs”, and I decompose them. You know, how many documents go through that interface or what’s the up time of my service. I want to have process KPIs based on those frameworks – do I produce the right amount of widgets in the right amount of time and the right amount of quality, for example. And in that KPI tree, what I like to do is not only put in the KPIs but I also put a little description on the side of it to say “oh yeah, we’re measuring this because that’s what you actually want to know”. And that helps them figure out where you get the measures from.

J-M: Exactly because otherwise you’re going to be saying “oh, I’d love to know this stuff” but you haven’t got your systems configured to actually capture that information. So when I see KPI trees, my next question is always “where does that data come from?” and “what format is it served up in?”. Remember that if you’re looking to fill dashboards, it can be an incredibly tedious and arduous and manual process if you’re just exporting a table into a flat file, doing some Excel magic on it, and then populating it into your BI tool. That’s incredibly cumbersome. You want to try and find ways of hooking into those systems so you’re not having to do this manual pull and push every time.

Roland: Yeah, but those junior consultants usually don’t cost a lot… 🙂

J-M: I see you haven’t paid for a lot of their invoices, oh boy!

Roland: But in all seriousness, I’m with you. So you not only have to find the systems that you want to pull data from, you obviously have to define the format; you have to define the sequence, how often you get it – is it real time? Is it a batch that runs every day, every two days or whatever?

J-M: Can I just interject here? A lot of people love to say ‘real time’. They always want real time. And I always use the words “relatively real time”. You want to get data in as fast as you can make decisions about that data. So if you’re making a change on how your supply chain is working you’re trying to interject in the middle of a flow, your supply chain / your end-to-end is going to take you like thirty days and you get data every minute, you’re not going to be able to make changes and act on that data every minute you’re just wasting system resources. Get data as frequently as that data is useful to you. Real time is expensive, and that’s overkill.

Roland: Not only that, take it from the old man with a gray beard, the person in front of the screen needs to be able to process what he or she sees. And we as humans are typically not as good at doing the real time thing. I wholeheartedly agree with you – maybe a daily update is sufficient or every four hours or weekly or whatever it is. The other thing is, and I think our listeners will already get a gist of it, dashboard implementations are actually implementations. So in my opinion, you need a solution architecture. So we started with the information needs, you know, what are the objectives. We looked at the KPI tree – oh, guess what, what do we want to know? We looked at the applications and the measures, so we go down even further. So what I would recommend is go and create a “solution architecture document”, create a bunch of graphics and charts that you will create (wireframes and all these types of things), and shoot them around. Ask your stakeholders, “is that exactly what you want to know?” because then you might see something like Stakeholder 1 needs to know the same as Stakeholder 2 but I can re-use this thing for Stakeholder 3 as well. That special information from that one system.

J-M: Yeah, you’re talking about collaborative and iterative design. If you’re not talking to people and you’re not iterating on your dashboards, you’re more likely to produce things that A) aren’t well vetted so you haven’t had a chance to go through and hone it, and B) aren’t what they need because you haven’t had a chance to talk to them about it. So talk to people and iterate on dashboards.

Roland: Oh, I agree. That’s the process behind it.

J-M: And the thing you’re iterating on is the design, right? Moving into the solution design part of things, one of the things I love to look at is wireframes, right off the bat. I want to present information to stakeholders before I actually go and implement it with how it might look in there. And remember in your wireframes, you’re also trying to understand storytelling and emergent features. If you’re not sure what emergent features are, think about it like this. If you’ve got a bunch of dials that tell you what the normal range for something is and they’re going to be pointing straight up and down, and you layer them vertically. What people are going to see is a straight line when everything is good, and instantly they’ll understand and see if there’s any variation in that line that those four widgets create is broken. That’s what we call an emergent feature – when multiple widgets interact with each other and you can use that as a meta analysis of all that data.

Roland: But use it when you do your wireframing – use it in the first place as low fidelity. Take those black and white squiggly-line pencil drawn sketches (if your tool supports this) and do this because you want to tell the story. Where do you go on that screen from (in western countries) upper left hand side to lower right hand side. How we read it here. The other thing that you should do, once you have that and you have the high level story being there, you should start establishing a style guide. Your information is a hierarchy, so think about what’s the most important thing that you want your stakeholders to see first. So that means, most likely, the widget that has that most important information will be the most prominent that you have. The biggest one and the other ones are smaller. Or think about formatting and think about headlines. Put text beside your widgets that explains what somebody sees, you know, because otherwise they might shrug and think “oh yeah it’s just another bar chart.”

J-M: The other piece of the puzzle is understanding what we call measures and dimensions. So what are you actually calculating and how are you filtering it? And helping to provide things like filter conditions for people so they can quickly segment the dashboard to a condition that they care about most. That’s going to be both part of your data structure but also part of your presentation design. So add filters at the top, which are easy to quickly drop down, as well as selector boxes, and suddenly the data matches what you’re looking for.

Roland: And keep it simple! Don’t have too many widgets on your dashboard and one widget answers exactly one question. Don’t try to do multiple things in one widget, and then you have to have twenty five different filters applied that nobody will remember how to do once it goes live. So keep it simple for your users – so if you have four types of information that you want to convey, have four widgets.

J-M: Exactly, and then the next piece of the puzzle I like to think about is the meta analysis of dashboards. Because one of the things you’re trying to do is you’re trying to tell a story, so lining up your dashboards in an order and your widgets in an order helps people traverse that story. So what did we do here, then what happened? Okay, then how did that interact with a vendor; how do they interact with our people, how did that tie in with process or task mining, where did I get that information from, and how am I going to live the process through looking at my dashboard so I can quickly understand where something might be off or something might be broken because my story no longer makes sense. Figure your stories out. Tell good stories. And then when they’re broken, you can quickly see them and be able to know where to react.

Roland: And I think we’ve come full circle, because the story for one stakeholder might be a different one then, than the one for the other one. So what happens then? You’ve built all that, you went through UAT, everything is fine, everything works, your data pipes work and all that wonderful stuff in the background, what do you do next, J-M?

J-M: You’ve got to roll them out. You’ve got to give people access to these dashboards and first and foremost, it’s not just turning it on because that’s going to give you a bad result. It’s enablement that goes alongside in turning on this functionality. That’s going to be walking people through the stories that you’ve drawn out; walking people to the widgets; showing the features and functionality and options for filtering and dimension calculations, and showing them what kind of information they can get from it and what they should do about that information. Draw up their “day in the life” of using the dashboard and help them live that by giving them the enablement they need at the time you’re rolling it out.

Roland: Absolutely, and what I would recommend to do is in your dashboard, most of them have some form of tabs. Use one of the taps to explain what people see.

J-M: Like a legend.

Roland: Yes, it’s a legend, if you will. People read it one time and then they get it and they just look at the other tabs. The other thing that I would recommend is some of the dashboarding tools that allow you to put notes to your individual widgets. You can say, “Oh yeah, I have a barchart and it goes like this and there’s a trend line in there” and then you have maybe in a corner a little circle with an [I] for information in there, and you click on it, and then it explains what this widget does. Like “when you look at the different data lines, the trend line will give you this while the bars will give you that information.” And then the last tip that I have is to give every widget a title and a sub-title. So the title is “what do I see / what is this widget all about?”. You can articulate this as a question, if you will – “how many escalations do we have in our incident process?”. But then in the sub-title you put some high level explanation there – “these are escalations in total, it does not show cases that have multiple escalations” – where it goes from a Level 1 to a Level 2 to a Level 3. Because there might be another widget that shows that. But the title will give you a first understanding of this is the total universe of my escalations, and by the way out of the total universe (second widget) this is the subset that has whatever multiple escalations.

J-M: That makes sense to me; Roland. Well, I think we’ve heard a bunch of different things today. We talked first about stakeholders, then about KPIs, measures, systems you’re grabbing those KPIs from, the dashboarding design through first and most wireframing and then creation of widgets and emergent features and storytelling throughout the whole life cycle and then some tips and tricks to make it all come together with good visualization for good data. I have to say, this is a ton of fun, my friend! Hopefully everyone takes this away and loves what we’re doing, likes subscribes and shares all this stuff about What’s Your Baseline and goes to www.whatsyourbaseline.com for lots more about all of this. Well, for the last time in this one, my name is J-M Erlendson

Roland: And I’m Roland Woldt

Both, somewhat together: And we’ll see you in the next one.