What makes or breaks a product team?
Strong design principles are one. A clear, effective roadmap is another. But one of the most important, yet overlooked, aspects of all great product teams, are the relationships between the designers and engineers on your team.
Yet many designers compartmentalize building a product into two distinct parts – design and development. This distinction is one of the most dangerous traps a product team can fall into. When design is seen as a satellite that orbits engineering, it usually comes crashing back to earth.
Designers trained in isolation
Design education is partly to blame for this. What happened when you handed in your design projects? I’ll bet only the smallest fraction of students ever had a professor bring you to the Computer Science department, sit you down next to another student, and ask you to build what you just handed in.
The same goes for agencies, many of whom lack their own engineering teams. For most projects, design specs are tossed over the back wall for an external team to build. You’ll be lucky if you ever meet them face to face. Luckier still if the product ends up resembling anything close to what you designed.
The problem in both scenarios is the same – they separate design from implementation. In product design, both these things are inextricably linked. A world with terms such as “design freeze” or “hand off” just won’t cut it.
Start by understanding the constraints early
Truly great products are often a combination of two things: a technical breakthrough and a never-before-seen design it enabled. So it’s essential designers understand the possibilities and restraints of the technology they’re working with, before they can properly delve into the design.
Here’s an example. Let’s say you’re designing a native iOS app. Here are some technical questions you might receive from an engineer that can heavily influence your design decisions:
Which framework are we going to use to match the spring curve you’ve designed with? If we can’t find a suitable one, maybe you should draw from the default UI view animations instead.
How long does it take the API to fetch the data for that list-view? If it’s too long, you’re going to need to do more than place a spinner.
The API takes a little too long to load in our user’s avatars. What do we display in the meantime?
Questions such as the above should be asked and addressed as early as possible by talking and sitting with your engineers (product designers at Intercom are placed with engineers from day one). Don’t be put off by what won’t work. The constraints you discover are often advantages in disguise.
Design together
A product designer should be responsible for sharing designs early and often with engineers. That doesn’t mean something neatly packed up and polished. It could be the roughest prototype imaginable.
For a recent project, all our designs were prototyped in Framer and shared with engineering as early as possible. It allowed us to discuss technical feasibility, which third party frameworks to use, what types of animations were possible. These were all perspectives designers might have never thought of.
In this instance, engineering heavily influenced our design decisions. It’s not just designers that have the capabilities to solve problems. You’re likely working with engineers who have spent thousands of hours solving their own complex problems. Great designers can’t always have the “eureka” moment.
What they can do is frame the problem for their team, and create a design process to extract the best solutions from that team. If you’re splitting your product process between design and engineering, you’re more likely to become protective of “your” area, shutting out potential perspectives and feedback which could lead you to a solution you might not have thought possible.
Build & iterate together
Our process for building product at Intercom starts with discussions between design and engineering, and a collaborative Intermission – a one page brief for the project
High-level product decisions are usually nailed down long before engineering starts. However, in terms of interaction and visual design, details reveal themselves as the product is being built. Instead of handing off pixel-perfect designs to your engineering team, embrace the opportunity to design alongside them as they build.
It means you can design with a clearer, more realistic perspective – based on real data, technical constraints, and an overall sense of how the product feels.
So if something just doesn’t feel right, or the design doesn’t scale with real data, identify if this is a larger design problem which needs to be brought back to first principles, or something that can be tweaked in code.
If the latter, sit side-by-side with your engineer. Communicate often and in person, or you risk details being lost in translation. Just remember communication isn’t about being the hovering art director, telling the engineer to adjust that asset by 1 pixel, or change this color to #f5f5f5.
Designing as you build also allows you to identify opportunities to strengthen your original solution. Designers aren’t infallible. Details are often missed first time around, so use your opportunity to improve the flow, offering alternative forms of feedback.
Working closely with engineering to add interactions to our user profiles
Some of my favorite animations or interactions have come from talking with engineers and assessing a screen together – asking ourselves “wouldn’t it be better if X did Y”. If these improvements can’t be made right away, talk with your team and assess if they can follow up after release.
Turning design into reality
Being a great designer requires you to be empathetic, not only to users or clients, but to your engineers as well. It’s about involving them in the design process, and understanding the technology that enables your design. It’ll make you a stronger designer, and result in a better product in the long term.
And remember that for a modern product team, what matters is what ships. So embrace those who can turn your ideas into reality.
Comments