Data Shows You Where to Look

Data is one of the best tools a team has. It reveals patterns, exposes blind spots, and challenges assumptions that would otherwise go unquestioned.

But data rarely arrives with the full explanation attached.

A metric can tell you that users are dropping off. It cannot always tell you whether they are confused, unconvinced, distracted, overwhelmed, or simply not the right users in the first place.

That distinction matters.

The mistake is not trusting data. The mistake is stopping too early with it.

In product design, the most useful question is often not "what does the data say?" It is "what do we need to understand now that we have seen this?"

Data needs interpretation

Every team wants to be data-driven. I think that instinct is right. The problem is that "data-driven" can sometimes become a shortcut for avoiding judgment.

A number feels clean. It feels objective. It gives the room something concrete to react to.

But a number is not the full story. It is a signal from a larger system.

If conversion drops, something changed. But what? The page might be unclear. The offer might be weak. The user might not trust the product yet. The wrong audience might be entering the flow. Or the metric might be capturing the wrong moment entirely.

The data tells you where to look.

It does not do the looking for you.

Three ways teams misread data

One: they mistake movement for meaning.

An A/B test can tell you which version performed better. It cannot always tell you whether either version solved the real problem.

I have seen teams spend weeks improving a small interaction while the larger flow around it remained unclear, slow, or misaligned with what users actually needed.

The number improved, but the experience did not meaningfully change.

That is the risk. You can make a metric move without making the product better.

Two: they favor what shows up quickly.

Some outcomes are easy to measure. Others take time.

Revenue may respond in days. Click-through rates may respond in hours. But trust, comprehension, confidence, retention, and behavior change often take much longer to appear.

When teams only follow the fastest signal, they can end up optimizing for what is easiest to prove instead of what is most important to improve.

That does not mean slow signals are more valuable by default. It means speed should not be confused with importance.

Three: they confuse the dashboard with the experience.

Metrics are a representation of behavior, not the behavior itself.

At some point, you still have to open the product. You still have to watch someone use it. You still have to understand the moment they are actually in.

"The cohort dropped by 12%" is useful.

But it is not the same as knowing why a real person hesitated, gave up, or made the wrong decision.

A dashboard can show the pattern. Design has to understand the moment behind it.

A number can point to a problem. It cannot always explain the human moment behind it.

How I use data in practice

Before I design, I use data to find the shape of the problem.

Where are people slowing down? Where do they abandon the flow? Which fields get edited repeatedly? Which actions take longer than expected? Which paths look efficient on paper but create hesitation in practice?

That gives me direction.

It does not give me the answer.

During design, I bring the data into a more specific context. I look at real users, real workflows, and real moments of decision.

Averages are useful, but nobody experiences a product as an average. People experience products as one person, in one situation, trying to get something done.

That is especially important in complex products. Clinical workflows, financial models, operational dashboards, and decision-heavy tools are full of moments where the "right" design is not just the one that increases a click rate. It is the one that helps someone understand what is happening, trust what they are seeing, and act with confidence.

After shipping, data becomes essential again.

I look at whether the change moved the metric we expected. But I also look for the things we did not expect.

Did we reduce friction in one area but create confusion somewhere else? Did users complete the task faster but make more mistakes? Did a cleaner interface improve usability for new users but remove context that experienced users relied on?

The unexpected movement is often where the real learning happens.

The harder skill

The harder skill is not reading the dashboard.

It is knowing how to interpret disagreement.

Sometimes the metric is right and your assumption was wrong. Sometimes the metric is measuring the wrong thing. Sometimes the design is better, but the measurement window is too short. Sometimes users need time to adapt. Sometimes your favorite idea simply did not work.

There is no perfect rule for knowing which one is true.

That is why good product work requires both evidence and judgment.

Data gives you the signal. Research gives you context. Design turns both into a decision.

The goal is not to obey the number or ignore it.

The goal is to understand it well enough to act responsibly.

— Victor