There is a moment in almost every project where things feel calm. The screens look right. The flow connects. The prototype behaves exactly the way you imagined.

Inside Figma, everything feels reasonable.

You zoom in, adjust spacing, rename components, and polish details. You replay the flow again and again until it feels obvious. At that point, it is easy to believe the hard part is done.

Most of the time, it is not.

The first real reaction hurts more than bugs

Two people reviewing a screen together in a pencil illustration

The real shock rarely comes from developers or technical limits. It comes from users.

You sit with someone and walk them through the flow. You explain the idea, the screens, the logic. They look at it, not as an outsider, but as someone who actually lives inside that process.

“This actually works differently.”

And then they start explaining why. They show background steps, small decisions, workarounds, and dependencies that never appeared in the first conversations. Things that happen before or after the flow you designed. Things the client or the people who presented the process did not fully see or did not think to mention.

That moment hits hard. Not because the design is bad, but because it reveals how incomplete the picture was.

When this happens during user testing, it is often a sign that you are on the right path. It means the gaps are showing up early, while you are still designing and can change direction without heavy cost.

Finding these problems at this stage is not failure. It is timing. It is far better to rethink a flow in design than to discover the same issues once everything is already built, where every change hurts more and moves slower.

Designing from borrowed truth

Two people discussing a process in a green pencil illustration

Many flows start with someone else’s version of reality. A client explains how things work. A stakeholder shares a vision. A document describes a process.

You design based on that input. You connect ideas. You make decisions that feel logical.

But that truth is borrowed. It is filtered by pressure, responsibility, and distance from daily use. Clients handle money, contracts, teams, and timing. They are close to the product, but not always close to every detail of how people actually use it.

This does not mean they are wrong. It means they see the product from a different place.

When a flow collapses in five minutes

A person facing a large diagram of connected screens

There have been moments where a single conversation changed everything. A flow that took days to design suddenly felt heavy. A step that seemed necessary was ignored. A feature that looked important was skipped without hesitation.

Sometimes the opposite happens. A tiny detail you barely considered turns out to matter a lot. Something niche, repetitive, or annoying becomes central to the experience.

These moments are uncomfortable, but they are also a gift. They show you the gap between how things are imagined and how things actually work.

Most of the time, this gap is not about fault. Not the user’s, not the client’s, and not even the designer’s. Sometimes no one saw it coming. The stakeholder did not catch it. The user did not mention it earlier. The design did not surface it. And that is part of building real products.

This happens often in MVPs, early prototypes, and first production releases. You make a decision with the best information you have, and later you learn it was incomplete. That does not make it a mistake you should hide. It makes it a moment to react.

What matters is how fast you adapt. Making changes while things are still flexible. Keeping interfaces simple enough to move, adjust, and grow. That ability to react has saved more projects for me than any “perfect” first decision.

The cost of learning too late

A person between interface wireframes and a network of colored connections

Changing a flow while designing is painful. Changing it while building is worse.

There is a big difference between rethinking screens and reworking logic, code, and timelines. The later you learn, the more expensive the mistake becomes.

That is why early conversations matter so much. Not as a formal step, but as a way to break assumptions before they turn into decisions that are hard to undo.

Clients, users, and the moving train

People sharing a train carriage in a pencil illustration

Product work rarely moves in a straight line. It feels more like a train with many people inside. Designers, developers, clients, managers, and users are all moving together, each with their own priorities.

Sometimes users are close. Sometimes they are distant. Sometimes no one has talked to them in a while.

As a designer, you end up standing in the middle, translating, adjusting, and rethinking constantly.

You have to take decisions while holding many ideas, opinions, and realities at the same time. You try to find the best possible direction knowing it will rarely be the prettiest one. That happens more often than people admit.

There are moments where you need to stop polishing and stop forcing things to look right at first glance. What looks good on a screen does not always work with technical limits, old user habits, or the need to adapt over time.

Every decision costs time, and most of them cost money. That is why choosing your battles matters. Sometimes you need to stay flexible and adjust. Other times you need to be firm and move forward with a decision. Learning when to do each has been one of the hardest parts of the work for me.

Figma is where things look right. Real users are where things break, adjust, and slowly find their place.

Two notebooks showing different interface sketches