Friction between design and engineering is often treated as something inevitable. Some of it is — they are different disciplines, bringing different concerns, constraints, and perspectives on the same problem. A large amount of the friction teams experience, however, is not inherent. It is caused by the way work is framed, when conversations happen and what is left unclear.
I spent 9 years in development, before I moved into design, so this is something I have experienced from both sides. Most design x engineering friction is not really about seniority. It is a mix of pressure, unclear context and the tendency people often have to protect their work, among other factors.
That is part of why even fairly obvious things often get overlooked.
This matters even more now, that AI is making multidisciplinary work easier. Designers can explore technical implications earlier, engineers can engage more directly with UX and product decisions. They are still different roles, but the walls between them are getting thinner as we speak.
That raises the value of shared judgement over isolated craft, and makes friction caused by rigid role boundaries harder to justify.
Here are seven ways to reduce that friction, from someone who has been, and continues to live on both sides. In real projects, those get missed more often than you’d think.
1. Start with the problem, not the UI / solution
One of the fastest ways to produce friction is to start the conversation with a ready solution.
People often react to the output, before they have taken a chance to understand the problem it is trying to solve.
Start earlier.
What is not working?
What are we trying to improve?
What needs to be true for this to be considered a better outcome?
AI makes it easier than ever to generate screens, mockups and variations quickly. Having that speed is invaluable, but it can create the illusion of clarity before the team has aligned on the actual problem. Faster output does not remove the need for clear framing.
2. Bring engineering in before the design feels done
Timing matters.
If engineering is only brough in once the design looks polished and settled, feedback immediately feels more threatening, questions sound like pushback. Designers feel like their work is being pulled apart, while engineers get the sense they are being asked to react to decisions that have already been made.
That is not collaboration — it is late-stage collision.
(Note: I’ve got a whole story on that, and how I improved it, coming soon.)
The best conversations take place before the work has taken its final form, while it is still open enough to be shaped by both sides.
With AI heavily involved in our workflows now, it is so easy to mistake speed for readiness and have a team lock themselves into a direction.
3. Surface constraints early
Ignoring constraints can ruin great work in the blink of an eye.
Technical limitations, dependencies, legacy systems, platform specifics, delivery pressure, scope, sequencing. These things are shaping the work whether teams name them or not.
The more visible they are early on, the less friction they create later in a project.
A ton of avoidable tension comes from treating constraints as “bad news”, instead of shared context. If design and engineering are operating on different versions of reality, they are bound to clash at some point.
Synchronising those realities is what builds stronger products.
4. Be clear on what is fixed and what is flexible
Not every part of a design carries the same weight and value. When this has not been made explicit, everything gets debated at the same level.
This is where conversations start to drag.
A design is a mix of preference, expertise, opinion, actual solutions, placeholders and optional bits. If engineering is not clear on which is which, they cannot respond adequately. If everything is treated as equally important, designers might get defensive, feeling their entire work is being attacked.
Clarity makes a huge difference.
What is critical?
What can flex?
What is still open to a better solution?
Involving AI into the workflow makes this even more crucial. Being able to generate more options, quicker, the volume of possible directions grows exponentially. Clear prioritisation is more important than ever.
5. Do not mistake technical challenges for resistance
Another obvious one?
You’d be surprised how often friction starts with misreading the conversation.
Engineering raising concerns is not the same as rejecting the idea. In fact, it is likely a situation where they are trying to expose risks, complexity, fragility, hidden cost… If that gets interpreted as unwillingness, the conversation turns defensive, quickly.
Defensiveness is human, we get attached to our work, especially when producing under pressure. Add deadlines, team dynamics and stress to that list and it becomes even easier for a challenge to feel personal, when it is not.
That said, not every concern should “win”, but it is almost always worth hearing and considering.
6. Ask meaningful questions
My personal favourite:
“Is this possible?”
I have found myself stunned by that question on so many occasions. Yes, everything is possible, one way or another — the sky is the limit!
Better questions are the ones that open up the problem, instead of boiling it down to “possibility”. Try:
What is the cleanest way to approach this?
Where are the risks?
What gets harder if we do it this way?
Is there a simpler version that still solves the problem?
Enabling shared thinking via this type of questions will eliminate more friction than polished handoffs ever will. I promise!
7. Treat engineering as part of product thinking, not just delivery
If you had to adopt just one of the 7 listed in this article, please, let it be this one.
If engineering is only brough in to validate, estimate or implement, the relationship and the whole process stays transactional, the conversation remains narrow. The team not only misses out on some great input, but risks ignoring constraints and creating the need for re-do’s, that might have been completely avoidable.
Spotting structural issues, downstream risks, simpler alternative paths and hidden complexity, early on, is often engineering’s special talent. They are not sense-checking the design, they are simply looking at the product from another essential angle.
The less engineering is treated as a delivery unit, the less friction the team creates for itself.
When the conversation evolves from handoff to shaping the right solution together, we are looking at better outputs, in the form of stronger products.
Final thought
You can’t just tell people to “collaborate better”.
You reduce friction by improving the conditions around the work: clearer problem framing, earlier involvement, visible constraints, better questions and more honest conversations about trade-offs.
Strong teams are not friction-free, because they agree all the time. They become friction-light, by reducing or eliminating poor timing, weak context, unclear priorities and role-based distance.
This matters more than ever right now, as the excuse to stay trapped within a discipline is weakening every day, with every new AI agent out there. As cross-domain thinking becomes more achievable, the teams that will stand out will be the ones who manage to build the strongest shared judgement.
Less friction does not just make teamwork easier — it leads to better decisions, better execution and more stable products over time.
