Data dashboard software has been around for years now, and many enterprises probably feel like their implementations can run on autopilot. That attitude is likely to lead to failure, though.
With today's easy-to-use visual business intelligence software, it's never been simpler for a business team to set up a quick dashboard. But failing to observe data dashboard best practices is a recipe for low adoption and meager return on investment.
In this interview, Mico Yuk, co-founder and CEO of Atlanta-based consulting firm BI Brainz, explains how businesses can get the most out of their data dashboard software investments. While the technology itself may be relatively simple, users need to keep a sharp focus on their goals during development to ensure that dashboards pay off in business impact, Yuk says.
What is the No. 1 big mistake that businesses make when developing dashboards?
Mico Yuk: The No. 1 mistake most businesses make is not spending enough time determining what goes into their dashboards. Most businesses take one of two approaches. The first approach is to upload their Excel spread sheet into a popular BI tool and start building charts, which often leads to having too many KPIs to display.
The other approach is to start doing discovery on their data and hoping they'll find a nugget that will give them insight. This all goes back to a lack of planning, which is why discussing what goes into your dashboard, such as the KPIs and metrics, is so important.
It's the classic 80/20 rule. Eighty percent should be spent on planning, while 20% should be focused on execution. In the business intelligence world, it's completely flopped. Eight out of ten dashboards suffer from low user adoption because the users are not really clear what actions to take.
How can a business drive adoption of a dashboard it has developed?
Yuk: Get more people involved. Today, a lot of requirement gathering sessions include less than 1% of the knowledge intelligence of a company. With the use of technology, businesses should focus on being more inclusive rather than exclusive when it comes to gathering requirements.
The second key to drive adoption is ensuring it comes from the top -- not necessarily the C-level, but someone like a VP who has to eat their own dog food. There is no better way to drive adoption than setting a good example use case and having it being driven from the top.
The third key to drive adoption is to make all dashboards and reports available on all devices. You'd think this would be obvious, but big organizations today are still focused on desktops and, in some cases, iPads. Phones are neglected due to screen size, unless the tool they are using has a native phone app. You can get adoption upwards of 20% this way by making it available on their phones. You have to meet users where they spend most of their time. That is their cellphones.
Lastly, continuity is very important. Launch it and forget it is the key to failure. Most launches involve a nice spike in user adoption. But sustaining that momentum requires ongoing socialization, training and the ability for users to make changes quickly. The continuity is more important than the actual launch, and it's a place where most businesses fail.
How much time should businesses spend perfecting the visual appeal of dashboards compared to other components?
Yuk: Having a sexy dashboard is important to the initial success of a dashboard, but the overall user experience is key. Today, a lot of organizations spend a lot of time on the aesthetic and visual portions and not enough time on what goes into it.
We divide requirements gathering into three distinct parts. There's design requirements, functional requirements and data requirements. The reason this is important is, when working with users, once you begin to build the dashboard looking at the design, functionality and data at the same time, [it] causes a dopamine overload. Users cannot deal with all three at the same time.
First, we work to have them confirm the design requirements. We then add functionality and have them confirm that, and then, last but not least, we add real data. We decouple the three areas, then attack them in that order. We found that approach can cut down scoping and requirement gathering [times] by up to 40%. What it does is it allows us the time to focus on what's going into a visualization versus what it looks like. If you separate the requirements into those three areas, it will cut down on the time spent, and you'll get the amount of attention you need on each area.
Just remember, the reason people spend a lot of time on the visual piece is because they're doing it in the wrong order or they're doing all three together. You sit down to talk about the color of a chart and someone says the numbers are wrong, then you talk about the numbers and someone says the chart is wrong, then you sit down to talk about both and they tell you that the drop-down menu doesn't function properly. After sitting through this process hundreds of times, I decoupled the whole thing and we saw overnight results.
Businesses have access to many data sources today, thanks to big data, that they didn't have in the early days of BI. How much of that should go into a data dashboard?
Yuk: This goes back to our discussion around what goes into a dashboard. The recommended amount of KPIs you should have is three to five. Typically, if you're able to focus on three to five KPIs, that usually limits your data sources. Figuring out what is important tends to fix a lot of things. First, focus on those three to five measurements that are going to give you results and, a lot of times, it's not going to require 19 different data sources to get those answers.
If you're building your KPIs based on your available data, you're opening the door to every data source available. But if you're building your KPIs based on the company's mission statement and actual goals, and making them actionable, they become so specific that, most of the time, a lot of data sources aren't required.
You've talked about bringing machine learning into BI and automating data discovery. What kind of role do you see for machine learning in data dashboard software?
Yuk: You have your KPIs, your trends and then the action. The theory that I have is that you can utilize human intelligence to attain the KPIs and then use machine learning to tell you how you got to where you are or why a KPI is above or below its target. You can also use machine learning to tell you what you need to adjust or change to achieve your KPI goals. Machine learning algorithms should be able to access your data sources to change your existing measurements and help you reprioritize or adjust them in real time to make sure they're relevant and keeping up with the business.
I truly believe that one of the biggest wastes of time companies have is, they go into meetings and use maybe 0.1% of the knowledge intelligence of their organizations, create a whole KPI data story, they go away, then they come back later and do it all over again. I think that machine learning can keep KPIs relevant so they're alive with the business and not something that dies.
BI seems to have been somewhat slow to embrace machine learning in this way. Why do you think that is?
Yuk: I think it's bad habits. People are doing what they know. What we know to do today is get in a room together with the senior guys and one of the worker bees and gather requirements together. I think business people just don't know better or any different.
People's jobs are dependent on this, so trusting a machine is another problem. When you have a machine telling you why something happened, today, there is a lack of trust.
How to develop data dashboards for effective BI
Data dashboards help BI users bring focus back to ROI
Clutter and overlap are prime reasons why dashboards fail