Seven principles from UX/UI design to improve your business data visualizations, Part 1
Sometimes I forget I am on Substack as well as Medium (most readers are there, but I like this platform better). Sorry. Part 2 is coming Monday.
Curious as to whether my education in data visualization best practices, experience working with clients, and personal design preferences aligned with what would be considered “good” user experience design from the point of view of UX designers, I decided to make a mind map of what makes a data visualization experience “good” in my own words, avoiding jargon as much as possible. Keep in mind that the spirit of this exercise assumes that the visualizations in question are business-oriented or intended to convey some specific message to a target audience like, “COVID-19 cases rose sharply in your county this month,” so that the user may take some action such as adjusting staffing levels or adjusting masking levels.
Seven broad themes emerged as I wrote and erased, and wrote and erased some more as I was able to group some concepts together and move others around. The finer details of what I consider good dataviz UX mostly fit into one of these broad categories (some fit into more than one) and have been sprinkled into the descriptions of the main themes.
A good dataviz user experience is audience-centric. Seems obvious, but how many times have I — not you, of course, but I have — gotten caught up in making a fancy chart or doing some linear algebraic gymnastics when there was a real person just trying to answer their data questions waiting on me to finish the calculations to create my polygons?
I love data art, “non-standard” chart types — what Brian and Jacqui Moore call “totally useless charts” (which I am seriously so grateful they proceed to teach us how to build), pop infographics, and even the occasional graph I find on Reddit.
However, in a business context, where an organization is paying us actual U.S. dollars to create data visualizations that help them understand and act on their data, we must keep their requirements (you did gather those, right?), data literacy, goals, and — yes, I hate to admit it, but yes — even preferences in the forefront of our datavizzy minds as we brainstorm, storyboard, prototype, design, and test. (Y’all do all those steps every time, too, right?)
Talk to them about their needs, their questions, what their team actually does, how their team is structured. Maybe there needs to be a team view and a c-suite view. Maybe they don’t need a dashboard at all, but an ad-hoc analysis.
(Or Flow. Or integration. I had a very hard time naming this category.)
A good data visualization user experience is cohesive. It’s one whole experience. A random, tenuously-related collection of charts, graphs, and KPIs does not a successful dashboard make. I don’t think that’s one of my potentially controversial hot-takes (those are later, keep reading 😜). And, in theory at least, I think most dataviz practitioners agree. But when under the weight of a super-duper-aggressive deadline set by some tech bro who has no idea how to create a data visualization let alone fix one created by someone else while having ADHD, or foggy with the haze of chronic burnout, or disheveled by a flurry of new projects…sometimes we just toss one more heatmap onto the view and call it a damn day. I don’t have any recent personal experience of this nature, of course, I just heard that’s how it be sometimes. (At 🫒 company name redacted 🫒 Where you should not go to work. If you like your mental health.)
You know what’s NOT cohesive? My writing on point number two.
Wait. Here we go. Back on track. Choo choo.🚂
Cohesiveness relates to data storytelling. If you cannot explain in a sentence or two how a bar chart displaying the number of customers converted by UTM parameter relates to a line chart showing conversions over time by segment, then why are both of these charts present on your dashboard?
I used the word cohesive instead of “storytelling” because your dashboard should be visually cohesive, too, with regards to things like typographic hierarchy, color, arrangement of menus, buttons, and filters, container placement, and style. There should be a sense of integration and flow. A few of these elements are not entirely objectively measurable, but we know those when we see those, right? Right.
Lindsay Betzendahl’s viz “Generating Vizzes — My Tableau Public Data” embodies that element of flow and integration. There’s a feeling of movement from bottom left to upper right. You feel it. I know you do. That integration of story, visual elements, and data is what makes Lindsay a Tableau Visionary and not just a Very Good Data Visualizer.
The interactivity I’m thinking of absolutely involves useful information in tooltips, reshuffling of categories via parameter actions, show/hide buttons, collapsible containers, and every other trick I’ve learned from 👬🏼 the amazing Flerlage Twins.👬🏼 (They had a post recently that has vastly improved my histograms.) Many informative, brilliant, complex static data visualizations exist (I could study them for hours), but for the business user, interactivity facilitates the creation of a relationship — interactivity — between the user and their data. They get to know it, feel more comfortable with it, and finally feel as though they can ask it the hard questions. This interaction should strengthen — or help create — a relationship between the 🫂 business users and the data team 🫂.
As data and analytics teams, we must get the fork down from our ivory tower made of dbt and data mesh and surrounded by a moat-like data lake and be available to answer questions about the data.
Not just that one dashboard, or the data at the company, but data questions, specific and holistic, real and theoretical. On several occasions, I’ve sensed some hesitancy, reluctance, or shyness from a stakeholder, so I’ve tried saying something like, “Are there any questions that these visuals aren’t answering for you?” Or if they look puzzled — perhaps because a tree map doesn’t make sense to their neurotype 🚨SPOILER ALERT🚨 yes, I did just make this about neurodiversity before I even got to #6, Accessibility — or maybe they were distracted by an urgent email when I was covering that point. I’ll say, “Let me show you the same data another way,” and I swiftly make a bar chart because I am so brilliant — ahem — I mean because Tableau is so fast and easy. I could just have alternate chart types on back-up sheets whenever I present data to a group, but the making it on the fly is the thing! It’s the spark of conversation that will facilitate the user’s relationship with their data by way of their relationship with you, which may have not existed until you took the 60 whole seconds to make a basic bar chart. But now it does exist, and it’s a beautiful thing. Really.🧡
This series of posts was inspired by a Twitter exchange I had recently with some of the #Datafam. Stay tuned for Part 2 on June 20. In the meantime, let me know your feedback. Do you agree? Disagree? Why?