With BI reporting, you will greatly reduce project time and increase impact by spending more time on design and wireframing up front. In other words: go slow to go fast. Our recommended approach may seem paradoxical, but if you’ve ever been frustrated by marginal results after a quick report build, you’ll want to minimize the never-ending iterations that invariably follow.
Thoughtful report design prevents rework
“If you don't spend time on good design, you invariably end up doing lots of iterative redesign.” - Brick Thompson, CEO, Blue Margin
Blue Margin builds in a distinct design phase for each dashboarding project to align on the business case and most important metrics that will drive better decisions, prioritization, and accountability. Get those right, and you’ll improve your business outcomes. Resisting the temptation to jump into development for quick delivery, we’ve found the real value comes through careful design. It produces dashboards that people adopt, that ‘touch the nerve’, and that prevent rework and wasted effort. Experts agree that reports developed with situational context deliver the best results and require fewer iterations (Knaflic, 2015).
Create contextual BI reports
To develop strong contextual dashboards, report developers should be asking end-users questions such as:
- What value will this report generate?
- What metrics do you view on a daily basis?
- What further questions do those metrics raise?
- What decisions do they lead to?
- What outcomes are impacted, and by how much?
“[In design], we start with really understanding what's most important for the business user. Ultimately, this is going to lead to greater adoption of the reports once they're developed.” - Will Trickett, Senior Data Visualization Engineer, Blue Margin
In the podcast episode, Why Spend Time on Report Design and Wireframing, Brick Thompson, Blue Margin’s CEO, and Will Trickett, Senior Data Visualization Engineer, discuss the cost savings (and other benefits) of beginning reporting efforts with thoughtful design and wireframe reviews. They also share why a consultative approach (rather than order-taking) by the report developer leads to more effective dashboards and stronger adoption. After all, the goal is to incorporate key data into your thinking. Dashboards that don’t get adopted are a waste of effort and create resistance to future efforts to become data-driven.
Listen to the episode below or read the full transcript.
For further listening/reading:
Resources
Nussbaumer Knaflic, C. (2015). Storytelling With Data. Hoboken: John Wiley & Sons, Inc.
Full Transcript
Brick Thompson: 0:02
Welcome to The Dashboard Effect Podcast. I'm Brick Thompson, Founder and CEO of Blue Margin.
Will Trickett: 0:07
And I'm Will Trickett, Senior Data Visualization Engineer here.
Brick Thompson: 0:10
How's it going, Will?
Will Trickett: 0:12
Going pretty good. It's been a good day so far. How about you?
Brick Thompson: 0:14
It's good. I'm glad to sit down with you. We haven't done a podcast together yet. And I'm looking forward to having a chat.
Will Trickett: 0:20
Yeah. Likewise. Thanks for having me on.
Brick Thompson: 0:21
Yeah, you bet. So I think today, we're going to be talking about design and the reasons that it makes sense to do kind of extensive design before actually getting into building reports. What are your thoughts on that?
Will Trickett: 0:37
Yeah, so we've had a lot of experience here at Blue Margin, doing design phases with clients. And, you know, I think when we when we first started out, and when I had first come on board, we did a lot of projects where we would just kind of jump straight into development. And we didn't take the time we needed on the front end to do designs. We realized pretty quickly that that was leaving us kind of fumbling, sometimes to fulfill the requirements for our projects, because we didn't do the diligence that we needed on the front end, to really understand the user requirements, understand the report requirements. And so we started to really introduce these design engagements with almost all of our clients. And we've just seen it yield a lot of fruit. So I'm excited to talk through kind of some of those values that it brings.
Brick Thompson: 1:21
Yeah, good, good, good. I'm looking forward to that, too. I know it can be really tempting, when you're especially when you're new at building reports, you sort of feel like, okay, I'm just gonna start building.
Will Trickett: 1:32
Right.
Brick Thompson: 1:32
The user told me that they want a report that shows profitability by month, great, I can do that. But almost always, it pays off to do more diligence and really figure out exactly what report is going to deliver the highest value. So so how do you how do you get at that?
Will Trickett: 1:53
Yeah, so the thing that we start with is really understanding what's most important for the business user. And ultimately, this is going to lead to greater adoption of the reports once they're developed. You know, one thing that that I like to kind of compare is like an airplane dashboard compared with a car dashboard. Right? So when I was a when I was a kid, we got to travel to Hawaii. And the pilot invited me up into the front, I got to sit down in the cockpit and look at all these dials and stuff, right? And it just blows your mind all these different gauges and instruments. But if you asked me like, what do these things mean? I would say I have absolutely no idea, right? It's just a bunch of data. It's a bunch of, you know, things to look at it, you know, contrast that with me jumping into my car now. And I look at my dashboard, I can see, you know, is my fuel tank full or empty? How fast am I going? Right? Is my oil light on? Right, right? You're gonna need to, you know, do something that hopefully not Yeah, hopefully not. So, you know, that quick insight that you can get from looking at your car dashboard is what we're really looking for in a report. We need to understand what's the key things that you need to know, as a business user, not the, you know, 120 things that an airplane pilot may need to know, which could be valuable. But ultimately, you're going to become overwhelmed with data and not really have quick action that you can take.
Brick Thompson: 3:18
I think I know what you're talking about, because I'll see examples of reports that the report writer/report author was really trying to deliver a lot of value. And so they crammed everything, and the kitchen sink into that report. But it makes the report really hard to read. And ultimately, I think the most successful reports are the ones that are intuitive, sort of like a gas gauge, or an oil light, where you don't have to think about it. I sometimes say this is not a knock on my mom, she's 83 and not super technical. And I often will say to people, look, if I can show the report to her, and she can tell me, even roughly, hey, it looks like on that report, things are going well or not. I probably hit about the right level. Now maybe that's a little extreme. Because people with context of a domain, you can get a lot more detailed than that. But you want to be thinking about it that way. So it's sort of at a glance, I get it.
Will Trickett: 4:19
That's exactly right. And I think especially for users at an executive level or leadership, you know, they don't have time to sit there and try to understand all the different pieces of it. They need something that they can just pull up, maybe it's on their phone, on their computer, get a quick pulse and then move on with their day. So I agree, as simple as we can make it, the better.
Brick Thompson: 4:40
Yeah, I think of your annual physical to write you get to the doctor's office. There are probably hundreds of tests they can run, but they start with pulse, weight, blood pressure. If something seems off, then maybe there's more tests to do, but you sort of get a quick, quick feeling. So yeah, yeah, exactly. So how do you go how do you go about working with a business user who needs a report to do that design?
Will Trickett: 5:05
Yeah. So it starts by asking good questions as a report builder. I think that, you know, as a business intelligence expert, you bring the ability to create a solution that adds value to an organization. But you don't necessarily bring the context of the organization. You're trying to gather that from the end user. And so, you know, when you come into those design phases, you need to ask questions, like: What value is this report generating? What metrics do you look at on a daily basis or need to look at on a daily basis? What questions are those answering? What actions does that lead to? etc. And I think as you start to explore those different pieces, you can really start to get into the head of the business user, not in a weird way. But in just, you know, here's, here's how they think here's how they run their business. And it allows you to make decisions as you build that really touch a nerve for that user versus just trying to build everything.
Brick Thompson: 6:05
I love it. It two things you said there that I really like, because I think of this when I'm thinking about good report design. What what questions does it answer? Are those high value? And what behaviors might the report drive? So when you see something on the report, does it cause you to do something good to either improve the situation or keep supporting a thing that's going well. There was something else you said, which which made me think of the fact that a good report builder is not only an expert at the technical tools, but also has to be able to think a bit like the business person, right? They have to, as you said, "get in the head of the business person." So if they're not able to do that, and sometimes we'll see this, especially at clients. They'll have a report builder working at the company, whose good at driving the BI tool that they're using, but not good at (not as good at) thinking about, "what's important to the business here?" And so they end up building reports that are sort of, sort of as an order taker. So someone will come and say, "I need a pie chart, you know, with 50 slices," and they say, "Sure, here you go." And, and, you know, as you know, as a Senior Visualization expert, you know you don't want that. Right?
Will Trickett: 7:23
So yeah, I think it's, you know, the classic example is like the difference between a fast food employee versus someone who's, you know, a waitress or a waiter at a really expensive restaurant, like, the person that you pull up to the drive up window, and they take your order, you know, they're not thinking about like, advising you on what you want to eat, you just order your burger, you get your fries and your drink. You're good to go. But if you show up to a gourmet restaurant, right, you're gonna probably ask them, "Hey, what wines should I consider here? What are some of your best offerings?" Right? And you start to really, actually have an interaction about, you know, what's, what's good/ what's not. And that's the kind of person you want to be as a report builder.
Brick Thompson: 8:02
I love that. I'm gonna steal that analogy. That's perfect. So I think one of the things that comes out of really good design and doing design before you build is almost paradoxical to the business user. And that is that it actually minimizes the total amount of work. Because if you don't do good design, you invariably end up doing lots of iterative redesign. Would you agree with that?
Will Trickett: 8:28
Yeah, that's absolutely right. And we've seen that before where, you know, we jump into a report build, and it's not entirely clear what the final deliverable is, right? We know that we need to, you know, get a report that the user is going to find value in, but in terms of how it's designed, and the way that it's structured, that's not, you know, really aligned on. And what happens is, you build version one, and you send it out, and they say, "Well, this looks good, but like, we want to see this, too, and this too, and you know, that visual should be over there. We don't really like the colors." You know, there's only so much that you can do, then you have to sometimes just recreate a lot of the stuff that you already built. And so that can happen multiple times, and the end result is you end up, you know, having a much longer timeline than if you had just started from the beginning really taken time to, you know, what we do here is we wireframe. So build out a mock up of the report. Make sure that it is going to meet the user requirements and then build to that. And then usually the, you know, there's always some iterations that occur, but they're usually much more minimal than if you just start building.
Brick Thompson: 9:32
Yeah, okay. So the wireframe just to help define that, for people who may not be familiar with the term is is sort of a hand drawn on a computer, but hand drawn representation of what the report might look like. And that really allows then the report builder to get in sync with the business user about the layout, and what KPIs are on it, and where they might be and so on. And it really allows you to test some design assumptions and design elements for very low cost. Because you can do that by hand very quickly,
Will Trickett: 10:06
Right. And you'll, you'll end up switching visuals so much during the wireframing, you'll build it one way, or you'll draw it one way, I should say. And then you'll say "Ah, you know, this should actually be over there." And you do all of that work, like you said, at a very low cost. So then by the time you have the stamp of approval on the wireframe, you're pretty sure that this is what they want to look at once they see the final report.
Brick Thompson: 10:27
Yeah, and there's more behind it than just turning that wireframe into a report, you know, dragging a graph onto the page or KPI indicators, that type of thing. But you're also determining what your data model (that supports the report) is going to have to look like. And so if you think you know, what you need to do, maybe, and ask your data team to build you a data model to build a report on you may be way off. And so you sort of get a double whammy of, "Okay, I now need to iterate the report and any data in the data model." And so, spending that time up front really allows you to get it nailed down before you do that data work,
Will Trickett: 11:08
right. And it's the same reason why, you know, when someone goes to build a house, they hire an architect first, right? You don't want the plumbing to come up in the wrong spot of the wall, and you can't connect your sink there, right? You don't want you know, the foundation to be off from where you want to actually put your kitchen or whatever. You need to take the time to make sure that that structure is in place to then build to specification. So yeah, just in that same way, it's really helpful for an architect to know, here's what I need to build to. And then it just minimizes all that additional back end work on the in the later phases.
Brick Thompson: 11:45
That's great. You know how much I love analogies. You just gave me a second good one. Just in this short podcast. I appreciate it. That's great. All right. Well, anything else you want to say about this topic?
Will Trickett: 11:58
You know, I think that this is probably one of the more overlooked pieces of development. I think anyone can build a clean looking report, not anyone, but a lot of people can. And they can, you know, create measures in Power BI, they can design a dashboard, but to really take the time on the front end to understand user requirements is a learned skill. And it's something that I think is worth investing in because it's going to lead to, in my mind, the best results. So definitely suggest really taking the time to do that upfront.
Brick Thompson: 12:31
Yeah, I completely agree. All right, Will, I've enjoyed our discussion. I really appreciate your time and I look forward to sitting down with you again soon.
Will Trickett: 12:39
Likewise. Thanks, Brick. See ya.
