A dashboard is the default; or is it? Despite the wide and nuanced range of ways available to communicate data, more often than not we hear from teams who want “a dashboard” to meet their particular requirements. Dashboard is certainly a buzzword, and we believe that this causes people to choose dashboards over their humbler cousin, the automated static report. However, choosing the wrong medium to share your data can negatively impact your audience’s engagement with the insights you have worked so hard to develop.
For some, there are also psychological and organisational benefits to selecting a dashboard rather than a static PDF. The dashboard carries more clout, attracts more attention, and on a practical level, is both fully automated and usually owned by the business function rather than IT. For anyone who has filled out a 30-page requirements document and waited 12 months to see the outcome, or for analysts who spend hours adjusting Powerpoint packs, these are significant considerations. However, we believe these same goals can be achieved without always jumping to a dashboard.
Maybe you are currently working on a project which will require you to share data. How do you make the decision of whether to select a dashboard, or something else? The main question to consider is whether the data needs to be interactive. Read on to explore a range of real-life use cases where we have selected static reporting over an interactive dashboard, and our motivations in each case.
Whether you refer to them as users, customers, or something else, your audience is the group of people who will typically consume the data insights you are sharing. The specific needs of this group of people should be the main deciding factor in how you choose to present your data. If your audience contains multiple groups with vastly differing needs, this could be an important sign that they should be treated as separate audiences, and given tailored insights that work best for them.
Our executives and managers are one of the most commonly mis-served groups in data visualisation. Their stacked calendars and overflowing inboxes leave this group with a very short attention span: if we don’t give them a fast return on their time investment they won’t read what we have created.
Many of the insights on how to reach this group effectively are pretty well known, and we see these incorporated into dashboard designs: big headline numbers, lots of relevant info on a page, and clear insights without a need to spend time digesting the data. However, in our experience there are some other considerations which may make a static report more suitable than a dashboard for this group:
Reducing friction: Heading to a browser to access a dashboard on an unfamiliar platform requires some amount of learning the new platform, and a lot of extra clicks every time they want to access it compared to opening a report from their inbox. Technical improvements, like single sign-on and email reminders with links, can help here. However, there will always be more friction with a dashboard compared to a static report.
Offline viewing: For many busy people, saving reports to view offline while travelling or in other free moments is an essential way to keep on top of their responsibilities. They print out physical copies, or at least download an offline version to view on their laptop or tablet. Unfortunately, many dashboards require an internet connection, and are not print-friendly, or their printing capabilities are hidden away in a menu. A poorly-scaled print out from their browser is not how we want our audience to experience our insights.
Personalisation: For a senior audience, the ability to access personalised reports is part expectation, part practical consideration. When page real estate is so important, it makes sense that we personalise it to match their specific needs. Creating personalised views in a static report output is often much more practical than creating and maintaining personalised versions of live dashboards.
Sometimes we create data for an audience who are not so confident with data, or perhaps a group who don’t understand the context of this particular data very well. In this case, we want to present them with a view that will help them feel comfortable with the data, and avoid showing potentially confusing or misleading stats through incorrect use of the interactivity.
Keep it simple: A group who are less familiar with data may not feel so comfortable with interactivity. In this case, our beautifully designed dashboard may actually be more off-putting than engaging.
Control the view: Giving access to filters and interactive options means trusting our audience to use them responsibly. For example, they may need to keep an eye on the sample size of the view they have filtered to in case it gets too small. With less data-savvy users, we should avoid requiring them to make these judgements.
Don’t need the detail: For non-analytical audiences, giving access to detailed data is often unnecessary, and can undermine trust in the headline numbers. Particularly where more complex calculations are in play, the raw data can sometimes cause confusion, or intimidate users into feeling that the dashboard is too detailed for their needs.
Usually when we think of a static report, we imagine a PDF of neatly-organised charts and tables. Another potential audience for a static report wants the complete opposite: access to detailed data in a format that allows them to run their own analysis. Our definition of static reporting is not limited to PDFs or slides: we also consider a spreadsheet of detailed data to be an important form of static report.
Avoid the ‘Black Box’: For the analytically-minded, a dashboard can be a source of frustration. Where did this unexpected number come from? How were these metrics calculated? A dashboard cannot be examined and tested or, ultimately, trusted.
Ad hoc analysis: This group often wants to ask different questions of the data, rather than sticking to pre-designed metrics chosen by the dashboard designer. Even if a dashboard allows exports, it can be difficult to get complete, detailed data. A purpose-built clean dataset for analytics is often much more useful.
One size does not fit all: We are strong believers in creating different outputs to suit different audiences. What works for executives is the opposite of what is needed by analysts.
Sometimes we create data outputs to be shared with outsiders. Whether it is a client, a regulator, or a commercial partner, a common challenge is that when data leaves the building, we lose some control over how it is interpreted. Here, interactivity can become a risk rather than an advantage. Here we see many of our clients opting to create bespoke static reports, rather than offering access to a dashboard.
Closely control their view of the data: Filters and self-service dashboard features create two risks: that the user will misinterpret the view they have created for themselves; and that data can be filtered to a tiny sample size, revealing information which ought to have been masked by aggregation.
Simplify security and distribution: While many dashboard providers offer excellent security controls, there can be challenges when trying to align these with organisational policies and standards. For many of our clients, sharing a PDF report is simply a more comfortable option than giving access to a live dashboard.
Seamless experience: Logging in to yet another portal can feel like more of a frustration than a privilege. Many secure dashboards require a login, often via an unbranded portal. For many of these clients, a PDF report delivered directly to their inbox would offer a much more seamless experience.
The constraints of developing and managing dashboard technology can also be a major driving force behind selecting static reporting over interactive options. Creating and sharing static reports can often be faster and easier, especially when we are sending it out to a large audience. There are also some positive technical reasons why static reports can drive engagement more easily than dashboards. We have listed a few of our top technical arguments in favour of static reporting approaches:
Logistics of access and sharing:
No licensing costs for end users
No time spent on administering users and access
Static reports can make use of existing platforms
Sharing data in widely-used file formats
Faster and easier development:
No need to design interactive elements
Reduced testing time due to simpler views
Faster path from design to deployment
Less friction means more engagement:
Scheduled email alerts contain the whole report - no need to click through
Easier to view offline and on their commute
Personalise alerts to share insights that are relevant to the situation
The old-fashioned IT-led reporting approach has a bad reputation, and with good reason. Lengthy requirements documents, slow development times and less-than-transparent numbers are just a few of the problems. However, today we use a range of user-friendly tools which can be managed directly by business teams to build and distribute reports.
Placing the ownership of the report development in the hands of the team that will use it completely changes the face of static reporting. Teams can work in agile ways, gathering feedback and refining their designs, and making adjustments with ease. This creates huge improvements in the quality of the outputs being produced, and massively reduces development and deployment times.
Many of the BI technologies which we see used in this space are extremely user-friendly, and can be picked up by the team directly. Some are the very same technologies which are commonly used for dashboard development: Tableau, Power BI and Qlik, to name a few. These offer a much more flexible, self-service approach by design, standing in deliberate contrast to the closely-guarded likes of Oracle and SAP reporting solutions.
The case studies on this page illustrate some real, current examples of the technologies which Keyrus clients are using to create static reporting outputs. You will see a wide variety of software and approaches in use, of which only a handful are specifically designed to produce static reports: if your team is already working with BI technology, there is a good chance it can be used to produce these outputs.
Today, it is very fashionable to declare that dashboards are over; just a few years ago we were hearing the same story about static reporting. We believe the reality is more nuanced: static reports, dashboards, and the myriad of new tools in the BI space should all be regarded as different tools in our arsenal. The best results come from selecting the correct tool for the job.
Above, we have described a number of situations where a static report may be more effective than an interactive dashboard. This leaves the question of when is a dashboard appropriate?
To quote dashboard legend Stephen Few, "Data becomes useful knowledge of something that matters when it builds a bridge between a question and an answer.” The best dashboards are those which answer specific operational questions, and avoid trying to spread their function too broadly. However, as discussed, the medium of data communication must also fit the audience’s appetite for investigation: dashboards work best with an in-between audience who can interpret data, but don’t want to perform their own analysis.
This boils down broadly to two situations where dashboards are at their most effective:
Constant Monitoring: Dashboards work extremely well in fast-changing operational environments, where they can be used to access clean data on-demand, and provide KPIs and alerts to drive immediate action.
Management Insights: Whether leading teams or processes, managers often need to absorb information from many different streams and use this to inform decisions. For managers where the same data sources are constantly used, a dashboard can be an excellent tool to streamline the process of checking their data, and in providing effective comparisons between data from different sources.
Ultimately, the dashboard very much still has an important place in our data infrastructure. However, we should always take the time to select the best method to communicate insights with our audience.
Innovations in self-service data technology and machine learning are transforming the world of data insights. In part two of this series, we will discuss the innovative new tools and approaches which are enabling us to offer flexible and personalised insights to every user.
Stay updated on the latest articles, events, and more
Leveraging customer data to understand their behaviour, preferences and motivations can lead to significant return on marketing investments. However, with large numbers of customers, traditional business intelligence practice is to reduce customer data down to aggregated metrics, typically focussed on pre-defined segments (or cohorts) of the customer base. Whilst useful, this process discards some insight that can be revealed only by looking at individual customer-level records. In this blog, we discover a way to use Qlik Sense's On-Demand App Generation to study user-defined cohorts.
Creating and deploying enterprise dashboards has never been easier. With Qlik Sense, a business user of a dashboard can even create their own content, simply drag and drop a chart and select from prepared master items. This is one of many features that make Qlik Sense a great platform for organisations promoting data literacy and self-serve analytics. However, sometimes the resulting one-size-fits-all look and feel of Qlik Sense dashboards can leave us feeling a bit limited in terms of design.
When creating reports for clients they can be financial penalties if they don’t meet the agreed standards, particular in the financial sector.