How to work effectively with engineers

Tips from a product designer on building valuable partnerships with engineers.

Right after college, I started working at Dropbox as a product designer. What I expected was that my first year working would make me better at my craft — at typography and layout, at asking the right research questions, at constructing intricate prototypes. What I didn’t expect was that so much of being successful as a designer would depend on my relationships with cross-functional partners, and in particular, with engineers.

Eager to learn more, I met with designers and engineers on the Paper team at Dropbox. I asked everyone two questions:

• Go back to a time when you had a great experience working with (engineers/designers). What worked well? Why did it work well?
• Tell me about a project when you felt stuck or frustrated with (engineering/design)? What was difficult? Why did it end up that way?

Here’s what I took away, packaged up into bite-sized insights that you can take with you into your own design process.

Learn what makes them tick

Resolve ambiguities about how you’ll work with the engineers on your team upfront. Do this by taking the time to get to know them. Make sure to be direct about how you’ll help each other do your best work.

Grab coffee at the start

Early in the design process, sit down with the engineers on your team and learn about how they work. Ask about things like:

• What do they expect at hand-off?
• How do they like to communicate?
• What were their past experiences working with designers like?
• What energizes them about their work?

Having answers to these questions can optimize both of your processes. For example, some engineers like designs to be redlined before implementing. Others like to be more ad-hoc and sit down with designers to get the design pixel-perfect. Figure out what works best so you know what to expect later on.

Be desk buddies

If you’re going to be working with a group of engineers regularly, make sure your desks are nearby. It’s a great way to naturally build rapport and have insight into each others’ work. All the scheduled meetings and Slack conversations can’t compare with the spontaneous conversations you’ll have sitting together.

On the Paper team, designers are integrated with their cross-functional teams (engineers, PMs, writers, etc.). Being close by, I get to catch up with the team in the morning over coffee and everyone else gets to peek over my shoulder when I’m cooking up something new.

Give engineers their design hats

Even early on, don’t forget to involve the people that’ll actually be building the thing you’re designing. Engineers provide a unique perspective to design. What’s more, including them in the process will make them better product- and design-thinkers.

Have an engineer in the room

Bring engineers into conversations and share early on, so everyone has context on the goals of the project. If the project isn’t staffed with engineers yet, work with an engineering manager to get at least one on it. Even if they won’t be working on it full-time for a while, you can start looping them in.

Kate Apostolou kicks off projects with a brainstorm to align and ideate together. This way, she gathers a diverse set of ideas and gets everyone excited about a common goal.

Make design visible

Post work in visible places and don’t be afraid to share in-progress work. Waiting for perfection and only sharing close to hand-off makes for infeasible solutions.

When the Paper design team started hosting design sessions on boards by our desks, engineers and PMs felt less intimidated to drop in, and often did, to see what was going on. It made other people on the team feel like the design process wasn’t just for the designers.

Train their design muscles

Invite them to research studies, design sessions, brainstorms, and more! These are opportunities to have engineers understand the problem at hand. These experiences also pay dividends in the future, when they’re able to contribute valuable ideas back to the project.

On the Paper team, engineers are always invited to design sprints. They’re involved in everything from forming the problem statement, all the way down to drawing storyboards. It’s a great way to get everyone motivated by the same user problems.

Get to a solution together

Leverage engineers for more than just implementing designs. They have an intimate knowledge of the product and its inner-workings. Working together will help you converge to a solution that’s both technically sound and user-centric.

Use design as direction

Designs don’t need to be complete for engineers to start work on them. Sharing incomplete designs lets engineers get a head start on building while you’re still ironing out the details. One caveat here is to set expectations around which parts aren’t set in stone. This way, you avoid unnecessary thrash.

As Bjørn Rostad says, “the best hand-off is no hand-off.” Iterating on design while engineers build creates a back and forth that doesn’t stall for anyone. It’s one smooth transition from ideation to implementation.

Don’t put all your eggs in one basket

It can be easy to prune the ideal solution for weeks before handing it off to engineers. Instead of having your one idea shot down because it takes too long to build, present a range of options so you can compromise on something feasible.

