Dashboards are incredibly useful and yet a huge pain to maintain. They’re packed with valuable information, and yet they often fade from people’s attention when they don’t answer their questions. They’re critical for business operations, and yet end up unused by their intended audience once the novelty wears off.
The common term for these contradictions and seeming paradoxes is dashboard rot. What it means is that dashboards aren’t one-and-done, but have to be kept up to date and monitored, or they will lose their usefulness and fall out of use. The term is inspired by bit rot in software (which needs to be kept updated or it will stop working properly) and link rot (web pages disappear or change, so links to them end up going nowhere).
Dashboards are built with the best intentions to answer a question, inform important decisions, and keep stakeholders informed. But after the initial excitement, they often end up being ignored.
And yet, you can prevent dashboard rot if you know the reasons why it happens in the first place:
Dashboards are often built by default, even if a different display of data would be more effective. The wrong dashboard was built based on assumptions and unclear specifications.
The dashboard is static and doesn't allow interaction.
The data in the dashboard isn’t fresh.
The dashboard breaks and isn’t maintained along with its data sources.
The dashboard isn’t meeting a need, so stakeholders stop using it – and you’re not even aware of it.
We’ll cover all these reasons in detail below, and provide some strategies for how to avoid them.
“What do you mean, why’s it got to be built?” he said. “It’s a bypass. You’ve got to build bypasses.”
– Douglas Adams, The Hitchhiker's Guide to the Galaxy
When there is a question about business data, a dashboard often seems like the obvious thing to build in response to that question. But it’s worth taking a step back and asking if a dashboard is the best solution. Hastily built dashboards that answer a single question often end up rotting away in obscurity once they’ve done their job.
Perhaps the question can be answered differently, with a simple database query, a script, or maybe an Observable notebook? A quick answer to a simple question can be perfectly sufficient and avoids spending more time than necessary.
When the data in question is likely to be of interest to more people, and on an ongoing basis, a dashboard is a good choice. Now the question shifts to knowing what to build. This might seem obvious, but the excitement about building something new can cloud our ideas of what we really need.
Make sure to ask the right questions:
Where is the request coming from, and who will the users be? The sponsor of a dashboard and its users can be the same, but they often are different people or departments, with different questions and needs.
What tasks are stakeholders hoping to accomplish with this new dashboard? What information are they looking for? Do you know what data sources provide the right data for the dashboard?
Are all the stakeholders involved in coming up with requirements and getting their voices heard? Are you making assumptions about their needs?
What existing tools and dashboards do stakeholders have, and why are those not sufficient?
Does the information your audience want shown in the dashboard match the tasks?
Building a dashboard or data app without knowing all the requirements, or making the wrong assumptions about user needs, is perhaps the most common cause of dashboard rot. The time spent upfront to make sure you know your users’ needs pays off later with a better user experience and less toil modifying your new dashboard.
Static dashboards can be useful, but nothing beats allowing users to modify what is shown. In addition to engaging users, interactive dashboards are less likely to succumb to dashboard rot because users can more easily access the information they need.
Filters allow users to modify the dashboard content by drilling down into a specific subset of the data. Mouse-overs provide additional information on charts and selections can highlight corresponding elements across the dashboard. Sometimes users need to access additional context. For this use case, links can point them to more information elsewhere, whether it's another dashboard or a different destination.
Observable provides a library of inputs to use in Observable Framework projects, including drop-down boxes and radio buttons for categorical data selections, rangle sliders to change continuous values, buttons, and more.
Dashboards are all about current data, but what is current depends on the use case. So it’s important to ask: what does your specific use case actually require? Is it the data as of close of business the day before? The end of the previous month or quarter? Knowing, and making a conscious decision, about what constitutes current data for your dashboard helps you avoid incomplete time periods that can cause confusion.
Incomplete data is surprisingly common on dashboards, and can lead people to draw wrong conclusions even when they’re aware of the problem. For example, if a line for sales is pointing down, it may be because sales are actually down, or it might be because you’re looking at an incomplete month’s worth of data. A clear and intentional strategy for updating the data avoids this problem by always showing data for complete time periods that can properly inform decisions.
Scheduled builds are a great way to ensure your data is current as of a particular date and time. Observable Framework supports automated deploys to set up continuous deployment (or CD). Traditional BI tools can achieve the same thing with date filters that remove incomplete time periods, though they still need to load all the data when the dashboard loads.
Not only the data needs to be kept up to date, the dashboard itself might, too! Check back with your users to see if they’re still getting value out of it, or if their needs have changed (and track their usage!). When people start using something, they often realize that they actually needed something different after all.
Dashboards require access to data sources, which might change or disappear. Dashboards can break as a result, so it’s important to keep an eye on them and be ready to respond when that happens. Even better, have a plan for any changes to databases to be run by the BI team so they know ahead of time when a change is coming, and can evaluate the impact it will have on them.
A separate build process, like the one in Observable Framework, helps with this since it catches errors in one central place. The deployed dashboard still works, but the build process can send error messages to the maintainer, who can fix problems. The user might never even know that there was a problem, while in a traditional BI dashboard, they will see database errors without knowing what to do about them.
One way to know if a dashboard you have put so much work into actually delivers value to your users is to track dashboard usage. It’s nice to get validation that people actually find what you’ve built useful. But more importantly, you want to make sure if it gets used at all, and used as much as you’d expect, over the long term. Dashboards often get a spike in traffic when they’ve just been released, but then the traffic drops off.
Build it and they will come – except, that doesn’t usually work. You have to tell people that you made something for them, and keep reminding them. Perhaps your immediate customers are aware of it, but are there other stakeholders or interested parties who might benefit from your dashboard (who also have access to the data, of course)?
Observable’s project analytics show you important information about how your dashboards and data apps are being seen, and who your most enthusiastic (or at least, most frequent) users are. A dashboard that doesn’t get used is no better than not having the dashboard at all – or perhaps even worse, since you spent all this time building it!
Dashboard rot is real, but it can be avoided with some simple strategies. Dashboards sometimes get a bad rep because of the issues discussed above: it didn’t need to be a dashboard, it was built without enough information about the what and why, etc.
But none of these problems are insurmountable. With some forethought and the right tools (such as project analytics), the work you do building a dashboard or data app will provide lasting value to your users.