top of page
  • Writer's pictureT. @ Data Rocks

Design Matters #3 - Mapping Journeys






 

This is a repost of the Design Matters series I run as part of my newsletter, originally sent to my subscribers on 27 July 2023.


If you'd like what you read, consider subscribing so you can get all upcoming issues fresh when they're first out!


 

Welcome to issue #3 of the series Design Matters.


In this series, I’ll share with you how design can help your dashboards go from average to awesome.


You might be a seasoned Business Intelligence developer, an enthusiastic manager, or an analyst dipping your toes into the field for the first time. Regardless of where you find yourself in your data journey, the goal of this series is to shed light on how design plays an indispensable role in data analytics - not just in making things look pretty but in affecting understanding, communication, and decision-making.


In the last issue of Design Matters, I covered the importance of having a clearly defined context, audience and purpose before you jump into building your dashboards. Today, we will expand a bit more on what that looks like in practice.


If you haven’t read the previous issues yet, you can check #1 here and #2 here.


 

Observe and cut through noise


Observe is the first stage of the loop, highlighted in the image.
The initial stage of The Loop

When we talk about developing a dashboard, the most common process is to ask people what they want and then jump right into developing these requirements into features. Analysts are usually anxious to get the ball rolling, and managers are anxious about quickly getting the information they need.


But this interaction doesn’t always seem to work as expected. Ideally, the people asking for a data display would know what they need and ask for those features accordingly. And analysts would understand what the users mean and just get on with giving them the data, KPIs and visuals they asked for.


But here are the top 2 complaints I hear whenever someone asks for my help with their dashboards:

“The users don’t know what they want and keep changing their minds” - every data analyst ever

and

“I get all these advanced and cool features from the data team, but none of them is what I’m looking for. I don’t know where to get what I’m looking for.” - every person using a dashboard ever.

But why does this happen? And how can we prevent it from happening in the first place?

There are a few points I’d like to address before we get to these answers.



Most of a dashboard’s success is defined outside of your BI tools.


This often comes as a moment of reckoning for many Data & Analytics teams, but your tools won’t ensure your success. Your people, communication, processes, frameworks, and expectations will. All of these elements exist regardless of which tools you choose to work with. You can use Excel, Power BI, Tableau, Qliq, Looker - you name it. A successful dashboard is less about the tool and more about what people do with the information they get from it, regardless of how they got to it.


The (incorrect) assumption that tools will solve the access to data in a business leads a lot of Data & Analytics teams to see spending time with user interviews, context mapping, wireframing and planning before development starts as unnecessary. The tool will connect to the data, and the people will get all they want. It’s all there. Why would I need to do all of this pre-work?


The truth is that, in the overall process, the time it takes from user request to delivery of a first version of a dashboard is largely the same, regardless of how a team chooses to allocate that time. It is not how long it takes, but rather in which tasks the time is spent, that defines whether a dashboard can fulfil its purpose.


You can choose to jump straight in, add all the cool features of your tool, and deliver an iteration of the dashboard that will get users frustrated and go through several reviews and adjustments - getting the analyst frustrated too. Or, you can choose to plan, map the user’s needs, prototype and wireframe options to solve their problems and validate with them before the build starts, then build and have a much smoother iteration process.


If your dashboards seem to all fall flat in user adoption, maybe shaking up how you approach the engagement and communication with the people using them and where you allocate your building time may help you more than you think.



You can’t isolate the person from the context


Let’s suppose you go out for dinner and ask for “cutlery”. Your request is correct. You need cutlery to eat dinner. The waiter goes to the kitchen and grabs the nicest fork they have. They want to be nice to you and serve you well. They hand you the fork. You look at them baffled - because you are eating a bowl of soup.


Often this is what your dashboard is doing. You’re giving your users a whole collection of forks and knives when they only need a spoon.


Most traditional requirement-gathering processes focus on asking what the user wants or needs but cannot identify where they’ll use it, when, and how. Your data will be consumed differently if your user needs it to feed on a weekly meeting slide deck or if they need to run a detailed root cause analysis of a process. And for each one of these contexts, you’ll likely need to approach the way you display this data differently.


The focus should be on outcomes, not features


When creating a dashboard, you should very clearly define what it’s trying to achieve. What problem is it solving? What pain points is it addressing? What will your user be able to do tomorrow with this dashboard, that they can’t do today?


A lot of the problems with evaluating if a dashboard has accomplished its purpose is that a purpose hasn’t been clearly defined in the first place. Mapping the current process your user goes through to satisfy a need for information and then comparing it again once they have the data display they asked for is a good way to assess if the dashboard has accomplished what it was set out to do. It isn’t always about revolutionising the decision-making of a company. It is also not about having a large number of features either. It is about setting out to solve an issue and then solving it.



 

User experience maps applied to dashboard design


User Experience (UX) design focuses on building the ways humans interact with apps, interfaces, websites and other products. And they have a few resources that can be adapted to help us map and define context, audience and purpose in dashboard design as well.

One of these resources is Journey Maps.


In a nutshell, these are a visual way to record information not only about the people who will use your dashboard but also what their current journey in using data looks like. It helps to map pain points, areas for improvement in their workflow or processes and how the availability of data can help them within the context where they use it.


The advantages of dedicating time at the start of a dashboard development process to map who your users are and their struggles and preferences when it comes to working with data are countless. You’ll get a chance to involve them from the start of the project and understand how they currently work without all the information they need. You can assess what their preferred ways of working with data are. You can understand how comfortable they are reading, analysing, working with and communicating with data in their daily processes.


It is a chance to connect and communicate expectations as well. There’s also solid research about how collaborating in the creation of Journey Maps helps improve not only the outcomes of a project but also how the project and communication flows. It also helps with aligning expectations from all parties involved.


There are tons of different ways of approaching Journey Maps in UX design. The good news is that I’ve done the hard work of trial and error for you and have been curating my own template for a few years now. At the bottom of this newsletter, you’ll find the link to the PDF version of my Dashboard User Journey Map, instructions on conducting the user interviews, and recommendations of questions to ask. Ideally, you’ll have one of these maps for each context-user combination. That way, you can have a detailed view of all the outcomes each user expects to fulfil with your dashboard development.


This is part of a broader collaborative process, and it may continue evolving while your development goes on. It’s obviously just a tiny fraction of the work that mapping user journeys entails, but it is a good exercise to kick off your next requirement-gathering process in a different way in case you feel like you’re in need of a reset but are unsure how to go about it.



 

I’d love to hear from you - have you ever tried mapping your user’s data journeys? How did it go?


 

You can download your Dashboard User & Journey Maps here.


Subscribers of the newsletter got the Dashboard User & Journey Maps for free when this article was first published. 


The PDF version is now on a ‘name your price’ basis with a very low minimum amount. If you’d like to support the effort that goes into writing this newsletter, consider downloading it or entering a higher amount. 


If you like freebies, though, consider subscribing to the newsletter! I often drop more helpful resources like this there first, either for free or at hefty discounts.😊



Until next time,

--T.


 

This is a repost of the Design Matters series I run as part of my newsletter, originally sent to my subscribers on 27 July 2023.


If you'd like what you read, consider subscribing so you can get all upcoming issues fresh when they're first out!


If you like what I share and would like to support my caffeinated habits, you can buy me a coffee!


 


Comments


bottom of page