As a data analyst or BI developer, deploying a new data product or dashboard to production is always a satisfying moment. It’s also tempting to think that that’s the end of the story - time to progress the ticket to Done and move on to the next thing. A few weeks or months go by and you might wonder how your stakeholders are faring with that product you spent so much time on. You ask around or check the automated usage metrics, only to find that nobody has looked at it since the week of publication.
It’s a frustrating experience that’s familiar to many data practitioners, including those working for one of our clients, a global financial services organisation looking to innovate in new and different ways. Their BI developers had created a dashboard tracking the retail performance of a new product that is fundamental to the company’s long-term strategy, but they were struggling to get senior stakeholders to use it to drive decision-making. They turned to us for guidance on how to increase dashboard adoption, and in this post I will walk through the key advice that we offered.
When developing a new data product, there’s one question that should be central to the whole design process: How does this product make my stakeholders’ job easier and/or faster? For dashboards, we can break this question down into three key considerations for the end user:
If the answer to any of these questions is "No", user adoption is likely to suffer. By using these questions as a guide to assess our client’s dashboard, we identified five key pieces of advice for increasing adoption.
A dashboard designed for everyone is a dashboard designed for no one. When you try to cater to multiple user groups, you risk creating a bloated product filled with metrics and visuals that each apply only to a subset of users. With so much clutter, it can be hard for users to determine whether the dashboard answers their key questions: This is a Q1 and a Q2 issue.
Our client initially attempted to build a single dashboard for three distinct groups: the Retail Performance Management Team, the Finance Team, and the on-the-ground Sales Teams. We recommended narrowing their focus to the Retail Performance Management Team first, ensuring the dashboard met their specific needs before considering other groups.
To design a dashboard that truly serves its users, you must first understand the questions they need to answer. To do this, you will need to run requirements gathering sessions that explore not only the questions users have but also the value of those questions and their alignment with strategic goals. It’s equally important to identify any pain points in the current process of gathering these answers and to uncover questions that users can’t currently answer. All of this goes towards satisfying Q1.
Our client’s initial approach was to pack the dashboard with a variety of metrics, visuals and insights available from the underlying data, without first considering their utility. We stepped in to conduct sessions with key stakeholders from the Retail Performance Management Team. By walking through their critical questions, we aligned on what needed to be answered in the dashboard, then formalised this in a requirements document to ensure that everyone was on the same page.
A well-structured dashboard should follow a summary > detail > granular flow, reflecting how users typically process information. Consider how much time users have to engage with the dashboard:
By structuring a dashboard around a user’s thought process, we are satisfying Q2.
Our client’s Retail Performance Management Team was accustomed to manual reporting in Excel that typically took several hours a week to compile. By following the structure outlined above, we were able to introduce the summary visuals to highlight insights that tables alone couldn’t convey, whilst also preserving those tables to maintain a sense of familiarity for the end users. We also advised ingesting granular data into the dashboard to allow users to drill down as needed, improving flexibility and reducing frustration.
Confidence in the dashboard’s accuracy is crucial for user adoption. Developers and end users must thoroughly understand the data lineage from source systems to the dashboard, including any transformations and filters applied along the way. This knowledge is essential for reconciling data and building trust in the end product - a Q3 consideration.
We suggested adding an intro page to our client’s dashboard that explained the data lineage: data sources, definitions of key metrics, the dashboard’s scope, and any key data inclusions/exclusions. This transparency builds trust in the dashboard’s contents. Additionally, some of our client’s dashboard developers lacked access to the data warehouse, which made it difficult to address data discrepancies raised by stakeholders. We recommended granting read access to upstream tables for all developers, enabling them to gain familiarity with the transformation pipeline.
A good dashboard clearly highlights all the steps that went into its design - including data lineage, applied transformations, data refresh, and definitions of terms - so that end users are confident about what they see
A dashboard should never be developed in isolation from its end users. To increase buy-in and ensure the dashboard meets user needs, stakeholders should be heavily involved throughout the development process. Regular touchpoints allow stakeholders to see progress, provide feedback, and gain early access to the dashboard, as well as ensuring that any risks impacting on Q1, Q2 or Q3 are raised and addressed early.
Our client previously had a working group dedicated to performance reporting on their new product, but it had recently gone dormant. We recommended revitalising this group with regular sessions to demo new functionality, using a Teams channel to log and address feedback promptly. We also recommended formal UAT with key users towards the end of the development lifecycle, as well as regular post-deployment check-ins to ensure that users felt supported even once the bulk of the work had been completed.
An iterative approach to dashboard design that involves stakeholders at all stages boosts end user confidence and buy-in
By implementing these recommendations, our client is already well on their way to refocusing their dashboard to better serve the Retail Performance Management team. They are also adapting their dashboard development workflow to ensure the right questions are answered and stakeholders are engaged throughout the process. Ultimately, treating end users as a collaborator, rather than simply a customer in the dashboard development process will increase the chances that your hard work goes on to have a significant impact on your organisation’s decision-making.
At Mesh-AI, our data analytics team has deep expertise in creating impactful, actionable dashboards that align with your strategic goals and in helping you build up the people, skills and processes needed to be a data-driven organisation. Get in touch with us to learn how we can help you achieve better outcomes through focused actionable insights and a stronger analytics capability.
.png)
