Video Transcript

Hello again everyone, welcome back to This Not That, or TNT. This is a vlog where we talk about a best practice in business intelligence (BI) and contrast it with a common mistake. Today we’re going to be talking about a general principle that most applies to the data visualization stage of BI.

There’s a temptation sometimes when we start working on a project to spend a lot of time and focus on putting together what we’ve been asked to do, waiting until the last moment when the project is due and then BAM, present this beautiful finished product to the person that is going to be using it. Now the problem with this approach is that all along the way we miss opportunities for user feedback.

I have often spent hours building a dashboard, only to present it to the client and they say:

"Oh, that’s totally not what I wanted. I know it’s what I asked for but actually what I want is this other thing over here."

So to get around this problem, I encourage you to look into the Harvard School of Design. Harvard School of Design talks about this process that is very iterative as opposed to very big bang with the goal of iterating through a project as quickly as you possibly can for the best outcomes. They did some research around this. They took a pottery class and graded one group of students on the quality of a few pieces of work produced and another group of students on the quantity of pieces of finished pottery that they produced. At the end of the year they did a blind study to determine who had the better pottery and it turns out, if you churn out pottery as fast as you possibly can, if you make mistakes as fast as you possibly can, you end up being better at your job than a group of people who do a few things slowly.

So how do we apply that to BI? As early as you possibly can, take a rough draft- an incredibly rough draft, make up the data if you have to- and show it to your end user. Ask them:

• What do you like?
• What do you hate?
• How could I make this better?

Then take that feedback, go away for a day, implement the changes and bring them another draft. Going through this one change at a time process will ensure you’re not investing hours and hours and hours and hours into something that won’t end up making your client/stakeholders/end users happy.

Another way to do integrate this iterative approach is with your data intake. As you’re pulling in fields, stop and ask people:

• Is this what you were expecting?
• Is this what you want?
• Do we actually need this information?

Otherwise you could end up with tables that have dozens of columns that no one actually cares about or uses anymore.

So in your processes, focus on being iterative. Fail fast. Fail with as little time invested as you possibly can. And then from those failures learn what success looks like. You’ll get a lot further that way than if you take a big bang approach.

Thank you for watching. If you have a comment, we would love to hear it. Or if you’ve got a best practice that you would like to see used more often in the BI community, let us know. You can follow us on social media or head to our website.