Next DPLC Live Webinar & Discussion @ 1pm ET on Feb 27, 2024
The Data Product Leadership Community is excited to host Karen Meppen of Hakkoda and DPLC founding member to discuss Immature Data, and Immature Clients: Are Data Products the Right Approach? We'll hear from Karen and then participate in an open dialog. Like all DPLC live sessions, it's fully recorded and transcribed too, and you can keep the chat going in our 24-7 Slack. For members only.
Apply to Join the DPLC Today

Here are (5) dashboard design suggestions you can start to apply today

If you're in the analytics space, then you almost certainly have at least one "dashboard" customers use.  I generally define dashboards as the landing page for your product when people log in, and so keep that in mind as you browse today's design suggestions:

  1. Your dashboard is probably too low on information density. 
    Dashboards with just a few large graphics/charts/KPIs are often a sign of low information density. Most of the time, a design looks misleadingly clean and simple because we're evaluating it on the surface. A huge donut chart with 3-5 values, and no calls to action, and no comparisons, may not be helping your customers understand the value or insight behind the analytic. Chances are, your design needs additional comparison data in order for the primary analytics to be meaningful. One notable exception here is something like an "always-on" dashboard; the kind of UI that is projected up on a monitor in a room for all to see (in theory). (Although...when was the last time you saw actually look at one of those omnipresent dashboards that's always up on the monitor?)  These types of dashboards are best left for another lesson.
  2. Most charts and data graphics can be shrunk and retain the same information density. 
    As a general rule, you can, and probably should be, shrinking your charts and data graphics down to the point where they are still legible. This allows more space for comparison information to be added, or for neighboring components to be visible within the user's viewport (the visible area of a given page or screen, as restrained by the device's resolution/size).
  3. A good dashboard usually will promote information that requires user attention, is relevantly curious or insightful, and facilitates completion of frequently repeated tasks. 
    Instead of thinking about the dashboard as a dumping ground to display the latest values for each of your widgets, consider modeling the design around "What would drive somebody to come back here? What new information can we surface here that can help them? Did we provide links/buttons/affordances to drive people to the things they come to the app/site/product to do on a regular basis?"
  4. Consider usage frequency within your design.  
    One of the easiest things you can do to determine how dense, insightful, and rich your dashboard can be (without overwhelming the customer) is to understand the dashboard's usage frequency. In general, the more routinely your dashboard is used, the greater the information density you can provide (and probably should). Alternatively, if users are only peeking at it monthly/quarterly, you probably need to balance both information density, and how much you can assume about the users' "given knowledge" when they're taking in the latest data. If you have particularly technical information, a dashboard that supports infrequent visits may need reminders about terminology, accepted/normal ranges of important KPIs, etc. A simple example of this would be something like a credit score: if you can count on the customers knowing what a credit score is, and they understand the qualitative ranges, then you might be able to get away with just showing the current score number (e.g. "790"). However, if you know the design will be used infrequently, then displaying qualitative ranges next to the quantitative values helps make the design more useful (i.e. "790 - Very Good").
  5. Consider emailing your dashboard.
    ...but heed this advice carefully!  First, if you already have a killer dashboard, then it may make sense to routinely email some or all of the dashboard information to users instead of asking them to log in. Turn that dashboard into a report card your customers can rely on. Additionally, if you have actionable insights in the email, then let users link directly to the place that needs their attention, even if that means deep-linking into your product and bypassing the current dashboard screen displayed in the browser/software by default. On the other hand, if your dashboard design is lacking or immature, then don't waste the time and resources building an email version of it hoping to see better results. Designing and coding rich format emails that render your design intent properly is still very taxing, and it is even more complicated when it comes to UIs that involve charts and data graphics. Wait until you have a great design/UX before investing in email delivery, or consider altering the design you'll deliver via email. Sending out a low-value dashboard every month just reminds customers to question why they're in business with you in the first place.

More Free Insights:

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

More Free Insights: