Dashboard Designing with No Data
By Julie Thomson
Imagine the situation.
You are a data visualization specialist responsible for designing business dashboards for stakeholders. You are about to embark on an exciting new project which requires a new suite of dashboards.
The Business Meeting.
The design meeting happens, the white boarding session is complete, and as the developer you are on the way to build the dashboard that is going to be ground breaking for the business. You are unstoppable, excited and ready to hike up the analytic maturity model with your client.
Then you get to your desk.
The Problem.
“The” dashboard that you are going to turn into reality requires data collected no one thought to capture for the last decade, excel workbooks that are higher in count than the rows that are needed for the dashboard and trending data that just simply doesn’t exist.
You have 3% of the data points you need to work with.
Ugh, a little help here?
The variance between the ideation session and the actual execution can seem beyond the effort of creating this ‘unstoppable dashboard’. However, this is a great opportunity as a developer to flex that consultative muscle.
Ready. Set. Go.
1. Mind Shift from ‘Di Vinci in a day’ to ‘work in progress’.
Frustration and self-criticism can be overwhelming when a dashboard in any tool looks nothing close to what is on a whiteboard or in a designer’s head. Regardless of what tool you use, the “perfect tool” cannot solve for missing data. However, a developer’s creativity can help supplement.
2. Design with what you have.
Instead of answering every business question, answer the most important one(s) with the data that you do have. This allows you to also use the beginnings of a tangible draft to sound check that the key business questions are getting asked rather than showing nothing. Data collected or yet to be collected will depend on these questions.
As an example, if the client has asked for the last 12 months of trending data across every program and IT do not have this data, try and present the KPI’s across programs for the last reporting cycle as an alternative until historical data can be consistently collected (see example 1 below).
3. Show what you don’t have.
Depending on the analysis, showing the lack of data available can be a powerful message to an end user. As an example, if a business is trying to drive overall program participation, showing a list of participants with a green or red participation status can visually highlight to an end user who is participating in each program. Visuals like this can drive targeted conversations for those not participating rather than showing an end user a single percentage point on a page (caveat: when appropriate) (see example 2 below).
4. Add context where you can.
In the participation example above, there can be cases where showing a single data point can be powerful, but in context. If the business wants to signal to an end user that program participation is low at 10%, help add supplementary information such as ‘compared to business expectations of 50%’. In the example shown below, finance has achieved 9% over their KPI target of 90% which signals to an end user the positive performance and by how much they are exceeding their target.
5. Extra Bonus: Start collecting the data.
To state the obvious, starting to collect the data in a usable format is fundamental to the business.
I follow the rule that 80% of the business questions can be answered with 20% of the data if the data is structured in a flexible way.
Raw figures can easily be added, subtracted, multiplied or divided as needed but hard coded aggregated figures limit the analysis that can take place as the business evolves (depending on the situation of course). It is much easier to modify a numerator than to try and recalculate a list of historical percentages without the raw data or having to backtrack calculations.
Other thoughts you would like to share? Comment below!
Thanks for reading.
