The 'MVP' is Often Just an Excuse for Lazy Design

Let me describe a moment you've absolutely lived through.

You've got a gorgeous flow in Figma. Fourteen artboards. Loading states, empty states, error states, the works. You're proud of it. Then someone in the standup says the magic words. "Let's just keep it MVP for now."

And watch how fast you move. You delete the empty states. You strip out the error handling. You hand the dev one pristine happy-path screen, the one where nothing ever goes wrong and the user does exactly what you prayed they'd do. And you call it lean. You call it pragmatic. You feel mature about it.

We love to blame engineers for shipping broken products. But let's be honest with ourselves for a second. Designers are just as guilty of lazy MVPing. We just do it earlier in the process, so the blame lands on someone else by the time it ships.

So let me walk through how we abuse the word, with the full understanding that I've done every single one of these myself.

1. "Viable" Means Viable

Everyone fixates on the word "Minimum" and completely ignores the word "Viable." Both are in there on purpose.

The example people always get backwards is the skateboard. A skateboard is a valid MVP for getting somewhere. A single wheel is not. The wheel is technically more minimal, but you can't ride it. It doesn't solve anything. It just sits there being smaller.

A bicycle with no seat is minimal too. It's also miserable. You can stand and pedal, but nobody asked to suffer. And that's exactly what we do when we strip a flow down to its happy path. We keep deleting until it looks clean in the file, and forget to check whether a real human can actually get through it when their internet drops or they fat-finger the wrong field.

The question isn't "is this the smallest version." The question is "can someone finish the actual task without hitting a wall." If they can, you designed an MVP. If they can't, you designed a demo and let everyone believe it was a product.

2. You're Cutting the Wrong Corners

There are two ways to make a design smaller, and we almost always reach for the lazy one.

Cutting scope means designing fewer things, beautifully. Cutting quality means designing the same flow but skipping all the parts where reality gets messy. The MVP idea was supposed to be the first kind. What we actually do is the second.

Cutting scope looks like this:

• "V1 supports one way to do this, and it's polished end to end"

• "Three templates instead of thirty, but each one is considered"

• "Solo users only for now, no team features, fully thought through"

Cutting quality looks like this:

• "I didn't design the error states, just let the browser throw its default popup"

• "Empty state? It's fine, it'll just be blank until they add something"

• "If the upload fails I didn't really design for that, dev can figure it out"

The first list is a focused product. The second list is you outsourcing your hardest design decisions to a tired engineer at 5pm who will absolutely default to the ugliest possible fallback. The error state is not the optional part of the design. It's the part that decides whether people trust your product when something goes wrong, which is exactly when they're paying the most attention.

3. The "V2 Figma File" Lie

Be honest. You have one. We all have one.

A pristine, lovingly crafted file called something like Feature_V2_Final sitting in your drafts. Every empty state designed. Every edge case handled. The beautiful onboarding you couldn't fit into V1. You swear it's getting built next quarter.

It is not getting built next quarter. That file is a graveyard of good intentions, and you visit it occasionally to feel something.

Here's why it never ships. The second V1 goes out, you get pulled onto the MVP for the next feature. Then the one after that. Your gorgeous V2 file just sits there collecting digital dust while the rushed V1 you're embarrassed by quietly becomes the permanent version. The "temporary" compromise outlives everyone's memory of it being temporary.

If you actually mean to ship V2, get it out of your drafts and into reality:

• Put the missing states in the backlog as real tickets, not a private Figma file only you know exists.

• Tie them to a priority, so they compete for real engineering time.

• Flag the gaps to your PM out loud, so the debt is visible instead of hiding in your account.

A documented gap is a plan. A beautiful V2 file nobody else can see is just a comfort blanket.

4. Debt by Design

This is the one I have to own the hardest, because designers do this constantly without noticing.

Sometimes we design a flow that looks complete in the prototype, but the final critical step doesn't really exist. The user fills everything out, hits the end, and then has to email support, or wait for someone to do it manually on the backend, or repeat half the process in a different tool. The Figma file looked finished. The actual experience has a hole in it that a human has to climb out of.

If your design only works because a support agent is quietly finishing the job for every user, you didn't design a product. You designed a beautiful front door to a ticket queue.

There's a fair version of this and a lazy version, and the gap between them is intent.

The fair version is a deliberate concierge approach. You knowingly handle the back half manually to test whether anyone even wants the thing before you invest in designing the full automated flow. That's a real, smart strategy.

The lazy version is designing up to the fun part, leaving the unglamorous completion step undesigned, and assuming someone downstream will absorb the mess. One is an experiment you chose. The other is you avoiding the boring 20% of the design because the pretty 80% was more fun to make.

5. The User Decides What's Viable, Not Your Deadline

Here's the part we forget while we're busy deleting artboards. You don't get to decide your design is viable. Your user does.

Viability has nothing to do with whether you cleared the sprint. It's whether a real person can open your product, do the thing they came to do, and leave thinking "that worked" instead of "what happened there."

So before you strip a flow down to its bones and call it lean, run it through one honest question. If this happy-path screen were the only version that ever existed, and the V2 file in your drafts was never going to be built, would you still be proud to put your name on it?

If yes, ship it. If your answer is "well, once we add the error states and the empty states and fix that one dead end," then congratulations, you didn't design an MVP. You designed an unfinished product wearing an MVP costume, and your users are going to see the seams immediately.

MVP is one of the best ideas in product and one of the most abused, and designers abuse it just as enthusiastically as anyone. Used well, it keeps us focused and stops us over-designing things nobody wants. Used as an excuse, it becomes permission to skip the hard, unglamorous parts and let someone else deal with the fallout.

The fix isn't designing more screens. It's being honest about the two words we agreed to.

Make it minimal by cutting scope, not by deleting every state that isn't the happy path. Make it viable by checking that a real person can finish the task without falling into a hole you chose not to design. Get your V2 dreams out of your drafts and into a real backlog. And stop designing front doors to ticket queues.

Lean is a discipline. Lazy is just lean with better PR. We know which one we're shipping. We just don't always admit it.