Joey Grillo describes this situation as “MacGyvering.” This is when design comes to the table with many explorations, and engineering does the same technically. Then, the team works to fit together a solution that both meets users’ needs and is also within the project’s technical constraints.

Think like an engineer

Build your own repository of technical knowledge. If an engineer says no to an idea, push back and use the opportunity to learn how the system works. Figure out the realm of what’s possible and what’s not.

David Stinnette always asks engineers to explain the technical constraints that exist. He uses it to find room for negotiation and propose solutions that engineers may not have thought of. Plus, it’s helpful to build an understanding of the way the codebase works for future projects.

Spot the edge cases

It’s hard to predict all the different edge cases and unique logic a design might have when you’re just mocking something up. Instead of leaving engineers to deal with edge cases when they’re implementing, work with them to determine what they are and how you’ll solve for them.

Early on, I’ll create and share a “design explorations” doc with wireframes, workflows, or low-fidelity mockups. Engineers will pepper the doc with questions around micro-interactions, empty states, error messages, etc. — things I usually haven’t thought about yet. With these questions in mind, I’m able to account for an extra level of detail in the next iteration.

Own communication, don’t expect it

In the implementation phase, good communication ensures that great design makes its way into the product. Instead of waiting for engineers to communicate about their progress, set up opportunities for that to happen.

Create milestones

On larger projects, slice a project into smaller one-week or two-week milestones. While this might take a lot more work upfront, it creates accountability. It also forces everyone to check in without having communication fall into any one person’s responsibility.

Because the Paper Growth team works on experiments, their projects usually have a timeline of one to two weeks of design work and one to two weeks for engineering work. With a small scope and short timelines, the team avoids long communication drop-offs. Try modeling larger projects the same way to reduce the risk of radio silence.

Carve out time to share

Make a regular habit out of sharing designs that are works-in-progress at team meetings. Also encourage engineers to demo if they’re able to get something working ahead of time.

Anbu Anbalagapandian, an engineering manager, created a bi-weekly meeting for sharing designs. The engineers on her team were excited by getting a sneak peek into what they’d be working on in the future. The meetings also gave designers time to collect feedback from the team.

Just sit down together!

Take the initiative to stop by an engineer’s desk or schedule an informal work session. These reduce back and forth and build the habit for check-ins outside of meetings.

Across the board, both designers and engineers on the Paper team found informal check-ins to be helpful. One way they did this was to both sit down at a computer together and walk through the implementation.

Don’t forget the final mile

The design process isn’t over just because you’re no longer mocking up or prototyping. Getting across the finish line means making sure that what’s built is high quality and that everyone understands the value of doing so.

Bug hunt together

Instead of leaving tickets or Slack-ing back and forth about polish, save time by combing through the experience together. You can be precise about the implementation feedback you give and work through any design details together.

Bryan Guillemette emphasized that as an engineer, he finds these informal QA sessions really valuable. Designers catch bugs core to the user experience and engineers are able to fix many of the bugs on the spot.

Prioritize design fixes

Understand the time constraints for a project and figure out which pieces of design are most important to get right for each release. Maybe it’s okay to release to 10% of users without having all the spacing perfectly tweaked, but maybe getting the right error messaging in is crucial before releasing to everyone.

Emily Lutz is an engineer who likes working with designers to create a prioritized polish list. This way, she’s able to focus her time on the most important parts of the design before an early release.

Conclusion

These tidbits are brought to you by both designers and engineers on the Paper team. They reflect the best of our experiences, as well as the places where we could improve. During your next project, try out a few of them to bring engineers closer to your design process.

After all, designer, engineer, product manager, whatever — we’re in it for the same reason. We’re all striving to make great products to do right by our users. So, the better we are at working together, the better we’ll be at doing just that.

Thanks to Justin Tran for the illustration, as well as Andrea Drugay, John Saito, Ryhan Hassan, Kate Apostolou, Emily Lutz, and Kurt Varner for their thoughts and feedback. Special thanks to Justin Hileman who propelled this process with an internal guide for engineers working with designers.

Want more from the Dropbox Design team? Follow our publication, Twitter, and Dribbble. Want to make magic together? We’re hiring!