Beautiful and Wrong

There's a seductive trap in product design that catches even experienced teams: opening Figma before opening your mouth.

You get a brief. Maybe a Slack message. Maybe a half-baked ticket. And because making things look and feel right is your job, you start designing. You pick up the pen before you understand the problem. The result is a beautifully crafted solution to a question nobody asked.

I've watched this happen for over a decade. I've done it myself. The cost is always the same: wasted sprints, confused engineers, features that ship and sit there collecting dust.

The pixel-perfect illusion

Here's what makes this failure mode so dangerous — it looks like progress.

A polished mockup in a stakeholder review creates confidence. People nod. They say “this looks great.” And they mean it. It does look great. But looking great and being right are two completely different things.

High-fidelity designs anchor conversations to surface-level feedback. People debate button placement and color choices instead of asking whether the feature should exist at all. The fidelity becomes a shield against the hard questions.

I've sat in reviews where a trader looked at a beautifully designed feature and said, “I would never use this.” Not because the design was bad. Because the premise was wrong.

Why teams skip the hard part

Jumping to design isn't laziness. It's usually one of three things.

It's comfortable. Designers design. That's our identity. Sitting in ambiguity and pushing back on assumptions doesn't feel like “doing your job.” But it is the job.

Organizations reward visible output. Nobody gets praised in a standup for saying “I think we're solving the wrong problem.” They get praised for showing screens.

The upstream work is often broken. Requirements come in half-formed. Strategy is unclear. Business context is locked in a meeting you weren't invited to. So you fill the gaps with assumptions and pixels, because waiting feels like standing still.

What actually needs to happen first

You need to understand the problem from the user's perspective, not from a product manager's summary of it. There's a difference between “users need better filtering” and watching someone cross-reference three spreadsheets because the filters don't map to how they think.

You need to know what success looks like in terms that aren't “we shipped it.” What behavior changes? What metric moves? If nobody can answer that, you're not ready to design.

You need enough context about constraints — technical, business, timeline — to know what's possible. A gorgeous design requiring six months of backend work when you have six weeks isn't a solution. It's a fantasy with a style guide.

Slow down to go fast

The fix isn't a new framework or a mandatory “discovery phase” checkbox. It's a mindset shift.

Before you design, write. Write down the problem in plain language. Write down who has it and why. If you can't articulate the problem without referencing a UI element, you don't understand it yet.

Talk to the people who will use the thing. Directly. Even fifteen minutes with one real user will save you days of rework.

Sketch ugly. Intentionally ugly. The goal isn't visual design — it's exploring logic and structure without the gravitational pull of aesthetics.

Present your thinking before your design. If the room can't align on the problem framing, no amount of design craft will save you.

The real craft

Anyone with taste and tools can make something beautiful. That's table stakes. The real craft is making the right thing — the thing that solves a real problem, fits within real constraints, and actually gets used.

The hard, unglamorous work happens before the first pixel. That's where design actually begins.