Category Archives for "Dashboard Design"

Dashboard Design Case Study – Product Sales Dashboard

A case study of the key steps to designing a product sales dashboard with real-world challenges

Check out the Kickstarter for the Dashboard Wireframe Kit!

Check out the Kickstarter for the Dashboard Wireframe Kit!

Get your PDF of the entire case study. Just enter your email to receive yours.

How to deal with strong opinions and inflexible thinking

The cast of characters

Who the dashboard was designed for

Dashboard Design Process

A business dashboard is a living thing that evolves with the needs to the users and the availability and quality of the data. If you agree with this then there is a process I utilize to ensure the dashboard never dies due to stagnation, irrelevance, inaccuracy or lack of value. The dashboard design process.
Why do this though, why not just get stuck in and build right away? Sure, that can work on occasion and you might get lucky. But in the enterprise, with multiple stakeholders, infrastructure and technology costs, employee costs and other factors, any ounce of risk can have significant impact down the road. Fixing user requirement issues during development is far more costly than during design. Not to mention regaining user trust. There is very good reason why the software industry adopted UI/UX years ago, applying these techniques to analytics is common sense.
  1. Know your users and stakeholders
  2. Understand your data
  3. Wireframe the end vision
  4. Build and apply best practices
  5. Drive adoption
  6. Rinse and repeat for the living dashboard

1 Know your users and stakeholders

For a dashboard to serve the needs of the business, leadership strategy and the end users, it may seem obvious, but we need to talk to anyone who has skin in the game. A good representation from each of the following groups is advisable:
  • Leadership and business owners of the dashboard
  • End users of the dashboard
  • Custodians of the data
  • Dashboard developers
There are many ways to skin this cat but getting answers to the following questions, tweaked by role, will help understand objectives, reduce risks and gain valuable information on potential roadblocks:
  • What is your role and what do you do day to day?
  • What are your objectives and goals?
  • How can this dashboard make your life easier?
  • How do you currently access this data?
  • What are your current challenges in doing so?
  • What KPIs do you currently use?
  • What KPIs would you like to see?

2 Understand your data

The deeper you can go on this the better but even knowledge of what tables and columns are available is important. Understanding data quality is recommended but can be tackled in later iterations of the process. What is vital, however, is having the ear of someone intimate with the data as a much of the details of the state of the data can be in that persons head.
Get the database schema, as well as the schemas of any other data sources. Run through what columns have sufficient data quality for a first iteration of the dashboard. Sufficient quality is obviously subjective but it should be enough to build user confidence in the numbers. What is not of sufficient quality needs a plan devised for when it can be improved and when it can be included in later iterations of the dashboard.

 

3 Wireframe the end vision

It’s workshop time and this kicks off the dashboard design. With some initial conversations and interviews under the belt a significant step is to get as many of the users and stakeholders into a room as possible with the aim of agreeing what is going to be solved while surfacing any obstacles and risks. The process revolves around personas for each of the user groups. This is were you leverage the work from step 1. It’s typical to have one to three primary personas. The key here is to surface what questions each persona wants answered and how/if the data is there to answer it.
The process is certainly a tricky one when mapping these questions to a series of charts where each chart should ideally satisfy several criteria:
  • What question is it answering
  • What is the resultant action (for an example see the post on the Burger)
  • Is the data sufficiently reliable for this phase
In the past I would draw out the dashboard and charts on the whiteboards but that was a long and risk-prone activity to do with a bunch of people in the room sitting idle. I now use a series of templates I developed to rapidly accelerate the whole process.
There are many design thinking frameworks that can be leveraged for running these sessions. I use my own customized version tailored to dashboard design but here are a few resources to have a look at:
The output of the workshop is a series of dashboard wireframes aligned to personas and a plan for next steps for finalizing the wireframes and moving on to creating high-fidelity concept designs that are more closely aligned to whatever technology the dashboards will be created in (QlikView, Tableau, Power BI, OBIEE, etc.). We are not boiling the ocean here, it is ok to have a basic dashboard for phase 1 so long has it has value and is reliable and the users understand it is part of a longer journey.

 

4 Build and apply best practices

With the high-fidelity designs signed off and approved the development can begin. There is plenty of variation, depending on the technology being used, but all of the modern tools allow a level of customization where data visualization best practices can be applied to some degree. Depending on how precise the high-fidelity wireframes were there may be a disconnect that has to be bridged to align the design with the technology. This is where spending extra time on step 3 with a dashboard developer of the technology of your choice is wise.

 

5 Drive adoption

I’ve been known to say that at this point we are 50% there because this is typically where a clear role has not been defined: who owns adoption? Who is responsible for making sure the users can find the dashboard, access it, understand it, use it and extract value from it? It is this vital stage that provides the detail to seed the next breath into the dashboard. It is the conduit for feedback and that enables a richer and more valuable subsequent iteration of the solution.
The important aspects of adoption can be surfaced in a platform that enables:
  • Discovery
  • Socialization
  • Gamification
 In practice the following features are desirable:
  • Dashboard hosting
  • Support for training materials
  • Search
  • Tagging
  • Discussion
  • Rating
  • Sharing
How this manifests can be the ubiquitous SharePoint but I prefer a platform born from the fires of analytics knowledge management: Cogo. However, the platform is just one part of the story. Handling change management, training and political/people ramifications are some of the hidden dangers ready to derail if not addressed.

 

6 Rinse and repeat for the living dashboard

As a rule a useful practice is to release a new version of the dashboard every three month for the first year of life. I’m not talking about the data refresh velocity here, that should always be fresh. It is the velocity at which we cycle through the above dashboard design steps again, i.e. get to step 5, get 3 months of user feedback and start with step 1 again applying all the learnings. After the first year I tend to default to a revisit every 6 months depending on workloads.
>