Approaching the product design process through an engineering lens

Not long ago, a wise design pro by the name of Joshua Goldenberg, VP of Design at Loom, advised product design folk to “find their engineering soulmate” early on in their job. 

He knows from experience that a strongly aligned partnership between design and engineering can make the entire product development process go more smoothly. It could also lead to more well-rounded explorations in the early stages, and possibly faster breakthroughs and innovations in later stages. 

As much as we’ve spoken to design professionals about the importance of the relationship between designers and engineers, it also helps us to hear directly from our engineering partners. 

So we were delighted to get some time with Duretti Hirpa, Principal Engineer at Zipper and formerly a Senior Product Engineer at Slack, on how design and engineering teams can best collaborate on building quality products. 

The Goldilocks Rule (or how not to dread the design-dev handoff) 

Like most engineers, Duretti has experienced that dreaded moment when a design mockup comes across her desk — sight unseen — and she’s instructed to just build it. That’s typically a worst case scenario, but it does happen. 

“I think I've seen projects go off the rails when engineering gets involved too late,” she says. “Sometimes design has made a lot of effort to get something looking a particular way, but maybe there's some technical limitation that means that we actually can't build any of that and that's sad because someone's spent a lot of time trying to get to that point.”

“What's that children's story with the three bears? It’s like that,” she says. “You want to get [the balance] just right.”

The best thing to do is to make sure there’s some engineering representation in early product conversations. It doesn’t have to be the whole team, but adding an engineering manager or a tech lead can help you inform design decisions and avoid critical mistakes come developer handoff. 

Even the smallest features need clear owners

You’ve been there: you see an opportunity to expand on an existing feature in a meaningful way, so you let yourself believe that this small update can simply get coded and shipped. No complications, right? 

But just as designers are bound to run into issues when they don’t consult with engineers early on in the process, the reverse is also true. “I think fundamentally engineers are optimistic people,” says Duretti. That doesn’t mean that their optimism can’t lead them astray. 

Duretti reasons that engineers won’t always know when they might come across an unanticipated issue that requires a design solution, like needing a new button or a mockup for an error state. 

She shares one example of a time the team at Slack wanted to make an update to an often-used feature (snoozing notifications). A small team of engineers went ahead and built out some necessary additional functionality, but no one truly owned the project’s success. Over time, product managers transferred teams, communication eroded, and the project kept getting punted. Even if it seemed like a relatively simple task, and an almost certain win for the customer, the project wasn’t going anywhere. 

“The belief that, ‘Oh, it's just a small feature,’ meant that we didn't run [the project] as tight as we normally would have,” she says.  

In what ended up being “quite the retro,” according to Duretti, the team realized that their biggest misstep was that everyone was waiting for somebody else to step up and be the leader. 

So, when in doubt, make sure that someone is responsible for looking after the project and is making sure that the right voices — whether that’s design or product management — are represented in your process. 

Managing scope creep is an interpersonal and a team effort

A reality we don’t often hear people be so candid about is that sometimes product decisions are influenced by people in positions of relative power. It’s not controversial, nor a secret, but it still is a reality that most product design and development teams need to contend with. 

Duretti calls these “human factors”. 

“Is it a very classic swoop and poop, where the [CEO] comes in and tells you how things need to go? Or is there a power differential; like is this a leader, a director, or VP?” she says. Depending on these factors, you can determine how much you can push back on a set of requests or demands. 

While there are some people who are naturally good at saying no, others need some practice on pushing back. Duretti says it’s a good idea to get aligned as a team of engineers and designers on what is and isn’t possible. When you’re crystal clear on your constraints, you can have a much more practical conversation with stakeholders. 

A great way to frame new requests is to be flat out and say, “it’s going to cost you,” says Duretti. Whether that’s time or money, every change that follows the initial brief should be approached as a negotiation. The better you get at managing and measuring your capacity as a united team, the better equipped you’ll be to ship features within a reasonable timeline (while also avoiding burnout). 

How to do more help than harm when you’re jumping in mid-process

We don’t always have the luxury of being part of a project from kickoff to shipping. It’s especially hard to jump in when the project has a history and you’re the new person on the team who’s still trying to make a good first impression. 

“My starting point would be to make friends with people on the team,” says Duretti. Be prepared that you may encounter some natural defensiveness, or wariness, from established members of the team, especially if they sense that you’re there to shake up their process. 

In cases where you may be stepping into a project that’s not going as expected, Duretti says that, “my zero-step would just be to establish some relationships with key people — both on my team and adjacent — and get a sense of what’s happening. Let me make some friends. Let me get the tea,” she says. 

“Sometimes it's just growing pains, and it's not any one person's fault, and sometimes there's super extenuating circumstances preventing the team from getting certain things done,” she says. 

“But if it's not happening on purpose, then I think you can influence what's happening and help people pave the cow path a little bit — but you should know whether it’s a hot stove that you shouldn't touch.”

Avoiding the “P” word 

Some people don’t like the word “process.” Nonetheless, you need to find a shared language for having an integrated and somewhat predictable way of working as a team. How do you achieve that?

Duretti approaches it with an MVP mindset, like any good product designer: “Can you [prove] it on a smaller scale? If you're on a team, and you agree to work in a certain way, and it shows that you’re getting better, people will want to copy that,” she says. 

“When you’re able to say: ‘Here's what we did, it worked really well, and now we're shipping much faster than we were before,’ people love that,” she says. So once you’ve found success on a smaller scale, and that success proves to be replicable, keep evangelizing to operate that way on a larger and larger scale. 

QA can be a competitive advantage 

“You don’t get a second chance to make a first impression,” says Duretti (spoken like a true veteran in her field). 

That’s why the final QA review of your product should be everyone’s job, and that includes designers. “Designers should have an opinion on the final feeling and full experience of the product,” she says. 

Balancing QA tasks between engineers and designers is also helpful because, by that point, designers will have had some distance from the product and so they can act as a true fresh pair of eyes. 

Duretti’s been in tech for about 15 years now and she’s noticing that the quality bar for software products has only gotten higher. “People are looking for a lot more polish,” she notes. 

“Users don't have a lot of tolerance for experiences that aren’t smooth,” she says. “I’m a quality nerd, I just really like using things that feel nice and I think that's a competitive advantage for your business. But be prepared: If it’s something that’s easy to use, it's going to be hard to do.”

What speaking with Duretti reminds us is that engineers and designers have more shared values than not. Both want to build products that are reliable, beautiful, and even delightful to use. Both want to make users happy while satisfying the needs of the business. And both want to feel proud of their work. 

But it’s not as simple as getting from point A to point B, as Duretti so astutely pointed out earlier. Even the seemingly smallest upgrades require collaboration across disciplines, clear owners, and inevitably some negotiations around scope and timelines. The more that designers and engineers can share in these responsibilities, the better the outcome for all. 

‍

This post is part of an ongoing series featuring snippets from Same Page — our event series that explores the design process. Explore In the Margin to see full-length recordings and more content on the design process.