As a UX Designer, I’ve worked on analytics dashboards for companies across multiple industries. Cybersecurity, consumer goods, defense, Business Intelligence tools, AI, and other complex systems. While navigating the dizzying amount of information, tips, and guidance available online about how to go about designing a dashboard for analytics, stay focused by honing in on answering your primary users’ top-of-mind questions.

It is easy to succumb to the temptation of immediately trying to find a solution, jumping right into the ‘how’ and drawing up interfaces. To start sketching donut graphs and sparklines, histograms and charts. But don’t! It’s easy to sidetrack yourself by arguing about colors and font sizes, but don’t go there yet. I’ve seen that happen and it’s a waste of time. Begin by forming a solid understand about the context of the product or service. Who, what, when where — before the how. It seems simple, almost stupid, but it’s critical. Once that is clear, it will guide the decisions on implementation. Just like the Cheshire cat in Alice in Wonderland said:

Alice: Would you tell me, please, which way I ought to go from here?
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don’t much care where.
The Cheshire Cat: Then it doesn’t much matter which way you go.
Alice: …So long as I get somewhere.
The Cheshire Cat: Oh, you’re sure to do that, if only you walk long enough.

Who will be using said dashboard? If there are a few users, identify the primary and start with her. Note the secondary users, but stay laser focused on the primary user at first. You can expand and adapt to support the secondary, but doing so initially will only distract you at an early stage. Are they a business user? Technical? What is the goal of that user? What does she care about? How is her success measured? Consider all of her other tasks, and how this dashboard is going to fit into her very busy workday.

When?

Trigger

What’s the trigger for your primary user to look at the dashboard? A specific event that occurred? Only when things are going really poorly? When everything is going well, just to monitor? When they have lots of time, and need to do deep analysis?

Frequency

What is the Every morning when she walks in to get her coffee? Every month so she can prepare a meeting to top management?

Duration

What is the duration of use for said dashboard? A few minutes? Hours, as her main job ?I’ve worked on a complex system UI used by technical professionals who said they used it for up to 4 hours a day. (Of course, the goal is to get them in and out more quickly.)

Where?

Location — office, home, on the road

Are they using it in the office on a desktop, or at home in their laptops at night too? Once I worked on a legacy system for mid-sized organizations. It had been built with the assumption that it would be used only at work, on desktop. However, after speaking to users, I realized that some users needed it at home for critical events, late at night, which meant laptop. They had a really hard time using it, and could not access all functionality, since it was not designed with that use case in mind (these days it’s rare to find user interfaces that are not built with responsive design at least to laptop resolution). What about the mobile, or tablet on the road use case? Do you need to support it? Answering this will impact the solution.

Supplementary

Is this analytics dashboard used alongside other systems? In complex environments it can be the case that there are other interfaces, data sources, and systems in place, and this dashboard will be one of the multiple sources used in a workflow. If this is the case, consider how to best integrate within the context of use. For example, I made sure to offer copy id functionality easily, so that users could easily jump between interfaces — front-end, Command Line Interface, and API. Later down the line, this need was validated.

Why does she need to consult with the dashboard? Usually it’s to answer a question, or multiple questions. Who is asking the question? Why are these questions important to answer? What will they do with the answer (a report, a presentation, a conversation, a decision). Make a list of the questions. Then assign a topic to each question. Categorize the topics that emerge from the questions. Once you have this, you can rank the importance of each question within each topic, and identify the most pressing topic per category. Or write a new question that best represents that category. After that, you will have a short list of categories, with one core question for each category. Finally, you can identify the most important category in relation to the others. This will be the initial, most prominent use case to design around.

Answering these is the tough part. You just identified the persona, her customer journey, and her primary and secondary use cases. Now that you have this information, the rest becomes more straightforward.

Congrats. You have made it through the hard work. Now, for this stage, you can rely more heavily on the UX and UI Designers to help with implementation. Also, there are plenty of great resources that can guide which type of chart or graph you need, based on your core use case. What you want to address here, is “will this answer your primary users’ most pressing questions?” If the answer is no, then go back up to previous steps until it’s more clear.

Brainstorm solutions

You can now generate ideas about how to best answer your most pressing question. There are best practices for which visualization to use based on what you need to communicate.

Select & converge

From amongst the solutions you (and team) generated, selecting one will be easy, since you have the focus of the questions. Which solution to choose is not based on arbitrary variables, but rather, based on the very clear goal of answering your primary users’ top-of-mind core question.

How not to.

I’ve been dragged into long and impassioned debates about using one color over another, even before the team had clarity on the questions posed here. I’ve been dragged into an ego-based discussion about ‘who was right’ about what the new dashboard should be? And I’ve seen the unfortunate effects of featurism in the place where PMs and Designers try and throw a bunch of pretty information at poorly defined users to see what sticks. Nearly none of it does.

Recap

Going through the process by answering simple questions posed above can save hours and frustration. It wasted a lot of time and was an exercise in frustration.

Thanks for reading!

About this series

In this article which is part of a series Design Techniques, I explore techniques tactics and methodologies I’ve come across in my experiences working as a designer.

About the Author

I’m a UX Designer turned Product Manager, with experience in startups, freelance, and agile B2B2C companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.