how designers can become better partners for engineers

Yelp’s Product Design team hosts a monthly Lunch & Learn session, and it’s always one of the events I look forward to the most. Topics range from Data Science for Product Designers to Voguing, and recently I had the chance to speak about Design–Engineering Collaboration.

This article is an expanded written version of that talk, with the hope that the ideas reach beyond the Yelp community.

I come from both design and engineering backgrounds. I studied the intersection of design, engineering, and business during both my bachelor’s and master’s programs, and before moving into design, I worked as an application engineer.

Because of that background, design students and junior designers I mentor often ask me the same question:

Should designers learn how to code?

But when you look deeper, the real question usually isn’t about writing production code or building high-fidelity prototypes.

Most of the time, people are really asking:

“How can designers collaborate better with engineers?”

And honestly, that’s the more important question.

My answer is usually this:

Knowing how to code is absolutely helpful for designers. But even without engineering experience, designers can still become outstanding partners for developers if they understand a few core engineering concepts and learn how to collaborate more intentionally.

Here are some practical lessons that have consistently improved my own collaboration with engineering teams — especially frontend engineers, since that’s where designers most frequently work together with developers.

---

Understand the engineering process before trying to improve collaboration

I think of cross-functional collaboration as something that needs to be designed intentionally.

Like any experience design problem, the goal is to make collaboration useful, usable, and enjoyable for everyone involved.

And just like user-centered design starts with understanding users, better design-engineering collaboration starts with understanding how engineering teams actually work.

The details vary from company to company, but most engineering workflows roughly follow four stages:

• Plan
• Develop
• Test
• Launch

Understanding what engineers care about during each phase changes the quality of collaboration dramatically.

---

Plan: involve engineers earlier than you think

During planning, engineers usually work alongside designers, product managers, and other stakeholders to:

• understand the problem space,
• analyze technical constraints,
• define requirements,
• estimate complexity,
• explore high-level system architecture.

This is one of the most valuable moments to involve engineering deeply.

Invite engineers into research and brainstorming sessions

Too many teams involve engineers only after major decisions are already made.

That’s a missed opportunity.

Engineers often contribute incredibly strong product ideas, especially around systems thinking, edge cases, feasibility, scalability, and technical innovation.

Bringing engineers into research and brainstorming earlier helps teams:

• build shared empathy for users,
• create stronger ownership across disciplines,
• discover constraints earlier,
• generate better ideas collaboratively.

And maybe most importantly, teams start building trust and camaraderie.

That matters more than most workflow processes ever will.

Be responsive during engineering scoping

One of the easiest ways designers can improve collaboration is simply responding quickly during scoping.

Engineering estimates are often time-boxed.

During that window, engineers are trying to understand:

• requirements,
• implementation complexity,
• dependencies,
• feasibility,
• timeline risk.

When communication is delayed, scoping quality drops.

The faster designers answer questions or clarify decisions, the more accurate engineering estimates usually become — which often leads to healthier timelines and fewer surprises later.

---

Develop: speak enough engineering language to reduce friction

During development, engineers are implementing product logic, integrating systems, building UI details, and ensuring everything works together cleanly.

This is where many communication gaps between design and engineering become obvious.

Hold a proper kickoff meeting

Async documentation helps, but kickoff meetings still matter.

A real conversation gives designers the chance to:

• explain design intent,
• walk through interactions,
• answer implementation questions,
• clarify undocumented edge cases,
• align everyone on details before development begins.

Tiny misunderstandings caught early save enormous amounts of time later.

Learn basic technical concepts

Designers do not need to become full-time developers.

But understanding the fundamentals of frontend engineering changes collaboration dramatically.

Even basic concepts help:

• HTML structure,
• CSS layout behavior,
• JavaScript interactions,
• responsive design,
• component systems.

Knowing the difference between HTML, CSS, and JavaScript already improves design conversations significantly.

The same applies to terminology.

Using implementation language correctly helps communication become more precise.

For example:

• padding vs. margin,
• fixed vs. responsive layout,
• component vs. page,
• state vs. screen.

Designers don’t need deep engineering expertise.

But speaking enough of the language reduces friction enormously.

---

Test: participate in QA instead of waiting for feedback

Testing is where teams discover whether the product actually behaves the way everyone expected.

Engineers usually work with QA teams, beta users, stakeholders, and internal reviewers during this phase.

Designers should actively participate too.

Take visual QA seriously

Even if dedicated QA testers exist, designers should still review the implementation carefully.

This is the fastest way to catch:

• spacing inconsistencies,
• interaction issues,
• typography problems,
• animation bugs,
• accessibility regressions,
• layout edge cases.

And ideally, feedback should happen quickly enough that engineers still have time to fix major problems before launch.

Report issues clearly and specifically

When designers report bugs vaguely, engineers lose time reproducing issues.

Instead, provide:

• exact reproduction steps,
• device details,
• browser version,
• account conditions,
• screenshots,
• screen recordings,
• expected behavior.

The clearer the report, the faster issues get resolved.

Prioritize ruthlessly during bug fixing

This is one of the hardest lessons for designers.

Everyone wants products to launch perfectly.

But in reality, product development is often about balancing quality, speed, learning, and impact.

Sometimes shipping something slightly imperfect creates more value than delaying everything for pixel perfection.

A useful question is:

“Will this issue meaningfully prevent us from learning what we need from launch?”

If the answer is no, the team may be better off launching, gathering feedback, and iterating afterward.

---

Launch: retrospectives matter more than most people realize

After launch, engineers usually monitor performance, fix high-priority issues, and run retrospective meetings to reflect on the project.

Designers should absolutely participate in those retrospectives.

If you’re not invited, ask to join.

Retrospectives are one of the best places to:

• receive honest collaboration feedback,
• understand engineering frustrations,
• identify workflow problems,
• improve future communication,
• strengthen long-term trust between teams.

Sometimes the feedback is encouraging.

Sometimes it’s uncomfortable.

Both are valuable.

Because the strongest design-engineering partnerships are rarely built through process documents alone.

They’re built through repeated collaboration, mutual respect, and a shared commitment to improving how teams work together.

And honestly, that mindset matters far more than whether designers know how to write code.