Why Designers Should Bring Engineers In Before the Mockups Are Pretty

Product designers often hesitate to share unfinished work, especially with engineers. The instinct is to wait until a design feels polished and defensible — but that timing can cost a team the chance to explore better solutions. Helena Jaramillo, a product designer at Coda who previously worked at Google, Transferwise, and Khan Academy, argues for flipping that instinct: bring engineers into the design process as early as possible.

The early ideation phase is where engineers add the most value. Their technical knowledge helps surface constraints and edge cases before a direction is locked in. Instead of discovering mid-build that an approach won't work, designers can learn those limitations upfront and build more thoughtful solutions around them.

Work With One Engineering Partner Throughout

Jaramillo recommends identifying a single engineering partner to collaborate with for the full duration of a project, even if a broader engineering team will eventually own the build. On a feature Coda shipped last year, Packs Tables — which pulls data from third-party services like Spotify, Google Calendar, and Gmail into a Coda doc — she worked closely with an engineer named Gil.

The feature was highly technical because it depended on APIs from multiple external apps, so it had to work uniformly across all of them. To reach a viable solution, Jaramillo and Gil used three practices: straw man mocks, brainstorming, and defined key questions.

1. Start with Straw Man Mocks

Straw man mocks are the visual equivalent of a straw man proposal: quick, deliberately rough sketches meant to generate discussion rather than propose a final design. They should:

  • Be quick to make — early ideas often contain misconceptions.
  • Ask more questions than they answer.
  • Show a range of directions instead of committing to one.

When reviewing these mocks with an engineer, probe with questions like: What are your biggest misconceptions? What haven't you thought about yet? What directions seem interesting, and which are technically difficult — not to avoid the hard paths, but to understand their trade-offs.

2. Brainstorm New Ideas Together

The process stays deliberately open at this point. Rather than refining existing concepts, designers can use their visualization skills to bring early team ideas to life. At Coda, the design team often works in high fidelity because the component library is ready to go, but pen and paper or screensharing an iPad works just as well for remote teams. During Packs Tables, Jaramillo and Gil used whiteboarding to align on open questions and sketch rough UI, without attempting to solve the final design.

3. Define the Key Questions

Key questions act as guiding principles for the project — they ensure the team tackles problems in the right order and prevents early debates about solutions. A useful analogy: if someone asks whether to order custom napkins for an event, the real questions are about budget, time, and the event's tone. Answer those first, and the napkin decision follows naturally.

Jaramillo and Gil tracked their key questions in a Coda doc during brainstorms, then ran them in a call with the full engineering team to get agreement that these were the right questions to pursue. This also created an opportunity to engage the broader team early.

Shared Understanding Beats Sequential Handoffs

The takeaway from Jaramillo's approach is that successful collaboration isn't about sending a polished proposal from one team to another. By involving engineers early — especially on technically complex features — the team can balance product goals against technical constraints, catch edge cases sooner, and reach a solution faster.