Why and how to align product design teams
When people talk about lack of alignment, they immediately think of adding strict processes and rituals to fix the problem — it takes about 30 seconds for someone to jump into scheduling a bi-weekly 15-people Monday meeting. While structure and process are necessary for alignment, trust is critical to making it work well.
When 100 teams have 250 designers doing what they think is best without talking to each other, the end result looks like this nightmare picture from my four years at Booking.com:
UI elements and whole features both look and work differently even within the same page as if they were designed by 100 different people — as they were. Multiple teams worked on the same things for months without talking to each other. On top of aesthetics and scalability issues, user feedback was clear — they were frustrated with the site and only used it because it offered the lowest prices.
So when we set out to build a design team at DeepL.com, the goal was to do better. Aligning designs while giving designers creative freedom is tricky. How do we find a balance between autonomy and alignment?
Do nothing — let experimentation decide.
This booking.com approach at the time. No arguments about design; just run an experiment. If it’s positive on your chosen metric (most likely, conversion), your design “won.” Right? Wrong. On multiple levels:
- Unless an experiment is set to test specifically design changes, it doesn’t help in comparing a specific design against other possible options. For example, if you’re introducing a new feature, you’ll (in)validate a combination of a high-level idea and user needs, general implementation, and a specific design. Because you’re testing so many things at once, even if your experiment shows an increase in the desired metric, it won’t say much about the strength of your design compared to its alternatives.
- An increase in conversion only shows one strength of your design: more people buy now. This metric alone doesn’t tell you if they were so frustrated by your design that they decided never to use it again.
- If you did validate a design change and there are no long-term concerns about the solution, you should have a conversation with your design team advocating for this specific solution to become a pattern.
Historical option — art director figure
Assign or hire someone to develop design direction and review other people’s work. While working well for small teams, it doesn’t scale. As the team grows, the art director will soon become a bottleneck.
Another problem with this approach is that it’s not great for the team. Smart and talented people don’t really like constantly being told what to do.
Dutch option — consensus
Discuss visual design or interaction patterns with the entire team until everyone is happy.
The problem is that moment might never happen, or the decision might take forever. And the speed of decisions aside, with never-ending discussions, the team grows frustrated over time.
How do others do it? Borrowing peer review from engineering
What if different team members reviewed each other’s work as developers do? This would create room for different perspectives and the opportunity for cross-product alignment without relying on one person to do reviews.
Sounds good, but engineering and design workflows don’t match one-to-one. In an engineering environment, a request for review can happen automatically on a merge request, while designers need to share their work proactively. There are many ways to facilitate this (from design critiques to pair design), but no good sharing is possible without trust. If people are afraid of being criticized or having decision-making power taken away, they will be reluctant to share. Two things we saw that helped greatly with building trust:
- Make it clear it’s ok to share imperfect work; the earlier, the better. This one is easy to lead by example: I happily share nasty sketches and dropbox papers with raw thinking. We even had a “Bring Your Worst Design” session where we shared our most embarrassing designs from the past.
- Make it clear that the feedback receiver is the decision maker. Whatever feedback is coming the designer’s way, their responsibility is to consider and decide whether to act on it or not.
Building trust takes time. And we need low-ego, open-minded people to make the peer review approach to alignment work. So it’s important to watch out for people who worry too much about being right.
In a growing design team, alignment is necessary to deliver business and user impact while keeping everyone sane. Adopting peer review-like practice helps bring diverse perspectives and needed feedback without creating dependence on one person. But for it to work, we need to build trust in the team first.
So far, we have made it work for a team of 20 people, and as the team grows, we’ll continue experimenting with the approach to keep up with the changes.
