The Design Was Approved. So What Happened in Development?

There is a particular kind of pain that comes with being a product designer who enjoys working with developers.

And no, it is not because I hate developers. Quite the opposite. I genuinely enjoy working with them. I like understanding how they think, discussing what is technically possible, figuring out how a design can move from Figma into a working product, and finding that sweet spot where a good user experience meets a practical implementation.

But sometimes, somewhere between “This looks good!” and “The feature is ready for review,” something happens.

And suddenly, I am looking at a product I do not recognize.

Let me tell you a story.

Imagine I am working on a new dashboard for a digital product. Let's call it Project Nova.

The team has been discussing the problem for weeks. We have spoken about the users, their frustrations, what they need to accomplish, and why the current experience is not working as it should.

I take all those conversations, the requirements, the user flows, the edge cases, and the feedback, and I get to work.

I map out the journey. I think about the information hierarchy. I consider what the user should see first, what actions should be obvious, what happens when there is no data, what happens when a request fails, and what happens when the user makes a mistake.

I design the screens. I connect the flows. I define the components. I think about spacing, typography, colors, states, interactions, and all those little details that can seem insignificant until someone actually tries to use the product.

Eventually, I present the design to the team.

We have our review meeting.

The product manager looks through the screens.

“This is nice.”

One of the developers nods. “I like it. This should solve the problem.”

Another teammate adds, “The flow makes sense. Let's move forward.”

We discuss a few details, make some adjustments, and agree on what needs to be done.

I leave that meeting feeling good. Not because everyone praised my work, but because we have aligned on the problem and agreed on a direction.

The design has been reviewed. The team understands the intention. We are ready to build.

Or so I think.

A few days later, the developer sends a message.

“Feature is ready. You can check it out.”

I open the application.

I stare at the screen.

I refresh the page.

I stare again.

Wait. What am I looking at?

The layout is different. The carefully structured sections have been rearranged. A component I designed to make an important action obvious has disappeared. The original interaction has been replaced with something else. The empty state I created to guide first-time users is now just a blank space.

And the button?

Well, the button is there. Technically.

But it is in a different place, has a different style, and behaves differently from what we agreed on.

I open Figma in another tab.

I switch back to the application.

Figma.

Application.

Figma.

Application.

At this point, I am beginning to wonder whether I opened the wrong project.

So I message the developer.

“Hey, I noticed a few differences between the implementation and the approved design. Can we look at them together?”

The response comes quickly.

“Oh, yeah. Some parts were a bit complicated to implement, so I simplified them.”

Simplified.

That word.

Sometimes, simplification is exactly what a product needs. I am not against it. In fact, good design often involves removing unnecessary complexity.

But there is a difference between simplifying a design decision and silently replacing it with a different decision.

I ask about the missing interaction.

“Oh, that one? I thought it was too much. The current approach is easier.”

I ask about the changed layout.

“The original one was taking too much time to implement.”

I ask about the empty state.

“Oh, I didn't think we needed all that. We can just leave it blank for now.”

And just like that, the design decisions we discussed as a team have become optional suggestions.

Now, I understand that development comes with constraints. Sometimes a component is more difficult to build than expected. Sometimes a library does not support the interaction we imagined. Sometimes the timeline is tight, the API behaves differently from what we anticipated, or the original approach introduces a technical problem nobody noticed during design.

These are real things. I know that.

I do not expect a developer to magically implement every pixel without asking questions. I do not expect every design decision to survive contact with reality unchanged.

What I expect is a conversation.

If something is difficult, tell me.

If an interaction will take longer than expected, let's discuss it.

If the design is not technically feasible, let's explore alternatives.

If you have a better solution, show me.

I might even agree with you.

But please, do not quietly make a different product and assume we will figure it out during the next review.

Because the next review is where the real drama begins.

We gather again as a team.

The product manager opens the feature on the shared screen.

There is a brief silence.

Then someone asks, “Is this the design we approved?”

Another person says, “I thought the user was supposed to be able to do this in one step.”

