Product Design
Menu

Design Debt: What I Ignore On Purpose

We talk a lot about design debt like it’s something we accidentally inherit.
Past decisions we’re stuck with. Old flows. Rigid layouts.
But the truth is: some of that debt? I chose it.

Not out of carelessness.
Out of clarity.

Design debt isn't always a mistake. Sometimes it's a trade.

In product work — especially when you're working on something large, fast-moving, or complex — you learn pretty quickly that you can’t perfect everything.
You have to prioritize momentum over polish.
Outcomes over obsession.

And that means letting go of certain things, on purpose.

Here's what I often ignore (intentionally):

1. Small inconsistencies that don’t break the flow

I used to obsess over every spacing irregularity. Every misaligned pixel.
Now, if it doesn’t affect comprehension or performance — I let it slide.
I make a note. I fix it when it matters. But I don’t let it block me.

2. Refactoring something that works (but isn’t elegant)

Could this component be more reusable? Probably.
But is it working? Yes.
And is a merchant or end-user suffering because of it? No.

I choose not to over-engineer the system just to feel like it’s “clean.”

3. Designing for every edge case too early

I used to chase every possible “what if.”
Now I ask: is this likely? will this happen at launch? can we handle this with defaults?
Designing for edge cases too early creates bloat.
Sometimes it’s better to learn from usage — and build backwards from real pain.

4. Fixing things no one has experienced yet

Designers are great at seeing friction before users do.
But that’s a double-edged sword — because it also means we fix things that might never happen.

Sometimes I sit with the discomfort of leaving a “maybe problem” alone.
Sometimes we never need to come back to it.

5. Over-documenting early iterations

Early on, not everything needs to be systemized.
If I’m in exploration mode or mid-shift on product direction, I keep the docs light — otherwise I waste time rewriting them every two days.

Why this matters

Design debt isn’t inherently bad.
It only becomes bad when we don’t know why it exists — or when we pretend it doesn’t.

I don’t ignore these things out of laziness.
I ignore them because I’ve learned to respect trade-offs.
Because I value team velocity, product goals, and clarity more than getting everything “just right.”

And when it’s time to clean up — I know where to look.

What I track instead:

  • What slows people down?
  • What confuses the user?
  • What’s hard to maintain?
  • What creates inconsistency at scale?

These are the signals that tell me: okay, now it’s time to pay off that debt.

Until then?
Some debt is fine.
Some debt is the cost of building.

Just make sure it’s a debt you meant to take.