How to Make Design Decisions When There's No Data

There's a version of data-informed design culture that's become a crutch. "We can't decide without data" can mean genuinely appropriate rigour, or it can mean nobody wants to make a call and data is a convenient excuse to wait.

Most design decisions have to be made without the exact data you'd want. The product is new. The user base is too small. The test is too expensive to run. The deadline is tomorrow.

Here's how to make good decisions in those conditions.

Acknowledge that all decisions have uncertainty

The framing of "we don't have data" can imply that a version of the decision exists that would be free of uncertainty if only you had the right information. That's rarely true.

Even with data, you're making a bet. You're choosing an intervention and hoping the outcome goes the direction you expect. Data reduces uncertainty, it doesn't eliminate it. Once you accept that, the question becomes how to reduce uncertainty as much as possible given what you have, not how to eliminate it before deciding.

Use the data proxies you do have

No data usually means no directly applicable data. But there's almost always something adjacent.

You have mental models from past projects. You have patterns from user research on similar problems. You have established design principles that exist because they've worked reliably across contexts. You have what your competitors are doing, which tells you something about what's been validated in the market.

None of these are the same as your own user data on your own product. But they're better than pure guessing, and they should be treated as evidence, not as substitutes for thinking.

Make the reasoning explicit

When you don't have data, the quality of your decision depends on the quality of your reasoning. So make the reasoning explicit and expose it to scrutiny.

Write down the assumption you're making and why. "I'm assuming users will understand this pattern because it's consistent with how we've handled it elsewhere in the product and because it matches a common mobile pattern" is a testable hypothesis. If it turns out to be wrong, you have a clear record of what you were thinking and can update your model.

This also makes your thinking available to the rest of the team. Someone else might see a flaw in your reasoning that you missed. That's a feature, not a threat.

Optimise for being wrong cheaply

When you're uncertain, structure the decision so that if you're wrong, you find out quickly and the cost is low.

Ship to a small cohort rather than everyone. Build the minimal version of the thing to test the core assumption. Make it easy to roll back. Design for reversibility.

A decision that's easy to reverse deserves less deliberation than one that isn't. If you can test and iterate in two weeks, you don't need to be certain before you start. You need to be willing to learn from what happens.

Trust established principles more in low-data environments

Design principles, things like progressive disclosure, recognition over recall, reducing cognitive load, exist because they've been validated across many products and many users over time. In low-data environments, they become more valuable, not less.

This isn't about following rules blindly. It's about recognising that the accumulated knowledge in established patterns is itself a form of evidence. When you can't run your own test, working with known good principles reduces the chance of making a mistake you could have avoided.

Be honest about what you don't know

The best thing you can do in a decision made without data is to name clearly what you don't know and what you're betting on.

"We're going with this direction. The main assumption we're making is X. We'll know within the first two weeks of release whether that was right, and here's how we'll measure it."

This isn't weakness. It's precision. It keeps the team calibrated about what's known versus assumed, and it creates the conditions for learning when the product ships, rather than everyone being surprised when the assumption turns out to be wrong.