What does "data-driven" mean? In simple terms, it’s a mindset where we prioritize or use data as the backbone for making decisions.
In the tech industry, being data-driven is one way to measure a product’s success and evaluate its performance. Data is one of the most reliable sources for understanding what’s going on with our customers in a broad and efficient way.
The main idea is that data is closely tied to facts.
If the data shows that customers don’t like our design, there’s a good chance that reality reflects the same thing.
Of course, there’s the issue of whether the data is valid or not, which is a whole topic in itself about how to ensure and pull valid data. We’ll skip that part for now.
Benefits of Data-Driven Thinking
So, what are the benefits of being more data-driven as a designer?
Your designs will be more effective (you’ll avoid making mistakes and wasting resources across departments).
Your designs will have stronger reasoning (making them more convincing and easier to get management buy-in).
They’ll be easier to evaluate (because you’ll have a clear foundation to refer back to).
Let me give you an example:
Say you get a project from a Product Manager (PM) to revamp the app's onboarding screen because sign-ups have dropped this month.
If we don’t dig deeper, we might do something like this:
Look at the current onboarding design.
Browse Dribbble for onboarding screen references.
Search Mobbin for other app references.
Create some design variations for a presentation.
End up with a design we don’t like but the PM does.
After development, sign-ups don’t increase.
So, where did we go wrong?
Well, there were a lot of mistakes.
Mainly, we jumped straight into creating solutions without validating the problem.
There are several approaches to validate the issue before jumping into solutions, such as conducting research, mapping out information, or—what we’re focusing on—looking at the data more thoroughly.
This is what we call being more “data-driven.” So, what can we do to become more data-driven?
Let’s break it down:
Ask for supporting data
In the first example, your PM said sign-ups have decreased. But by how much? What were the previous numbers? What are they now? When was this data collected—last month, this month, or this week? Ask for clarity around the data.
If you’re lucky, the PM might provide this data. But sometimes, you get a task without any clear foundation. In this case, you can push back, asking, “Is this task really important?” “What happens if we don’t do it?” “Are there other, more urgent tasks?”
Question the relevance of the data and the problem
Once you have the data, you can start questioning the relevance between the data and the problem. Does the data support the problem they’re claiming?
For example, if sign-ups are down, does it make sense that it’s because the onboarding flow is bad? Or could there be another factor? Maybe the issue is with a different part of the flow.
From here, you’ll start to get a bigger picture of the problem. And you’ll understand why this data supports the issue you’re working on.
Data doesn’t always directly say, “This flow is bad” or “this flow is good.” Think of data as a signal that “okay, there’s a problem here,” but where exactly the problem is, you’ll need to dig deeper—either by finding more data or doing additional research. This helps build a stronger logical foundation.
Ask what the success metrics are
Finally, ask what the end goal is. What are we trying to improve? The target will significantly affect your design—what components to focus on and which information to highlight.
If there are no success metrics, you can meet with the PM to define them. Success metrics will also help you evaluate your design’s performance later.
So, that’s a little insight into how we can become more data-driven. I’m still learning how to do this myself and practice applying it to my work.
If anyone has additional insights, feel free to share.
Thank you 😀
Using data doesn’t guarantee your design is right,
but it’s even riskier if you have no data.