One topic that comes up often when I sit down with designers, whether junior or senior, is collaborating with engineers. It doesn’t matter if I’m talking with designers from Montreal, Toronto, Amsterdam or Seattle based. Designers always have strong opinions about this relationship.
Usually, everyone gets along fine on the surface. But when you start a project together, things can get tense. Designers complain engineers aren’t following their guidance or are building things without checking with them when steps are missing. Engineers complain designers hand over features that aren’t feasible or clear. Or even consult them on these ideas. Honestly I’ve been there myself, I have heard it all since the start of my career.
Over time, I learned a simple mindset shift that changed everything: treat your engineers as a core user of your design process. They are trying to use your work to build a product. If they’re frustrated, that’s a sign of friction you can fix.
Here’s how I approach collaborating with engineers. This process has saved me time, prevented late-stage surprises and built stronger trust with my teams.
1. Start with an open conversation
When I join a new team, I schedule time with each role to walk through:
- How I work: I over-communicate rather than leave assumptions. I show what tools I use to share progress and what they can expect by the time we get to handover. I walk them through my Figma template structure. (Small brag, but there is always a “wow” factor from them)
- How they work: I ask how they prefer to receive designs, which channels they like for questions, what they enjoy the most during projects and what has annoyed them in past projects.
- What success looks like: We talk about what makes their job easier and what has caused problems before. How they prefer to collaborate in general.
I listen carefully, I leave my ego as a designer outside of the conversation, take notes and show empathy for any past frustrations. We then agree on ways to avoid those issues together.
2. Keep everyone informed throughout
Throughout the project, I make sure all roles know what’s happening, trandparency and communication is crucial:
I know, engineers are always the one that are most often the quiet ones or complaining they have better things to do, but…
- Regular check-ins: Meetings are the best way to align, even if there’s not much to share from their end and just show up to stay aware.
- Written updates: If someone can’t attend, I send a summary email with decisions, progress and blockers to everyone.
This prevents surprises. If engineers know what’s coming, they can still raise concerns early.
3. Do a post-launch retrospective
After launch, I set up a one-on-one with the engineer(s) to review:
- Did the handover meet expectations?
- What worked well?
- What could improve next time?
Most teams do retros as a group, but a private conversation helps you get more candid feedback if the engineer isn’t much of a public speaker. This is how I’ve kept refining my process over the years and my Figma template.
4. Use a structured Figma template
One tool that consistently helps is my Figma file template. Here’s what I include:
| Page | Purpose |
|---|---|
| Cover page | Clear title, team members, date. Helps anyone opening the file know what it is. |
| Project overview | What, Why, Who: goals, stakeholders, hypotheses, UX outcomes, scope, risks. Links to related docs. |
| Current state audit | Screenshots of existing features, success and error states. Comments on what works and what doesn’t. |
| Meeting notes | A space to store important files and notes so nothing gets lost in Drive. |
| Design exploration | I make sure everyone understand that they cannot leave any reviews on this page, they should in general not be looking at this page. This is where I has a designer should be allowed to explore all the ideas and potential solutions. |
| Team discussion review + feedback | This page is to allow you to place a few mocks, or userflows to have it reviewed by the team during a design critiques. They in general should be asking questions or leaving a lot of stickie notes with their feedback. |
| Spec sheets | One page per feature. Each includes user flows, default and error states, annotations, and rationale. Engineers can link these directly to Jira tickets. |
Why this works
Breaking down each feature onto its own page avoids confusion. Engineers most often work with Jira to keep track of their accomplishments and progress of the project, so they prefer to include a single link for each Jira ticket being created instead of digging through a massive Figma file with everything. Making sure clear annotations answer most of their questions before they have to ask. Your spec-sheet need to walk them through the user journey, not just have pretty images.
Those specsheets need to offer, the default view, the success or error phases, if your project is available in a different language, include a sample of it also, just to make sure the engineer understands if something shifts and how the design will adapt. Keep your desktop and mobile views together if that is how your engineer prefers to work.
Since adopting this approach, I rarely get last-minute pushback or repeated clarifications. The transparency and structure make delivery smoother and it also helps leadership and product managers aware of the deliverable.
Final thoughts
Collaborating with engineers doesn’t have to feel like a battle. If you treat them as a key user of your process, you’ll see fewer frustrations and better outcomes.
If you’d like a discuss further of my Figma template or want to share your own methods, I’m always interested in learning what works for other teams.