How to Build a Successful Dashboard
A checklist from someone who built a few unsuccessful ones
At this point in my life, I think I have worked on more than a hundred different dashboards. As I grew more senior and started managing a team, I became more wary of these tasks — questioning the actual need and expected value for each dashboard request. Building an effective dashboard actually takes time — and when the requirements are not properly defined, it can quickly turn into a multi month nightmare (which ends up being used by no one).
And people are usually quick to push for a new dashboard. Building a dashboard is doing something that is actually tangible — i.e. you are building a product that you can release in the ‘real world’ (contrary to a study, that is more abstract). But ultimately, if there is not a clear issue that the dashboard would solve, or if the cost of building it is more important than the value it would create — it might be a waste of time to take on the project.
And as your time is valuable, below is a checklist to follow to increase your dashboard project’s chances of success.
Step #1: Define the use cases and the audience
Before starting the actual work — you should be clear about a few things, and in particular: why you are building this dashboard and for who.
“Hard choices, easy life. Easy choices, hard life.” — Jerzy Gregorek
From my experience, it is important at this stage to put a stake in the ground and to be clear about what are and are not the use cases, and who exactly is the intended audience. If you make those “hard” choices at the beginning, it will make your life way easier — so make sure to properly answer the following questions:
- What’s the problem this dashboard is trying to solve? That would be the #1 question to answer. If your dashboard is not solving anything, people will not use it. By clearly defining the problem, you can get a better sense of what value the dashboard will be generating, and that can help you size what your personal investment in this project should be (see my article on ‘how to select which data project to work on’ for more info!)
- What won’t it be useful for? Being clear on what the dashboard will be useful for and what it won’t be useful for will allow you to make sure you’re not ‘brave new world’-ing the dashboard, i.e. overwhelming the interface with too much information and making it hard to use. It will also be very useful for the internal branding — if it is clear that your dashboard is only useful for doing X, your dashboard will be known internally as THE dashboard to do X.
- Who will be the audience of this dashboard? Tailor the experience to your audience. For example, if your audience isn’t familiar with the side of the business you are reporting on — you should add more context to the data. If they don’t know how to use filters — you should not add filters. If they’re mainly using their mobile device — make sure it’s mobile-friendly. Recruit a few beta testers that would be representative of your audience — they can give you feedback on any mockups and the final product.
- How will you know if your dashboard is a success? This one is a tough one, and is often overlooked. At the end of this project, you would want to have a simple criteria to decide if this is a success or not. It can be usage-based (e.g. “more than X people connect monthly to the dashboard”) or project-based (e.g. “most project Y decision are based on data provided by the dashboard“).
Step #2: Benchmark // Find inspiration
Now that you have a clear idea on what success looks like and what you should be building, it is time to get to know your audience better and their relationship with data. Where are they in their data journey? What data are they currently consuming? What is their data dreams? Understanding them is key to make your dashboard a success:
- Has our organization tried to solve this issue in the past? How can you build the future if you don’t know about the past? If a solution has already been tried in the past, learning what worked and what didn’t work can be extremely powerful.
- Which dashboards are popular with your audience? Your audience is already consuming data internally, and they might be used to seeing the data presented in a certain way. Are they used to seeing it split by specific dimensions? Would they prefer you to follow a particular naming convention? Studying these dashboards can give you a list of dos and don’ts for your project.
- How is your audience currently doing without this dashboard? Knowing how your audience is currently doing without the dashboard is helpful to understand what is the minimum value they need from the dashboard — in other word, what your dashboard should at minima be doing — and prioritize the feature accordingly
Step #3: Prototype & Build
The user experience of the dashboard plays an important role in the dashboard success, and too often, analysts overlook the importance of it. It is important to never forget that a dashboard is a tangible product that is meant to be used regularly — and the best way to make sure of that last point is to develop it with your potential users:
- Build mockups first. Building mockups (especially simple ones, on a spreadsheet) and running it by your potential users will allow you to make sure you are covering all of their use cases, and that the UX is ideal. Keep it simple & focused on the problem it’s trying to solve. Think ‘inverted pyramid principle’ for how you present the data. Use the right visualization for the right type of data.
- Run those mockups by your potential power users. Fill the mockup with some actual data and show it to your beta testers (that you identified in Step 1). Observe how they use the mockups (i.e. what are their user journeys) and if they are able to find the information they need by themselves. If they don’t or if their user journey is painful — iterate and try again.
- Build the dashboard! Now that everything has been validated, and that your beta testers are ecstatic, go ahead and build the dashboard. Make sure that the data loads fast enough, that you are consistent between the different sections, and the numbers are using the right format.
Step #4: Test, test, test
Making sure the dashboard works before releasing appears like a no-brainer. But what does ‘works’ mean? It means that ‘your audience is able to find the information they are looking for’ and that has multiple components:
- Are the numbers right / do they match different data sources? There is nothing more damaging that having a dashboard that reports ‘wrong’ numbers — your audience may instantly losing trust . Look into other dashboards and data sources that are reporting the same metrics, and validate that you are reporting the same thing.
- Are the main user journeys working as intended? During step 3 you identified a bunch of Critical User Journeys (CUJs). Try following those CUJs and see if you are able to complete the critical tasks — if you aren’t, you should fix that.
- Are the different beta testers happy with the end product? Ask your beta testers one last time for their help and let them run wild on the dashboard. Pay extra attention to their questions — those are usually signals that there is something missing or there is not enough context and that the dashboard may not be working as intended.
Step #5: Document everything
Remember on step 2 how happy you were when you found out someone already tried to solve this issue and documented their efforts? Now it is your time to give back!
- Where is the data coming from and how is it transformed? Make sure to start a product requirement document (PRD) to document where the data is coming from and which potential transformation you are applying (and why).
- What are all the steps you followed to actually build this dashboard? Add that to the PRD — it will be useful for the colleague who will takeover after you start working on another project.
- What are some other potential considerations? Use the questions from your beta testers (from step 4) to build a FAQ, and link it directly from the dashboard (potentially alongside the PRD).
Step #6: Release the masterpiece
You’re done! Now it’s time to go-to-market, to show the world your incredible work, and to receive congratulatory messages:
- Send a launch email to all the right stakeholders. Make sure you nail the launch email, you only get one chance to make a first impression.
- Consider organizing a training. If the dashboard is slightly complicated, or if it is meant for a small number of users, it might be interesting to organize a training to make sure they know how to use it and they can get the most value out of it. It can also be a good way to collect feedback and/or feature requests for future iterations.
- Make sure your dashboard is discoverable. If you have a centralized knowledge management system, make sure your dashboard is part of this system, and you’ve optimized as much as possible for it to be found.
Step #7: Verify your dashboard is successful
Remember the success criteria you defined during step 1 for this dashboard? Now it is time to use it and understand if you made it or not. Did you get the # of users you expected? Is your dashboard helping the right people to do the right thing? If it doesn’t — look into what went wrong, and either fix it or learn from it. If it does — celebrate, because life is too short.
And you’re done! Well… For now.
Because a dashboard is a tangible product that is meant to be used on a regular basis, and because a lot of things can go wrong once you release the dashboard (e.g. the intended audience can change over time, the general needs can also evolve, the upstream data sources can be updated, etc.) — you should make sure you have the right processes in place to maintain it and update it accordingly. Landing the launch is one thing, making sure it is a success on the long term is another one (and I’ll touch on this on another article so.. Stay tuned I guess?)
Hope you found this insightful and I didn’t bore you to death with this long article. Would you add anything to this checklist? Let me know in the comment section!
Thanks for reading!
If you had ‘fun’ see my other articles:
