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.
When building dashboards, a common problem that many teams face is dashboard rot — a situation where your dashboard becomes outdated, inaccurate, and ultimately ineffective for its users. 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).
A dashboard can quickly lose its value if it’s not regularly updated, maintained and monitored. 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.
In this post, we’ll explore five key strategies to help you fight dashboard rot and keep your dashboards relevant and useful.
“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, building a dashboard often seems like the obvious 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 actually delivers value to your end 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. By implementing these strategies when building your next dashboard, you can ensure that your dashboards remain relevant, accurate, and useful over time. Regular updates, user feedback, and performance improvements will help prevent dashboard rot, and ensure your dashboards continue to provide valuable insights over the long term.
Want to learn more about how Observable’s end-to-end data visualization platform can help you quickly build fast, interactive dashboards help your end users make more informed decisions? Start building with Observable today.
Dashboard rot occurs when a dashboard becomes outdated, inaccurate, or less effective over time due to lack of maintenance or updates. It can lead to users relying on incorrect or irrelevant data, reducing the dashboard's usefulness and value for decision-making.
By maintaining your dashboard’s data sources, ensuring data is up-to-date, elevating your dashboard’s user experience through interactivity, and monitoring dashboard usage, you can ensure your dashboard remains effective.
You should update your dashboard's data and visualizations regularly to ensure it remains accurate and relevant. The update frequency depends on your organization, but it's important to set up automated refreshes or scheduled updates to avoid outdated or incomplete data.