7 Crucial Tips for Building Dashboards Users Actually Love To Use

Vaclav Kocian
GoodData Developers
9 min readSep 26, 2022

--

Imagine you’re in a situation where you need to understand a problem quickly and make an important decision. Usually, such a situation would require hours of digging through endless spreadsheets and a ton of not-so-easy analysis. But you’re lucky, and your company has a dashboard for you. A dashboard that guides you and quickly focuses your attention to the root of the problem, allows you to see the numbers in context, and even enables you to dig deep and explore the issue from any angle your data allows. After a few minutes of visual exploration, you’re ready to make a confident decision. Great, right?

And now, imagine yourself in a situation where you have a client who asks you to create such a dashboard for them. Or you need to create a dashboard for the users of your own application. What should you do? Where do you start? Situations like this can be intimidating. But as always, everything is hard until it is easy. The following seven tips are not a definitive guide to building perfect dashboards end-to-end but they will help you get up to speed.

Tip 1: Define the Problem

First, you need to make sure you’re solving the right problem. Building the wrong product for the wrong users is surprisingly easy. It’s a very expensive mistake and a frustrating experience for everyone involved. So make sure you’re solving a real problem people struggle with, not just a well-defined imaginary one. How to do that? Simply start by asking your client questions. A lot of them. And keep asking. Do not settle for the first general answer. Dig deeper and ask why, why, why — go beyond the client’s assignment, challenge everything that is not thoroughly explained to you. What questions should you ask? Let’s see some examples:

  • Who are the users of the dashboards going to be?
  • How do the users achieve their goals right now?
  • What are the typical problems users face?
  • What are the most critical and actionable pieces of information?
  • How does the product fit into their typical day?

A well-rounded set of questions will help you to define the problem properly and outline the scope of the whole project. An excellent tool for asking all those questions is a requirements gathering workshop. Put together business and technical stakeholders from your and your client’s sides for an hour or two and start finding the answers.

But do not stop at just asking the client about the project. Go and talk to the future users of the dashboard. All this brings us to the following point.

Requirement gathering workshop done in Miro

Tip 2: Know Your Audience

Remember, you’re not your user. Nor is the colleague sitting next to you. And it’s definitely not a client who tasked you with creating the dashboards. If you’re building a dashboard for real people, you need to get out there and speak to those people. Not every single one of them, of course. Five participants are usually enough to make a good round of user research. And it’s not just about asking the right questions, learning to listen to the answers is equally important. You need to listen carefully, empathize with your users, and truly understand them.

So plan a research session and keep asking questions. And again, do not settle for the first answer you get. Get down to the root cause of the user’s needs.

And by needs, I don’t mean the user’s daily tasks. People don’t need to create a spreadsheet — they need to know the company’s sales performance. And not just to know, they need to act on that knowledge. So always go beyond the superficial day-to-day work and search for their underlying needs.

And don’t shy away from wandering into the less pleasant territories. Ask for users’ struggles and pain points with their current solution. Because fulfilling a need is great but alleviating pain is even better.

That’s why most successful products, not just dashboards, tend to be painkillers. Not just vitamins. You can skip vitamins for days or forever and be just fine. But try missing painkillers, and you’ll realize that pretty quickly. So try to discover the most aching pain points of your users. If you can help them replace a day of work in spreadsheets with a single dashboard, great! Even better if the users are doing that report every week and now they just change a date filter with a single click.

Sometimes it’s not possible to interview the end users. Then you need to be creative. Ask your client more questions. Do a round of hallway testing in your company. Use online user research tools to access similar users. The goal remains to get at least some information about the future users of your dashboards.

Tip 3: Define the Dashboard

Now you can start shaping the dashboard’s outlines which meet your client’s and user’s requirements and needs. There are different types of dashboards, and by now, you should know if you want to show just a few essential KPIs, build complex dashboards guiding the user, or allow the user to roam around and freely combine the data points to reveal insights on their own.

But how to move from the piles of meeting notes and workshop miro boards towards something more visual and tangible? And without spending valuable time on actual development?

Wireframes are a terrific tool for precisely this step. They are quick, cheap & easy to make, simple to change or scrap, and, mainly, easy to understand by everyone. At the just-right level of complexity, they serve as a middle ground for all involved parties — both business and technical, both from your and the client’s sides. They can help you get your vision of the future shape of the dashboards across and still carry the message “this is all up for discussion.”

