Your design is not the final product

What changes when design meets real implementation

These are the outcomes from a recent testing session:

“Reduce the font size from 19px to 14px.”
“Adjust the spacing between the button and text.”

We see comments like these almost every time we do QA. They are not taught in bootcamps or design courses, but they show up every single time.

Implementation issues can slow time to market and prove harmful to the business. But UI bugs are not the only cause of implementation problems how feasible your design or solution is, can also be a significant challenge for engineers. Feasibility and pixel-perfect implementation are the two main sources of tension between designers and developers.

That tension often stems from two things: communication and process.

Communication

Communication is the bedrock of everything and it goes beyond meetings and calls. Good communication means how you hand off designs, how you document changes, and how you maintain changelogs.

A common example of poor communication is when a design that has already been approved and handed off needs to change. Sometimes a flow or component shifts mid-development. What most designers do is make the change directly on the original handed-off file rather than duplicating it and creating a new versioned file. This causes confusion and delays.

These are all forms of communication. When we get them wrong, it always comes back to hurt the team.

Process

Most teams work in silos, and that creates chaos during implementation. I try as much as possible to include the engineering team whenever I am thinking through a problem it gives me a clearer understanding of what to build, how long it will take, and what it will cost.

One way to do this is a mini-workshop where you walk engineers through your proposed solutions and discuss the cost of building each one. Many designers avoid this because they fear the engineering team will dictate what gets built. But when there is shared understanding and a clear outline of the impact, there is almost always a middle ground.

The Mindset Shift

Before I start designing any solution, I think through five things: usability, feasibility, viability, shared understanding, and impact. These are my pillars whenever I pick up a problem. In this article, I want to focus on two of them: feasibility and shared understanding.

Feasibility

When thinking about feasibility, I always factor in three constants:

Time to build (TTB): How long will it take to build this solution?
Customer goal: What do we want the customer to achieve?
Outcome: What does success look like?

These three constants drive me to have honest, open conversations with the engineers I work with. They also keep everyone grounded when it comes to stripping a feature down to its essentials. The TTB constant in particular varies depending on the scope of a project and shapes how the conversation with the engineering team unfolds.

Shared Understanding

I always want to be fully aligned with the engineering team so that everyone has a clear understanding of what needs to be achieved. This alignment drives how I hand off, what I prototype, and how I annotate.

A concrete example of how I build shared understanding is through how I manage changelogs for already handed-off designs. When a change is needed, I duplicate the file and create a new versioned copy rather than editing the original. I then communicate the changes to the developers, share the updated design, and annotate exactly what changed — without deleting the previous version. This keeps the team aligned and in sync throughout development.

More good, less evil

We cannot eliminate all the bad in this world, and the same applies to implementation. We cannot achieve 100% perfection — but we can aim for fewer imperfections. That is the goal.

Your design is not the final product was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.