What’s in UX for dashboards — chart planet
There is a field called User Experience Design (UX for short) covering … the experiences users are having with various products and exploring ways to improve those experiences.
Usually, UX is not the first thing that comes to mind when you are learning how to make better dashboards. Typically, you learn data visualisation, then all the materials on data infographics and data journalism convince you that you need storytelling because data storytelling is an important topic in business, isn’t it? I have already ranted on how storytelling is not the thing for dashboards, and how UX is the one every dashboard designer should look into.
To put it short — storytelling is for crafting a story, most commonly for a presentation, but also for reading it once. Dashboard is about making an automated data interface, which will be revisited regularly. It might sometimes have story, sometimes it might not. It might provide some story-like features, but definitely not a true complete story. Also, a dashboard might be used by different audiences. And what audiences get when they use something? That’s right — User Experience.
I was shocked after properly learning about UX for the first time — how come it is not a commonly discussed field among data professionals?
How UX came to be my point of interest as a BI developer
I was working as a finance manager and naturally created a lot of Excels and PowerPoints. Later I pivoted into Business Intelligence, so I was doing a lot of PowerBIs. Obviously, data visualisation is a field that unites both professions, but I felt that storytelling which is bread and butter for crafting a good presentation don’t really have its place in dashboard design.
However, I still wanted to dive deeper into the design part. I felt that plenty of Power BI trainings are too tech focused when SQL guys (not necessary in a cube) discover that they can make charts now. Of course, they care a bit more about a custom connectors and MCPs rather than what colours work best together, or how to guide reader’s attention.
So, I decided to learn a bit of colour theory, UX, and dig into “design thinking” hoping to broaden my connecting to humans skills instead of connecting to database skills.
I had some basic prior understanding of UX. I thought that it is something that helps people to navigate digital products, and there are plenty of tips and tricks to learn. Example: always make your buttons rounded corners because clicking a button is like touching it, and people would rather not touch edgy objects.
By learning UX, I expected to increase my baggage of such tips and tricks, but also learn the underlying basics. Knowing the basics makes easier to dig deep.
In the end I learned that UX is:
- not about digital products only
- not about navigation only
- not about visual part only
- also involves custom connectors and MCPs
- also involves project management
- is more about seeing the big picture rather than small tips and tricks
- is way more important than I thought
- it “solves” all the issues designers are having with dashboard adoption
- has a lot to do with dashboard design
Here I am not going to teach you UX basics, instead I will provide the 5 ways to apply UX to dashboard design (or any other data-product, be it Excel spreadsheet, semantic model or schema), that, as clickbait posts say “I wish I knew this earlier”. Those were my 5 most WOW! insights.
What is UX
Before giving the first insight I have to properly introduce what UX really is. But instead of giving a proper definition which will sound as word salad if you haven’t worked in this field for the last century, I will explain when UX is good.
There is a backend — it works, whatever you have built simply does not break.
There is an interface — people can interact with the backend using the interface.
There are user needs — users can meet their needs by interacting with the interface. They are interacting with purpose.
There are business goals — business meet its goals when user needs are met.
Good UX is when everything works together.
When backend fails and data pipeline throws an error — user opens a dashboard and sees that the data is not up-to-date. That’s obviously a bad experience.
When interface fails, users mis-filter, get a wrong impression of the data, and might think all things are fine when they are not. That’s obviously a bad experience.
User needs are not met when there is no view they need, so they rather export to Excel and create the view on their own. That’s obviously a bad experience.
Business goals are not met when due to all the failures mentioned above real business problems are not solved, and business is losing money. Then there are layoffs. That’s obviously a bad experience.
And this bad experience often comes as a result of miscommunication.
Data engineers do not optimize a table to be used for a dashboard because they work on a different team, and they don’t care. How is the dashboard going to have a good performance? Dashboard designer has no understanding who is the audience of the dashboard because they consider them “I’m just a developer, I just do as they say”. So how can they address user needs when they don’t know any? Or in an extreme, but too common case — no one has any idea why the dashboard has to be there in the first place — what kind of business purpose it is solving. Will anyone use such a thing? Could this be an email?
All these things lead to confusion, poor design choices, then poor experience and finally poor adoption. And here comes the first insight.
Insight #1: Work together
I always imagined great UX to be created by a lone designer sitting there, staring at the screen and making a pixel perfect report, with frictionless interaction.
Apparently, they have to know how the underlying systems work. They have to know their users — actually talk to people. And they have to know the ultimate goal of their business.
The same goes for data engineers — it’s so much better when they understand what kind of problem they’re solving. The same goes with product managers — it’s so much better when they understand how backend systems are working. (At least they know there is no such thing as “Just get me that data really quick”) Finally, business should also understand how data works. (So they won’t tell you “AI is going to create all the reports from now, so we do not need data governance.”)
Or even better when people knowing all this stuff are in a single team. Good UX needs teamwork and communication.
Now, since we know the four parts that have to work together, let’s explore the five layers of UX.
The Surface layer
The first layer of UX is the Surface.
- It looks nice, I want to check it
Surface are your screen layouts, images, texts, buttons. Surface guides the user through the information.
And we have to skip this part! Most people associate UX with Surface by default, and I would rather not strengthen this association even more. On to the next topic, where things start getting more interesting.
The Skeleton layer
After you were attracted to the Surface, you tried making sense of what you see.
- I understand what I see
Skeleton is mostly about organizing your elements and navigating through them.
One thing at this layer surprised me a lot — how elegantly you can solve dashboard design problem of having too much information to show. The page is already full, but users still keep asking for more. You can try progressive disclosure.
Insight #2: Progressive disclosure
The point of progressive disclosure is that information is not presented all at once. It has to be presented gradually.
This idea follows very well the Information Seeking Mantra coined by human-computer interaction enthusiast Ben Schneiderman in 1996. This mantra is not about how you should present information because some smart guy was thinking about it, but more about how humans naturally discover information, especially on digital screens.
Get Martynas Jočys’s stories in your inbox
Join Medium for free to get updates from this writer.
First, they overview the whole screen. If they find anything interesting, they look closer. If they would like to know more, they start making actions and searching where to find more. In the end, the mantra sounds like this:
- Overview first
- Zoom and filter
- Details-on-demand
For dashboard design, that means a lot. On every page, there should be an overview. Usually, those are your KPI cards. Then zoom and filter means there should be some visuals providing further details. Very detailed information has to be a few clicks away — usually on another page.
This approach allows providing really feature rich dashboards where everyone gets their information in a single report. You’re an analyst, and you want an analytical interface to try out different scenarios — it’s a few clicks away. You want your huge outrageous export to Excel table — it’s there, but you have to click to get it. Putting all those things on a single page is just impossible.
Providing such progressive disclosure requires the dashboard creator to know very well what is the hierarchy of the data. What KPIs are the most important, so we shall see them in overview? (Could be margin) What dimensions are most important, and we should see them in the first page?
Then other KPIs (margin consist of profit and sales), other breakdowns can be displayed on a different page a click away. Robust knowledge what is the most important for end users, what is next important and what is least — is essential for creating smooth progressive disclosure.
Using such a dashboard with clear hierarchy provides satisfaction because with every click, a user gets some additional value — an additional KPI, breakdown, or a view.
And of course — fewer visuals on a single page means less clutter.
Below is an example of progressive disclosure principle implemented literally with top-down layout.
We start with a big number (overview), then provide more details by region (zoom and filter), then provide more details by country (more zoom and more filter), and then provide even more details after clicking on a button (details on demand).
The Structure layer
After understanding what you see (the Skeleton) you start searching for patterns — how do I even use this thing?
- I understand how it works
Structure is a lot about how information is organized — the overall amount of it, how big are the chunks and how connected are they. Also, how to interact with this information, what is the workflow.
Here I found a fascinating principle which explains how do we get away without writing dashboard usage documentation for end users — how to make dashboard so intuitive, that such documentation is not needed.
Insight #3: Intuitive experience
Intuitive experience means that a user tries your interface (or dashboard) for the first time and immediately becomes an expert of it. Even if they want to solve a new task, they already have an idea how to do it.
This is a huge topic deserving its own article, but for short intro, there are a few things you can do to make sure the experience is intuitive:
Be consistent. Whenever you make a decision about chart types, colours, layouts, filters — keep the same decision for every page in the same report, and even better, for every report within an organization. Once user understands the meaning of colours or the layout in one page — they will use all other pages similarly, make sure they are not hit by surprises.
Be predictable. Use established mental patterns — like a button with little circled i probably means information. People in some countries read from left to right (in others from right to left). Time charts also flow from left to right. Red is bad (in most countries). And so on. When users see such common hints, they immediately assume they know the meaning — make sure they are guessing correctly.
Make things visible or at least findable. If there is some nice interaction — make it possible to see it right away by providing a button to trigger that, or at least add some text explaining how to do it. The most notorious example is drill-through functionality in Power BI, which can be triggered from a pop-up menu by right-clicking on a chart. How a user is supposed to find this? Always add a button for drill-through — when a user opens a report they will see all the options available right away.
Provide feedback. Visual feedback is something of utmost importance in web interfaces. You click on a button, and then you see a familiar spinning animation which says “things are running”. Without this animation, you would just keep clicking. For dashboards, that is rarely a big issue because the tool takes care of it. But still, if you provide a nice button which filters a few dimensions at once — indicate what is filtered. Or even change titles of charts dynamically to represent the current filter context. When a user uses such page — they will see what is the result of their actions.
Be simple. The simpler the layout, the interaction, the visuals, the easier it is to learn those things at a first glance.
Be learnable. All things described above lean into being learnable. Every decision you make about dashboard design is some kind of encoding — this is the way we display the information, this is the way we do the navigation. And then, when user opens such page they can decode — ah, this is the way they do the navigation! Any decisions without too much thought will make things confusing, people will be unable to decode those random design choices.
Below is an actual example of an intuitive semantic model. If fails to be simple because it has a lot of going on, but since the calculations have consistent naming conventions, use predictable abbreviations (like YTD), and are organized in folders, they are easily findable. Using this model becomes a learnable experience. You cannot understand it all from the first try, but you already have an idea how to use any part of it if ever needed.
Making things intuitive is not dumbing things down. It’s making complex things easy to use.
The Scope layer
After you understood how to use the thing, now the next question — should I use it?
- What’s there for me
The Scope is about deciding what content should be there in the final product and what features should it have. In dashboard, we think about content as indicators and their charts, features are filters and other analytical actions.
The next topic was probably the biggest reveal for me personally, that one where the brain explodes. But the more I work in BI field, the more I realize how obvious that thing actually is.
Insight #4: Requirements don’t exist out there
There is a phase in the dashboard design process where you go out to talk to the user to “gather” the requirements, only to learn that they do not have requirements for you.
What they do have is their pre-existing examples, maybe some mock-up made in PowerPoint, or simply a request to transform an Excel table into a dashboard. What’s the goal of this dashboard?, what are they going to do with it after seeing the number? — they don’t really know. Every so often they insist on a specific visual (usually a table), or specific layout not because it is a requirement, but because in their opinion this should work.
A requirement should be a need they have, and a feature is a solution for that need. Instead of providing requirements — users offer solutions, and what we, as dashboard developers need to do is to reverse engineer those requirements back from suggested solutions.
More often than not, requirements are generated on the spot, during the conversations, rather than gathered.
Quite often requirements are negotiated. Users want so many things, that you have to prioritize them, explain what you can do or cannot do, given the deadline, the budget, or the data. Do you want better performance or more charts? Do you want real-time or a weekly snapshot? All these decisions have to be negotiated.
And finally, it is wise to have a “negative scope” — to define not only things you are doing, but also what you are not doing, at least now. We are not bringing KPIs from that table because integration will take so long, leave it for next release. We are not adding this functionality because it is “nice to have” — there are more important things. We are adding only one sales channel for this release because data is not ready. Such boundaries help to prevent scope creep, when everyone has ideas, but no one has priorities.
So, the requirements for a dashboard do not just grow on a requirements tree somewhere in the corner of then office. It is a great effort to extract them out of the collective consciousness of the Business users. And this is not the end of the story because they evolve. No one expected the final result will look like this, so they want a different view. Business has changed while you were sitting there cooking a dashboard, so this new KPI has to be added.
Managing scope is an active, complex and never-ending process.
The Strategy layer
Finally, you have your dashboard, which helps you find the perfect cat memes. But does it help to do their job for anyone?
- Why does this thing exist
Strategy layer is alignment between user needs (cat memes) and business objectives (more profit). Which implies why we are not making cat meme dashboards, even though their adoption rates would be high.
One interesting observation is about who is the user.
Insight 5: You are not the user
You are the expert of the tool you are using. And you have a curse of knowledge — you don’t understand what others might not understand. In the end — you, the creator of things, are not the user of those same things (with a few exceptions).
But hear me out: the stakeholder is often not a user too. Product owner is definitely not the user. Even your client might not be the user. Finding and talking to an actual user might be challenging in some organizations.
A stakeholder might be a confident all-knower, who will not admit the actual user might know better than him. Or they might want to protect the time of their hard-working staff, not involve them in those vague “requirement” meetings. Or they might not consider “the chart developer” as someone who should interact with serious business people.
If any of this is true, you might end up with a dashboard which looks like in the image below:
Explanation: The stakeholder himself has the access to all the data, and sees all the regions. The actual users are region managers, they only see their region due to row-level-security settings. So, they just see a single bar in a bar chart by region. I failed to convince the stakeholder that a bar chart with all the regions on the overview page should be replaced with something more suitable to a region manager.
To know user needs you have to talk to the user, not their representative.
Conclusion
And this is it. Here are the 5 things that I found most ground-breaking for me when I learned about them. Some time has passed since these discoveries, and now all the above principles are a firm part of my workflow.
I hope you learned something new and will also find ways to incorporate it into your daily workflows.
And remember — you don’t need storytelling for dashboards. You need UX.