You can use a fancy tool for creating wireframes like Figma with a vast library of various charts and UI elements. But you definitely don’t need to — grab the thick black marker and a few sheets of paper and start scribbling. And don’t censor yourself at the beginning — generate many ideas first and only after that, converge and iterate towards the final design of your dashboards.

Wireframe done in Figma

Tip 4: Focus the User’s Attention

The dashboard should not be just a data dump of your database. Putting a bunch of data points upfront, with everything on the same level of importance, only confuses people. Nothing seems important when everything has the same level of prominence on the dashboard.

The general idea is to start at a high level and lead the user into more details. A small number of the most important KPIs can tell you your business performance at a glance. Put those front and center to help users understand which areas are not doing well. Lead them through your dashboards with drills and allow them to discover the root cause behind specific KPI’s performance.

Even if you aim to build more explorative dashboards, it’s still a good idea to focus the user’s attention on some critical data points first and allow the exploration from there.

See the example below of four main KPIs that might belong to an e-commerce company. By clicking on a KPI, the user can drill into a more detailed dashboard about the selected area — sales, orders, or customers — and explore the problem in greater detail, which is not possible on the overview page.

Most important KPIs — front and center

Tip 5: Choose the Right Visualizations

Showing a data table is good, but showing a bar chart is even better. Or a line chart. But sometimes, it is still the best way to stick with the table. It depends on the context. And on the end users. Luckily, you have all the information you need if you followed the previous tips. But most importantly, it depends on the nature of the data you want to show.

Always choose a visualization that most clearly and efficiently communicates your data. The user should take as little time as possible to understand the meaning. So do not shy away from “boring” chart types like bar or line charts. These are typically the easiest to understand, which is the end goal.

Avoid any exotic chart types just for the sake of the wow factor on the dashboard. Always keep in mind what is the type of information you want to communicate to your users. Speaking of eye candy, remove any visual clutter which does not carry information — all unnecessary images, gifs, lines, etc. Just remove them and let the charts shine. Last but not least, don’t mistake dashboards for infographics. Infographics look fancy, but they’re typically static, single-purpose artwork, which is rarely helpful or usable with generic business data, which can take many shapes over time.

That said, test the dashboards with an actual or a similar data set to the final production-level data.

To dive deeper into the different visualizations and charts, you can check the article about choosing the right data visualization on our GoodData blog.

Bar chart vs. Pie chart for the same data

Tip 6: Put Your Numbers in Context

Showing numbers and charts is nice, but they carry very little information without context.

A sales volume of $7 million is impressive, isn’t it? That might be true if you’re a small local company. But not as great if the previous month’s volume was $23 million, or if you’re a large company with an expected sales volume of hundreds of millions. To give your user the context, show them another number for comparison — the previous period, an industry benchmark, or a goal you aim to achieve.

Suppose you design a dashboard for a season-susceptible business. In that case, it’s better to compare the current period to the same period (i.e., a month or a quarter) in the previous year rather than to simply compare it to the previous period.

The date range also gives your numbers context. Knowing whether you’re looking at today’s or last year’s sales volume is essential.

Bullet chart — bar chart with a secondary metric. Spend vs. Budget in this case.

Tip 7: Integrate

Building a standalone analytical application, a dashboard, without integrating it into the existing systems is the best way to create a product that the users won’t use. It is just one more system to think of, to log in to, separated from the area where the work actually takes place.

Embed the dashboard into the current system. Integrate it with a single sign-on, so it’s easily accessible with a single click.

Pay attention to your surroundings. Not just when crossing a busy street but also when building a dashboard. Your dashboards will have some application around it — an application already known by your users, so try to match the style, colors, terms, and overall style and feel with the parent app.

If you want to learn more about how easy it is to embed a GoodData dashboard into your application, check out our other article here on Medium.

Conclusion

That wasn’t that hard in the end, right? Building dashboards is no witchcraft or rocket science. It is more like a blend of craft, creativity, experience, and the right pieces of knowledge applied at the right time.

To wrap things up, first, you need to understand the problem you are trying to solve, then empathize with the users and their needs, and only then build the dashboards accordingly. If you start your dashboard-building career by sticking with the tips mentioned above, you can’t go wrong.

--

--

Vaclav Kocian
GoodData Developers

Dataviz & analytics enthusiast | Senior UX Designer @ GoodData | Mountain climber | vaclav.kocian.in