What Designers Can Do To Collaborate Better With Engineers
In software teams, engineering, UX and other functions come together to work on a product. These different functions have different goals, different perspectives, different core beliefs.
At one level, this is a strength — every function recognises some aspects, while missing others. All these pieces of the jigsaw puzzle need to come together.
But these pieces can have jagged edges that cut into each other, rather than fitting together neatly. The team can get distracted into unproductive debates, certain people’s relationships may be strained, and certain functions made to feel like second-class citizens.
So each function should think about how they can work well with other functions, for the benefit of the team. Specifically, how designers can collaborate better with engineers.
In this blog post, designers’ intentions are not in question. I assume everyone is well-intentioned. Just that sometimes there’s a gap between intention and outcome, which I’m trying to address.
Designers should deliver a UX in sync with product decisions already taken. For example, if we’re building an app for power users that priorities something else above ease of use, before objecting saying it’s too hard and we should simplify it, stop and think about whether this is in sync or in conflict with the product goal. This would be like a chef at a vegetarian restaurant suggesting a beef dish. That’s not a bad idea, just bad in this context. Similarly, a UX idea may be a great idea, just not for this product.
Designers don’t need to understand technical feasibility at the beginning of their stint with a company, but it would be good for them to learn this over time, so that they can make proposals that are actually implementable 1. Infeasible proposals may not be the designer’s fault — he’s a designer, not an engineer — but they they don’t help the team progress 2. In other words, a designer who doesn’t understand technical feasibility isn’t a bad designer; one who does is a good designer.
Designers should understand the constraints the team is under, and deliver the best UX that can be implemented in the available time, rather than an idealistic one that takes six months to implement 3. Which amounts to insisting on buying a private jet when we can afford only a car. While well-intentioned, it doesn’t help the team progress.
Designers should internalise the spirit of launch and iterate, not aim for perfection right out of the gate. Do you remember the day Instagram launched? Your users won’t remember the day you launch. In fact, faster iterations lead to a better UX.
Designers should iterate with users with interactive prototypes, validate the product (does it do something users want?) and UX (is it usable?) before giving anything to engineering. This is because engineering takes 10x the time as UX.
Designers should deliver to engineering in an agile way, not waterfall, where engineers wait for months and suddenly get a 80-page PDF. The first deliverable should be an interactive prototype, with both product and UX validated. The details may not be right yet. For example, if want to ask for someone’s gender, you could do so via a segmented control:
Or a single button that toggles each time it’s tapped:
Or a dropdown:
Or a checkbox:
Or abbreviations like M and F. Or icons for each of the genders instead of text.
Such details can be taken care of later. Similarly visual design — colors, fonts, alignment, padding, icons — can be filled in later. But the essentials should be in place: how many screens are there in this app? What can the user do in each screen? Which screens require input from the user as opposed to merely being informational? Where can the user navigate to from a given screen? These essentials should all be frozen in the first deliverable from UX to engineering. And the rest, in the second.
Designers shouldn’t deliver static mocks, because it’s harder to get a feel of how the product will work until after implementation, at which point changing it will cost a lot more.
One designer told me that once he delivers, it’s the engineering manager’s job to get it implemented, not his. This is not ideal. Designers should coordinate with engineers to get the important parts implemented first.
Designers should optimise for the team as a whole, not just for design. For example, if engineers say something takes too long to implement, think about how to reduce it 4. Or proactively talk to engineers after implementation is done, find out where a significant amount of the time went. Maybe a single animation took two days, while the rest of the UI took two days. Be open to such input, let it sink in, and maybe you’ll do things differently next time. Or maybe you won’t. That’s fine. The important thing is to be open-minded and recognise the consequences of decisions we’re taking.
Designers should prioritise what area of UX improvement the team should work on first. I worked with some designers who want everything improved. At one level, I can empathise with that. That’s what I want, too. We’re here to build a high-quality product. But it won’t happen at one go. We need to work on it step by step. So it’s important to identify what’s most important to fix, what’s second most important, and what can be done later.
The same principle applies to everyone. If I as an engineer come up with an idea that’s great from an engineering perspective, but we can’t acquire users who want this product for at least thrice their LTV, it’s not feasible from a marketing point of view, so it’s ultimately a bad idea.
An infeasible proposal may still be useful to iterate from and end up with a good proposal. For that to happen, all participants in the discussion need to have the maturity to prevent it from degenerating into an argument: Engineers can say “we can’t do that” but they should have the maturity to follow it up by asking, “But are there some good ideas here that we can implement in a different form?” Designers should have the maturity to respond to “That’s not feasible” with “I see, so let’s not go ahead with my proposal, but are there some good ideas we can do in a different form?” rather than arguing over and over again for “their” idea.
Unless six months is within budget.
Not necessarily reduce it, if it breaks the design, but be open to the perspective and consider it.