10 Steps For Efficient Dashboard Build
Dashboard building is both art and science. Historically the process tends to be lengthy and the product static with less than optimal use. However, this does not need to be the case if we both follow an agile methodology and think outside of the box. If we simplify the process, we can reduce the development time of dashboards from weeks/months to as little as days. Below are ten steps to follow to streamline requirement gathering and deployment of business intelligence dashboards.
1. Find the core business question.
Just like paragraphs should have one main idea, so should dashboards have one main business question. These questions tend to be open-ended and have multiple parts like what is my throughput, what are my sales, retention, EBITDA, etc.
2. Define the standardized measures that answer the question and the standardized dimensions that add context to the question.
These are the quantitative pieces of information that answer the core business question. Throughput could be the time between different endpoints. Sales could be conversion of new leads. The important part of these measures is that their definitions are kept consistent across the organization. The same goes for the dimensions, or how to break out and slice and dice the information. These include portfolios, territories, departments, etc. If a portfolio means one thing for one group but something else in another group you need to standardize the definition in order to use it without contributing to a data silo problem. It is important though not to overload the dashboard with too many measures. Try to limit to 5-7 or you risk taking the focus out of the dashboard.
3. Confirm data sourcing and revise initial measures and dimensions as needed.
When you have the business question and the pieces that go into answering it, you need to identify the sources of the data that feeds them. If the same data points are being recorded in different places, identify that and bring to the business’s attention as this can also help resolve redundancy for the users. Push for use of system fields and areas that are not using free-text when you can as this helps reduce possible ETL errors as well as minimize the noise users will see when filtering or viewing.
4. Establish a pipeline to bring data into framework.
Once you have the sources identified, you need to establish a template or pipeline to get the data into your reporting/analytic system. Use the ETL tools you are most comfortable using or are authorized to use (Python, Airflow, SSIS, etc) and get the data in. The more normalized and optimized you make the final object tables post-transformation, the faster the data will load into your tool. Try not to overengineer or hardcode the reporting layer as this will make it harder to maintain and expand as what you analyze expands. I tend to make broader views and establish filters on the report layer so that what I do for one area translates to others without having dozens of views that do the same thing just a little differently.
5. Build a summary page with values of key measures.
Keep in mind that you do not build your dashboard for just one person. Different people and groups will need to look at the data at different depths. For those more in the peripheral, it is helpful for the users to be able to see how the organization is answering the business question at a glance. A summary page is useful because it creates this one-page glance that even busy executives can use to quickly gauge if the organization doing okay in the question or not okay. A sample structure would be a table with the 5-7 main measures in it. You would have the current period values, expected period values and the difference between the two period values. This difference can be color coded red and green to make good and bad changes pop.
6. Build overview sheets.
Number values are useful but there is something behind the adage that a picture is worth a thousand words. To keep things as broad as possible but still be functional, I tend to go about overviews in one of two ways. The first is to have an overview sheet for each of the main measures. The second is to have one overview sheet but a toggle for the measure. I do the former if I have an API in place that would allow the user to get to the overview sheet in a search format without having to navigate through the dashboard to get to it. The latter I do if that is not the case so that the user can minimize clicks to get to the information. The goal for either is less clicks.
A key thing to remember for overview sheets is to resist the urge (or pressure) to show data over time in bar charts. There are a lot of design and data visualization reasons behind this but when showing data over time it is best practice to use a line graph (just a line and not the fill below the line). This may seem strange to business users if they have always used bar charts for this but in the end it makes things clearer and follows best practices. Simpler is better especially when looking at data overtime or else the noise may drown out the message your are trying to convey.
7. Build breakdown sheets.
Users need to be able to slice and dice the data and the breakdown sheet(s) is what empowers them to do so. Bar charts work best for this purpose as they allow the eye to easily compare values. Pie charts and stacked bar charts make this difficult so it is recommended that you avoid both as much as possible. Also if you have bar charts next to each other, make sure you keep the axes synced with one another to avoid possible representation bias. Start all charts and graphs at 0 on the y axis unless you have a serious exception as to why you do not (some do exist but these are rare). I tend to create toggles to allow the user to change what the key measures are breaking out on but there are a bunch of ways you can do this. The key is to keep it broad so you can add more measures and dimensions easily if needed.
8. Demo to stakeholders the initial draft and revise as needed.
If you followed the first 7 steps, the demo should not be something to be afraid of. More likely than not, what you present will be unlike what your business users have seen before but that is the point. Remember that you built this dashboard out of a need, not an ask and stand by your work. Show the users how it works and answers the business question. Show how it filters and toggles, downloads, etc but be ready for critique. You should welcome this because that means they are more interested in it than if you only receive silence. If they point out minor tweaks, make note of them and audibly repeat them so the users know you are taking it to heart. Discuss openly any that would make the dashboard less maintenance-friendly or require additional sourcing. This should be rare if you did the first 7 steps properly but it can happen. Work on finding the solution by finding out what it sounds like the users are trying to derive from the dashboard critique and finding a solution. They will appreciate your candor and willingness to work with them. In the end the product will be as much of theirs as it is yours.
9. Write instructions of how to access and navigate the dashboard.
This step is essential for user adoption because they will not use your dashboard if they cannot “use” your dashboard. Having a handy guide in front of them will help ease some frustrations they may have with the new tool. You still may receive assistance requests but this should minimize that. When you address a request for assistance, make sure you reference the instructions while you assist the users so that they know where to go when/if their issue happens again.
10. Deploy to production, iterate, and prepare for the next dashboard.
Once the dashboard is live, you may be done with the initial build but you are not done with the dashboard as a whole. In truth, you are never done. You will need to keep adding more to the dashboard as the need arises and to create more dashboards as there are numerous business questions to be answered.