Dashboard design & requirements: the struggle and the solution💡

My name is Simon. I’m a front end enthusiast at delaware, working on all kinds of data & analytics projects 📈.

Today I wanted to talk to you (yes, just you!) about the struggle of building dashboards and reports for the business community. Not the technical challenges that come with creating a data model or making sure your applications are intuitive and pleasing on the eyes but rather about how to get what’s inside a user’s head and translate that to clear requirements for data visualisation.

After you read this post and are in awe of the things I came up with I’d love to see all of your praise in the comments! (just kidding👼 I’d love to hear your remarks so I can further improve)

Ready? Get set. Let’s go 🚀.

Data visualisation is hard. Tools these days make it very easy to create bars, lines and pies and slap them on a page. So easy in fact, that the only thing clients seem to care about when planning a new analytics project is how many different charts the tool can produce. Afterwards it’s just a matter of making the tool available to your employees, right? So they can make shiny things? 💠 Sadly, no… A strategy like this will render the investment pointless. Too many things will be created that aren’t fully tapping into the potential of dashboarding and people will lose faith… and go back to everybody’s good friend excel.

Data visualisation is a lot more than picking a tool and creating charts. It’s about a thorough understanding of people and their needs (and appreciating the change a project like this brings for them). You need a good understanding of their mental model. Your dashboards need to reflect that mental model and present it as a story they can read. One could almost argue we need careful planning and requirements gathering!

You know what else? Requirements gathering is hard. The hardest part.

I see it all the time: dashboards and reports are developed only to never be opened again. Is that because the people who should use are so reluctant to change? I don’t believe they are. I think it’s mostly due to not understanding the needs correctly (or not taking the time to try and understand them).

So just organise a workshop and ask them what they want! 🙄

It’s not that simple. Like Henry Ford said:

If I asked people what they wanted, they would have said faster e̵x̵c̵e̵l̵ horses.

People are really bad at predicting a future situation. What we are good at though is unpacking a problem when it is laid out visually in front of us. Drawing to the rescue! ✏️

A problem visualised is a problem halved

I noticed in workshops that starting to sketch was to daunting for a lot of people. So I needed an alternative. That’s when I thought of the possibility of using a card deck.

Why cards? Research has shown (Touch Neurology, 2011) that cards will clear your mind and improve your thinking process. It will help focus on the task at hand and gives the developer of the dashboard a good opportunity to really get to know the problems you are trying to solve.

For the cards I came up with the following structure, which I like in all my dashboards:

1 Scan the big picture

That’s the job of the KPIs displayed on the most prominent place of the screen. For those I included KPI cards:

With on the front the possibility to write down a sample metric with title (titles are important, makes everyone in the workshop agree on what they are showing) and on the backside some more info. The charts that tell more about the metric are the link to step 2.

Note that you can write on the cards with a dry-marker and wipe them clean. I still wanted for people to write down notes and thoughts.

2 Zoom in on important details

One of two possibilities:

• Filters: I don’t like filters on dashboards. As humans we are not equipped to make comparisons if we need to switch views all the time. We need the info all at once. However, it can be a good way to save screen space for information we do not need to see together.

Again with possibility to write down some sample values we need to filter on and some more notes (like what charts need to filter?)

• Charts: when well designed, charts offer the possibility of instant insight. Which is what we are aiming for in a dashboard. I created a set of 40 charts (only the ones I believe belong on a dashboard, sorry area charts 😢) with explanation on how to interpret them and in what context they work best.

The front shows an empty axis, to write what we want to show. Other cards also show legends when multiple colors are being used. The yellow boxes show the different categories this chart can be used in. Options are: Part to Whole, Deviation, Magnitude, Correlation, Change over time, Spatial, Distribution and Ranking.

For every chart participants also need to answer these two questions:

A dashboard is all about actionable insights. If the second question can’t be answered, the chart does not belong on a dashboard.

3 Link to supporting details

This can be achieved by clicking or hovering over a chart. It can show some more details in a popup or redirect to another report. It can even link to an excel. Depending on the technology, filter values can also be passed around.

A small card that can be added to a chart to define some functionality when someone interacts with the chart.

After trying this out, I noticed things got messy because the cards were flying all over the table 🛸 I then decided to make the cards magnetic and added a magnetic board. Added benefit is it mimics the constraints of the screen size. This makes people aware of the fact they can’t throw anything they want on the screen.

Context, context, context

An analytics project is more than visuals alone. What about data sources and IT infrastructure? That’s why I also created a board that I call the Lean Analytics Canvas (after the business model canvas). It can provide vital context together with the mockups you create and is easy to iterate over.

This is something I’ll discuss in another post, I don’t want to make this one too long 👶

Overview of the cards and boards

The intention of the cards is to define the requirements of a dashboard in a fun and engaging way for both the developer as the people who will use it. I believe taking an approach like this will result in better products that will actually be used.

What are your thoughts? Experienced anything similar? See potential for improvement? I’d love to hear it in the comments!