The 1:10:100 Rule in UX: Why Catching Design Mistakes Early Saves Millions

Here's something every designer learns the hard way. If you find a mistake early, it's cheap to fix. If you find it late, it gets expensive. Really expensive. There's actually a name for this: the 1:10:100 rule.

Say you're working on a checkout screen in Figma. One of the button labels is confusing, and you notice it while testing the prototype. You change a few words and you're done in five minutes.

Now picture finding that same problem after launch. You'd be dealing with support tickets, people leaving without buying, a quick fix and a new release. Same mistake, very different bill.

So what is the rule?

The rule breaks the cost of a mistake into three stages. Each stage costs about ten times more than the one before it.

Prevention is stopping the mistake before it happens. Think clear requirements or a good design review. Correction is when the mistake gets in, but you catch it before users see it. Failure is when it slips through and reaches customers. At that point you're paying with their trust, your time and real money.

Where it comes from

George Labovitz and Yu Sang Chang made this idea popular around 1992, in their work on quality management. Their example was about data. Checking a record when you enter it costs almost nothing. Fixing it later costs more. And making business decisions based on bad data costs the most.

Since then, people in manufacturing, software and UX have picked it up, because it holds true pretty much everywhere.

How it looks in product design

For us, the three stages are design, development and after launch. The reason the cost keeps going up is pretty simple. The longer a mistake sticks around, the more people and code end up tied to it.

In design, the mistake lives in one frame. In development, it's mixed in with code, tests and other features. After launch, real users run into it, the support team has to deal with it, and it can hurt sales.

How to use it

The idea is to catch problems as early as you can, ideally before anyone writes code. As a designer, you already control most of the places where that can happen: talking to users during research, checking your work against the design system and for accessibility in design reviews, running quick usability tests on a prototype, and sitting down with developers early so the specs and edge cases are clear.

This rule also comes in handy when you need to ask for time to do research or testing. A week of testing can sound like a lot. But put it next to redoing a feature after launch and it suddenly looks cheap.

One thing to keep in mind

Don't take 1, 10 and 100 literally. Nobody measured these exact numbers. On your project it might be 5x, or it might be 50x. What matters is the idea behind it: the cost doesn't just go up a little at each step, it jumps.

So when you bring this up with your team or clients, share it as a way of thinking, not as hard data.

Wrapping up

Research, prototyping and testing aren't extra work. They're the cheapest way to avoid big problems later. So next time someone asks why you're spending so much time on testing, tell them about the 1:10:100 rule. A dollar spent now can save you a hundred later.