Traditionally design teams have been centralized, such that all designers worked on the same team and would take on projects together.
This allowed teams to build on each other’s strengths, hire specialists that focus on specific areas like visual design or prototyping, and allowed them to cover a broad range of challenges.
However, over the years a different model has emerged and has become more and more popular – designers have become embedded in cross-functional teams together with engineers and a product manager and together they own a specific part of the product.
This is how we structure our teams at Intercom and it allows us to build and iterate fast, as everyone is working closely together and builds up deep domain knowledge over time.
We’ve seen many benefits for structuring teams this way, but there are a number of challenges we’ve had to overcome.
Designers lacking feedback from other designers
In a cross-functional team, a designer primarily works with their product manager and engineers. Those disciplines give great feedback, but it’s different from the feedback another designer would give. Because they come up with creative design solutions that solve problems and produce delightful designs, a designer’s feedback is a unique combination of broad and detailed.
Solution
Encourage your designers to get feedback from each other. Twice a week we organize design crits where the designers get together, present their work and exchange feedback. This type of designer to designer feedback can help improve the overall product in a more effective way than standard user feedback.
In addition to this, try sharing your designs on Wake. We’ve found it most useful for feedback on interaction and visual designs, as it can be difficult to digest more complicated product design challenges.
If you’re running a cross-functional design team, try creating a dedicated space for designers to gather. Recently, we set up a design studio where we gather for design crits and workshop design problems together.
Work getting siloed
When every team works on a different part of a new product, designers aren’t always aware of how their work might overlap with others. This can lead to similar things being designed in different ways, conflicts where two designs are not compatible, or unintegrated experiences where multiple parts of the product that should be aware of each other are not.
Solution
Transparency is key here. Keep roadmaps for all teams together in one place and accessible by everyone on the company. Using a tool like Basecamp to keep track of projects and giving everyone access can be incredibly useful as well.
Our designers also share their weekly and 6-week goals with each other. We’re using a shared Google Doc to keep track of this. Each Friday at 4pm there’s a reminder on our team Slack channel to update your goals and set new ones for next week. Then on Monday morning there’s another reminder to check out what everyone did last week.
Sharing in design crits and on Wake will also help designers to stay in the loop.
Designs becoming inconsistent
When the design team is small it’s easy for the designs they produce to look, feel and behave similarly as designers talk to each other all the time. As the team scales it becomes increasingly difficult. You can clearly see that different parts of your app were designed by different people. The patterns used there are similar, yet different and it’s not obvious why.
Solution
To keep your designs aligned and avoid designers reinventing the wheel, introduce a design system. For us it’s a collection of design patterns, design principles, front-end engineering guidelines and guidelines for how to write content. This allows both designers and engineers to move fast and focus more on the unique value their designs enable rather than the interface elements that make it up.
It’s important to get the whole design team to think about the interfaces they design as reusable patterns and deviate only when reusing doesn’t make sense. When deviating, design it in a way that others can reuse it too.
Designers having different values
While the team is small, designers organically stay aligned on the same values. But as you scale, designers start to interact with each other less and less and their values can start to drift apart. For example, one designer might value making the product as consistent as possible, even if that means making the user experience worse, while someone else might value optimization for the specific context, instead of optimizing for consistency.
Solution
Establish shared design principles. What are the qualities that you strive for in your designs? What do you value as a team? Establishing actionable principles will help designers make decisions and evaluate designs. It’s important for them to not be truisms. For example, “our designs should be easy to understand” is a bad principle. No one intends for their designs to be difficult to understand. Instead talk about specific trade-offs you’re willing to make. For example, at Intercom we value simplicity over power. The opposite might be a completely valid principle for another company.
Once your principles have been set it’s important to actually use them when evaluating designs. Print them out and put them on your walls to remind your team. If you find that you don’t reference some of them consistently, consider dropping them or reframing them.
Difficulty learning from each other
If there’s just one designer on a cross-functional team, who can they learn from? This is especially problematic for new hires who join a team and don’t know how design works at your company. Covering this in onboarding helps, but it’s not enough. Doing design crits help as well, but it’s just not enough to really pick it up. As with any craft, the best way to learn is by observing and imitating.
Solution
When new hires join, do tours with different teams and team members. Give them small but meaningful projects that they can complete from start to finish and collaborate on with the other designer on their team. This is useful not just for new hires, but also designers who have been on the same team for a long time. It’s refreshing to see how other people work and try something different.
Establishing and documenting a shared process for how you approach design problems can be incredibly useful as well. We’ve created a checklist that we follow for each new project that we take on that guides designers through the design process and helps them plan their work.
Lacking a social sense of a design team
When designers are on separate teams you can lose the social aspect of having multiple designers in the same company. Even simple things like geeking out about little big details, discussing how you use the latest feature on Sketch and just getting to know each other can make a big difference.
Solution
To mitigate this, organize events for the design team. We do team lunches twice a week where we watch interesting talks or just chat over lunch. Once a month we organize a team evening where we play tabletop games, go to a gallery or just get beers after work.
To celebrate the work that designers do we organize design team show & tell, where we present our work to the whole team after reaching a certain milestone such as deciding on an overall direction or when a project is ready for engineers to get started. It’s not about getting feedback, it’s about appreciating the work that other people on the team do and to increase transparency.
We’ve also set up studio time each morning from 9 a.m. to noon, where designers can get together in the studio, work from the same space and have informal chats.
Whether having a centralized design team or embedding designers in cross-functional teams, there are compromises to overcome. We have found that the benefits of cross-functional teams outweigh the drawbacks. However, it is important to actively work on mitigating them.
Your company is an ever-evolving organism. New people join, some people leave, teams grow and teams change. Nothing stands still. So even if these strategies are working now, I’m sure that in a year we’ll have different ones in place. Keep iterating on how you work.
Comments