Build Better Software

The Good, the Bad, and the Silently Broken

Your dashboard is only as good as your data.

by Jay Hogan

In this Q&A, our dashboard expert, Jay Hogan, explains the importance of starting with good data when you're building a dashboard. 

What's the hardest part of building dashboards?

Getting clean, high-quality data is typically the hardest part. Your dashboard is only as good as your data, so it's likely you'll need to do some data cleanup before building reliable reports. 

And what kind of process is that?

It can be laborious, but it's necessary and helps you think about better data. An outcome could be changing processes or fixing upstream systems so that new or different fields of data are required to get at what you ultimately want. 

What kind of fixes can you make to improve your data? 

One way to make sure your data is good, is to require managers to certify it. Provide them a system that allows them to easily verify the info, and update if needed. "Nag reminders" keep everyone on track to update so that over time the data gets cleaner and more accurate. It's a technique you can use to eliminate confusion and empower your frontline managers, or whoever owns the data, to actually impact change. If the data is certified, then you know you have the best, most up-to-date information.

So certifying data is one way to get good data. Where does bad data come from? 

One type of bad data is "slowly changing" data. For example, let's say your company has been around for 30 years. When you first started collecting contacts you just collected first and last names. Then you decided you need birth¬≠ dates, but you don't have that information for your first 100 records. So your data quality isn't consistent because of slowly changing data. If you don't define a structure for the data with specific constraints, customers will type in whatever they want, and you'll get a bunch of bad data. Bad data in = bad data out. Great dashboards can't be built with bad data. Ideally, your data is complete and meets a clearly defined schema. With a consistent data structure, you'll have a better sense for how complete the dataset is. But even with these guardrails, sometimes you'll still need to massage the data. 

How do you handle data gaps?

You have to make a decision based on your use case. What is the purpose of your dashboard? How critical is that piece of information and will the dashboard be useful without it? And if the answer is, "No, it won't be useful," then define a strategy for filling in the gaps. That could involve digging into paper records or calling people or sending them emails to get what you need.There are all kinds of ways to fill those gaps.

What is "silently broken" data?

A common example of this is when a dashboard or system indicator shows everything is working properly but it's unclear how up-to-date the data is. For example, let's say your dashboard has a widget that uses a collector to talk to Salesforce and find new contacts that have been added to your database. The widget shows the connector is working, but there's no indicator to tell you whether the data was updated four days or four minutes ago.

How can I prevent "silently broken" data? 

In the example above, the simplest way is to literally timestamp the new contact data with the date and time it was pulled into the widget. So instead of saying, "Last updated December 11 at 9:00 am," say, "Last updated 35 minutes ago." As the time span gets bigger, the language you use gets broader. Avoid saying, "Updated 63 days ago." Instead say, "Updated 2 months ago."

And what if that information isn't being updated as often as it should be? 

That's a good point. We don't want users to make decisions based on a number that isn't accurate. For a lot of the data points, we know how often they should be refreshed. For example if you bill monthly, you'll have a new revenue number once a month. So if the revenue widget hasn't updated in more than a month, we know that data is probably stale. In these cases, use a visual cue — maybe a dogeared corner or a red flag — to warn the user. Dashboards help you make decisions, but you have to be confident in your data to do that. Building in fail-safes, like an out-of-date or stale indicator, is one way to create that kind of confidence.

Jay Hogan leads SingleStone's AppDev Team, which builds award-winning dashboards and other software.

Need help finding answers to your data questions?
Tell us about your challenge.

Learn more about our Software Development solutions.

Jay Hogan
Jay Hogan
Application Development Lead
Contact Jay