We all know that data accuracy and modelling are key components for an impactful reporting solution but how said data is being presented is oftentimes the difference maker between your work becoming incorporated into daily processes and being left forgotten under a user's bookmark list.
Here are some tips and best practices on how you can ensure the data you are presenting is easy to navigate and serves the end user's needs.
Communication
The first step of creating a dashboard is understanding its future audience and the context, in which it would be used. For example, the level of granularity and drill-down would differ between a view intended for data analysts and one for business executives. Also, if the dashboard is sent out as an export or included as part of a presentation it wouldn't require as many interactive features as a web browsed one. Alternatively, are there any existing processes that the client does for their reporting and are looking to optimize?
All of the above can help us identify what KPIs and breakdowns the client would expect to see or find useful. In addition, understanding what the reporting aims to resolve as a business problem would help in knowing what type of analytics must be present (descriptive, diagnostic, predictive or prescriptive) and the frequency at which data should be updated (live, daily, weekly, etc.).
Style
For the visuals to be coherent, there should be an overarching theme tying all titles, images and widgets. This comes down to selecting a limited color palette (no more than five including black and white) and a font. If you are to add a new page or report to an existing collection, review available templates and previous work as a guide. If you have the freedom to innovate, I strongly recommend spending some time doing brand research (browsing through their website and available resources). The work done here will pay in dividends when the look and feel of your final product is in tune with the company's vision.
Structure
Firstly, you should set your specific page size height and width and relevant margins. The decision here lies in if this will be mainly sent out as an export or if it will be accessed by web or mobile users. If you expect cross-device traffic, make sure that the delivered product shows the same way across or consider making two versions per each user group. Avoid having a large page with tons of widgets to scroll to as this tends to lose the viewers' attention) and instead separate your visuals in different pages per sections or segments. This can also result in better performing dashboards depending on the visualization tool in use.
It is imperative to keep a hierarchical structure between all the texts displayed on the page. This will help direct user attention to the correct areas and ease usability. An example order would look the following way:
title -> section header -> KPIs -> KPI headers ->
filter values -> filter labels -> graph headers -> graph labels -> comments, etc.
Here you can play with both the font size and toggling bold/italic depending on the elements at play and you can enhance these by strategically adding colors (e.g. if your dashboard is predominantly white, if you add red color boxes behind the KPI headers the eye would naturally drift to them). Make sure you don't overdo it as if the dashboard is too colorful it will have an inverse effect.
Hierarchies and the data layout are the key elements in achieving a successful dashboard storytelling effect. You should aim to keep KPI totals and main granularities to the top left and gradually flow to more specific views/gauges/segmentations/predictions as you scroll down. It is important to also provide context on the output by outlying % period changes, target goal/budget, comments on the logic of complex calculations and predictions and a separate documentation or information page on the dashboard itself. Not all users will be well versed in the data so the above can be a maker in how much value your work ends up bringing.
When it comes to widget selection, stick to simpler visuals. Line charts are great at showing data through time, while bars provide better categorical comparison. Bubble charts, word clouds and sankey charts might look cool, but unless they exactly fit your data reporting case, I would recommend avoiding them. Pie charts can be effective in directly conveying segment size but lack accuracy, especially if there are extreme disproportions. In such cases we should also be careful of the axis min and max sizes we use to make sure the data comes through visibly. Custom widgets can be a great addition if you have the resources to add a wow element to your pages but do not rely on them too much - as with anything, sound fundamentals are more important.
Polish
Once you've drafted a version of your dashboard you should apply the less is more mentality. Negative space can be just as important as charts themselves if you use it correctly. Remove any repetitive data charts and any unnecessary word duplications (e.g. if you have a chart title of what the segment and metrics are you don't need to repeat it again in the chart itself). Also, wherever the X and Y axis are inferred from the already provided data (labels or titles) you should remove that as well.
Make sure there are interactive elements to your charts like filter selections, switch measurement/dimension, drill-downs, click-to-filter, etc. These scale the usability of existing charts and as an added bonus keep users more engaged with the content.
Round up your measurements by leveraging decimal points and thousands aggregator symbols (K,M) unless the data specifically requires exact number reporting. In most cases the summarized version is enough and you can configure hovering to provide the exact numbers if necessary.
Lastly, consider your dashboard audience for specific regional and cultural details. What is the timezone the data is displayed in, what is the currency symbols used, should the text frow left-to-right or right-to-left, etc. are all questions that can ensure you are matching the users' expectations when browsing the data and no confusion out of assumptions is created.
Delivery
On a final note, I would highlight getting feedback from the end users whenever possible. It is better to deliver an unfinished version and have the client comment on what he works and what can be improved instead of keeping them in the dark until the final version gets published. Additionally, if you have the opportunity, create two versions to gauge via A/B testing what feel and layout works better for the specific audience and this would tremendously increase the satisfaction your users will have with the final result. Hope all of this was helpful!