Someone else looks at me.

“Why did we design it this way if it was going to look like this?”

And now I am sitting there trying to explain a design that is no longer the design being reviewed.

I open Figma and begin comparing the original screens with the implementation.

“This was the approved flow. This interaction was part of the design. This component was included because users need to understand what happens next. We discussed this during the last meeting.”

Then someone says, “But the design looked good when you presented it.”

Exactly.

It did.

Because that is the design we reviewed.

Now we are reviewing a different implementation, and somehow, the conversation is beginning to sound like a design-performance review.

Was the designer not clear enough?

Was the design too complicated?

Did I fail to consider the developers?

Should I have designed something simpler?

And before we know it, we are discussing whether the design was good enough instead of asking the more immediate question:

What happened between the approved design and the implemented feature?

That is the part that frustrates me the most.

Not that something changed. Things change all the time when we build products.

Not that a developer suggested a different approach. I welcome that.

It is the fact that the team can approve one solution, implement another, and then evaluate the designer as though nothing changed in between.

It is like agreeing on a recipe, deciding together what the meal should be, then changing half the ingredients in the kitchen and wondering why the final dish tastes different.

And the person who wrote the original recipe is suddenly being asked what went wrong.

Now, let me be fair for a moment.

Designers can make this difficult too.

Sometimes, I can get carried away with the details. I can spend hours refining an interaction without fully considering the effort required to implement it. I can create a beautiful flow without understanding a technical limitation. I can assume that because something makes sense in a prototype, it will be straightforward in code.

And sometimes, developers look at a design and genuinely see a problem that I have missed.

That is why collaboration matters.

The solution is not for designers to dictate every decision or for developers to implement everything blindly. It is not for developers to ignore the design because they believe their approach is better, either.

It is for both sides to understand that we are working towards the same goal: a product that works, solves the right problem, and makes sense to the person using it.

I bring my understanding of the user, the experience, the interactions, the visual hierarchy, and the problem we are trying to solve.

The developer brings their understanding of architecture, code, technical constraints, performance, and implementation.

Neither perspective is enough on its own.

And when a design decision needs to change, we should be able to discuss it without turning the conversation into a competition over who understands the product better.

Here is what I wish every team would remember.

An approved design is not a decoration. It is an agreed direction for solving a problem.

It should not be treated as an untouchable document, but it should not be treated as a random suggestion either.

If a developer needs to change something, communicate it.

If a designer has made something unnecessarily complex, explain why.

If a component takes too long to build, explore a simpler alternative together.

If the implementation differs from the design, document the difference and make sure the team understands the trade-off.

And when we get to the review meeting, let us compare what was built against what was agreed, understand why the differences exist, and decide together whether those changes still solve the original problem.

Because the goal is not to prove that the designer was right.

The goal is not to prove that the developer can build it their own way.

The goal is to make something good enough to deserve the user's trust.

I want to work with developers who challenge my decisions when necessary. I want developers who can tell me that something will not work and help me find a better solution. I want to understand their world just as much as I want them to understand mine.

And I want that same energy in return.

I am not asking for pixel perfection at the expense of a functional product.

I am asking for communication, shared responsibility, and respect for the thinking that goes into both design and development.

Because sometimes, the design is not the problem.

Sometimes, the problem is that we agreed on one thing, built another, and forgot to talk about the difference.

And the next time a team says, “The design looked good, but the implementation doesn't feel right,” I hope we pause long enough to ask:

Did we actually build the design we approved, or did we build the version we assumed would be easier?

That question alone could save teams a lot of unnecessary meetings, rework, frustration, and finger-pointing.

And perhaps, just perhaps, it could help us build better products together.

For the designers and developers reading this: Have you ever experienced that awkward moment when the approved design and the final implementation look like distant cousins? 😅

I'd love to hear how your team handles those conversations. Do you review designs together during development, or does the first real comparison happen at the end?

#ProductDesign #UXDesign #SoftwareDevelopment #DesignSystems #TeamCollaboration