The most critical lesson about Data: think indirectly
Data can be your competitive edge as a Designer, if you understand how to think about it.
Most designers I've met have a single common stumbling block around Data, which prevents them from learning several valuable skills.
From creating Data Visualizations, which use our Design skills and processes, to Data Storytelling, which persuades audiences to empathize with our users, Data can be a competitive edge in this weird job market.
However, whether I was helping Designlab create its Data-Driven Design course, writing a book on the subject, or creating my course on Maven, I've seen Designers stumble on the first and most important lesson: how to get started.
If you're working with Data, the first and most important lesson isn't to learn Python, Excel, or Analytics. Instead, the first step is learning to think indirectly about data.
Designers often have no experience thinking indirectly about data
What do I mean when I say "thinking indirectly about data?"
Consider how you gather feedback from the user testing process. Perhaps you've talked to 5–7 users and created a spreadsheet to store all the users' responses.
At this point, you're thinking directly about data. You're going row by row, column by column, to figure out what some shared insights might be. You might even know the answer to a question like "What did Participant 3 say for Question #7?"
This deep dive into how particular users responded is the basis for qualitative research, and it's how we obtain valuable insights to present to the rest of the team. But this approach doesn't work for 5,000 users.
If you tried to do such a thing with such a large spreadsheet, you'd get lost or waste a lot of time. On some level, we know what we need to do: summarize the spreadsheet somehow to figure things out.
But I can't tell you the number of times I've seen designers become deer in headlights when they see such a large spreadsheet, unable to process what to do next.
I get it. As a designer, you might not have worked with data of that scale before, so it's intimidating. However, this is why learning to think indirectly about data is necessary: figuring out what you're looking for before looking at a spreadsheet is how you avoid getting lost.
To show why, I want to discuss a data professional's workflow and the importance of queries.
Data professionals, Queries, and thinking before looking at data
Data professionals aren't a different species of human. They're not excited to see a million rows of data in a spreadsheet, but they're not intimidated. This is because they have the tools and rationale to think indirectly.
Part of how they do this is through something called the Query. The query is a question formatted for a computer to do the heavy lifting and answer for you quickly.
For example, if we were to provide the query "How many people answered Strongly Agree (i.e., 5) to Question 7?", the computer can quickly go through an entire column of responses and spit out an answer like "372 people."
Similar commands can also modify datasets, improve data quality, and tackle many other job responsibilities. When you learn this, you realize that thinking indirectly about the data isn't about staring at the dataset and hoping for answers.
Instead, you just need to figure out the correct queries to ask of the data. You might also realize the big mistake many data novices make: you don't need to look at the Data to figure this out.
Figure out your queries, or why you're even looking at a dataset
In learning to think indirectly about data, the first step is to take a moment and put the data aside.
Instead, write down a quick summary of what you're trying to learn from a data source. Doing this before looking at a whole bunch of numbers helps you keep your focus.
In many cases, you're trying to determine whether what you saw is a common occurrence. For example, imagine that 3/5 users had issues with the checkout process in your user testing process. You want to get some data about the checkout process to determine whether this is a common occurrence, along with why and where.
You might write down the following questions as a result:
"Are there a lot of people that have an issue with the checkout process?"
"Where are the most common pitfalls in the checkout process?"
"Where are users running into errors in the checkout process?"
"Is there a steep dropoff on one of the checkout process pages?"
"Are users spending a lot of time on the checkout process pages?"
etc.
Writing out these questions and listing what you hope to find in the data can help you keep your focus. Here's the thing: Data professionals never just look at the data and hope they stumble upon something interesting.
There are always weird patterns in data, and without any idea of what you're looking for, it's easy to get lost in the data. So, this list of questions is to help keep you grounded and find precisely what you're looking for.
After that, it's time to consider looking for signals.
Signals in metrics: how we're able to draw conclusions
After writing that list of questions, the next thing you'll write is how you expect to answer this question from the data. This is important because, you might not be able to answer all of the questions on your list working with the data.
For example, my third question, about "where users run into errors", is not something we can get from data. At best, you might be able to narrow it down to a single page.
The other thing to remember is that this is where metrics might come into play. While some knowledge of metrics will be incredibly helpful here, you don't need to have metric mastery to figure out this question.
Here are some of the more common Signals that you might write down:
Workflow (If 10,000 people land on the credit card page, and only 2,000 moves to the next page, that might signal problems on this page)
Change over time (If the checkout process used to take 3 minutes, and now it takes 6, that might signal a problem)
Benchmarks (If six months ago our metrics were better than now, that might signal a problem)
Outliers (If there are outliers in the data (I.e., there are a few people that spend 20 minutes on a page consistently), then this might signal a problem with the user experience for a target user group)
New vs Returning User (If there's low user adoption, perhaps this signals problems with the initial experience)
etc.
Whatever the case, think about these signals and how to find them. If you’re unsure where to find such things, I recommend my book (or upcoming course) to learn how to find these things.
However, once you find this list, you can finally begin looking at the Data with a clear goal.
Thinking indirectly about data becomes easier with this list
When you have this list of queries, it becomes much easier to look at Data and not freak out.
The best analogy is having a shopping list for a place like Costco. Without it, you might spend $50 on a 5-pound container of Cheese Balls or be distracted by the colorful decorations. However, once you have a clear idea what you’re looking for, it becomes easier to navigate.
That’s not to say that writing out your list always works: sometimes, you don’t find what you’re looking for in the data and might have to look elsewhere.
But doing this avoids the often visceral reaction Designers have towards Data and helps you learn how to work with it. As I’ve found, this helps Designers become more comfortable working with data.
Data has been my competitive edge as a Designer
When I was suddenly laid off while recovering from COVID, Data was my competitive advantage when looking for Design jobs. Interviewers, especially hiring managers, pointed to my background working with and visualizing data as one of my strongest points.
Was I hired simply because I was a Data-Informed Designer? I don’t know. However, learning Data, rather than Engineering or Business, can be a great way to augment your design skills easily.
However, ensure you don’t stumble on the first and most important lesson about Data: thinking indirectly. Once you do that, Data will suddenly become much less intimidating.
I’ve revamped my Maven course to teach Data Informed UX Design. If you want to learn this valuable skill, consider joining the waitlist.
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.