Since the dawn of time man has been trying to tell stories with pictures. Cave drawings told stories about great hunts, travels to seasonal camps, the number of people living in an area, and so on. Mankind thought we had evolved past this until the 1980's, when Pictionary came about and we once again found ourselves attempting to depict entire stories through wild gestures, crude drawings and repeatedly pointing to the same thing over and over all while wondering why your audience wasn't getting it . . .
It's not your fault, you see, that your dashboards and scorecards fail to tell the story you want them to - it's in your DNA! Mankind has spent hundreds of years trying to tell stories through simple, quick pictures and failing. Today, however, we get to blame everything from extraordinarily expensive dashboard tools to failed requirements to poor business practices and unsympathetic IT resources.
Let's take a moment to understand where your dashboards may have gone awry and what you can do to get them back on track.
You were tool dependent. As an organization, you bought into the myth that you must have a leading edge tool. Furthermore, you listened to the salesman when he said that once you have it installed you won't need IT anymore.
Dashboards and dashboard specific tools are not tightly coupled. Dashboard interfaces can be created in just about any mainstream tool out there today. Additionally, IT resources are the key to unlocking the power of the tools you already have and helping you avoid some of the main issues listed below.
You have dirty data. Data quality is paramount when it comes to data visualization. You cannot build a beautiful structure on a faulty foundation.
Part of your engagement when beginning a dashboard project should involve a data profiling effort. IT resources can provide insight into the content of the data you want to display on a dashboard and assist in cleaning the data in the source system.
Your visualizations fail to tell a story. If your dashboards or scorecards don't contain data pertinent to the viewer, their purpose is void.
The process of developing a dashboard is an interactive one. They cannot be built without the input of the end user, or you risk providing a functional dashboard that no one cares about. Part of the development life-cycle should include joint design sessions where developers and end users create visualization mock ups.
You are trying to consume too much. A dashboard should be subject oriented and focused. Often times users request seeing everything on one page so that they can then discern what is important to them.
Well designed dashboards can be a highly beneficial tool. Poorly designed dashboards can distract and confuse users. For example, when you try to include too much data on one screen you lose inherent logical grouping found in the data and risk making false correlations. Creating multiple tabs that are subject oriented and purpose driven as well as limiting the number of objects on the screen will help minimize this risk.
You assume real time data is necessary. In the vast majority of corporate business dashboard situations, near real time data is acceptable. There are exceptions, such as call centers and inventory management.
Building dashboards against operational systems in order to get real time data is expensive. It requires additional development, advanced software and high performing hardware. Near real time (refreshed every 5-60 minutes) data will often meet business needs for strategic, executive, analytical and the majority of operational dashboards. Make sure to ask the question “why” and “when” as you gather requirements, making sure there is a valid business need when real time data is requested. Also make sure that both real time and near real time cost scenarios are presented so that your user community understands the costs.
Your requirements were vague. Often times requirements fail to relate the desire of the owner, speaking in vague terms rather than specifying the actual need.
Due to the nature of dashboards, not all requirements gathering methodologies are applicable. A dashboard is not a report, nor is it a website or software. Initially you will want to document the set of data to be focused on and provided a profile of that data back for cleansing. As that process is underway, users and developers should sit down in a series of joint design sessions and create mock ups so there is a clear understanding of what will be delivered and how it will function.
You get mired in the details. Dashboards should be high level information, not transaction level data.
The strength of dashboards lies in providing “at-a-glance” data in a highly visual manner. Too often visualizations are overwhelmed by including too much data - every data point in a collection rather than just the top 10, for example - which results in visually confusing data. Instead of attempting to include all the data in the first visualization, link the visualization to additional analytical reports or provide drill-down capabilities.
You over-visualize data. Just because you can represent any given piece of data in a myriad of ways doesn’t mean you should. Constantly moving gauges and charts might look impressive, but they only serve to stress out the user.
Your user base wants to see sales volumes by state - why start with a map of the world? You have KPI data, but choose to rate it with emoticons. You include 250 data points in a single chart. You refresh data in real time when users want to see yesterday’s performance You apply the latest visualization gadget because it looks cool. Users want their data in a quickly consumable manner, caring more about applicability than the wow factor when it comes to daily use.
You use the “one size fits all” approach. A dashboard designed for the CEO is not intended to be consumed by a team lead. A HR hiring dashboard may not contain the KPI information the sales team needs.
Analytics focused users may start at a high level but need the ability to drill down to the transaction. Operational users want a dashboard that helps them steer activity in real time or near real time. Executives want to see how the organization is performing against KPIs. While all three may be looking at the exact same data, how they view it will be significantly different.
You assume one layout will work for all. Even if you filter data by the individual user, the manner in which the data is arranged can be just as impactful as the data itself.
The data in a dashboard should be arranged logically, according to the characteristics of the data. For example, if you have a dashboard displaying financial data as well as inventory it would be best to group the financials together and create a visual break between it and the inventory data. If you group data together, the implied assumption is that one has a relationship to the other.
As more organizations seek to quickly understand and analyze their data, dashboards and other data visualizations are becoming more popular. The ability to display your data in a visual manner that clearly showcases your ares that need focus and those which are succeeding proves to be an invaluable tool. However, just as well designed dashboards can help you steer your business to success poorly designed ones can lead you in the wrong direction, costing you time and money.
At Quandary Tech Solutions we have decades of experience in building highly effective data visualizations across a wide range of platforms. While we work with many of the leading industry tools, we also have the knowledge and ability to build dashboards in the tools you already own or can help you choose one that fits your budget.
Call us today at 800-208-6388 or email us at email@example.com to speak with a visualization expert.