The 3 types of design teams: centralized, embedded, and the elevator team
There’s not a secret formula for a team to succeed.
You’re a design manager that already built your perfect design team and the next step is to make a decision about how to organize your incredible people.
There are many possibilities of structures in order to speed up your design process.
The first and more important fact is: there’s not a secret formula for a team to success (according to Google). No matter if it’s a design team or any other. We’re talking about people, the most difficult and unpredictable system to manage.
Teams are like people, there’s many of them, but no two are alike.
But if you’re looking for some tips of how to organize your team, you are in the right place. ¡Here we go!
Centralized
As you can imagine at this point, centralized teams keep all designers together in the same space.
These teams use to work as an agency where there are many projects going on and managers manage the workload within the team.
Almost always, collaboration happens in the design team and other areas like developers or business don’t participate in the process.
As they share the same space, they can post their works around for discussion. Designers can share easily their work with peers and get feedback in a rapid way at the same time that they learn from each other.
A huge benefit of centralized design teams is that experience is unified and consistent across many products. In this way, centralized teams have a grand-crossed vision, instead of an incremental vision of a single product.
On the contrary, designers are isolated from other areas and their requirements. Constraints can be discovered at the end of the design process and iterations can be slow.
This is a huge risk of doing unworkable solutions and wasting time .
Embedded
On this second type of design team, we find the opposite of centralized teams. Embedded teams use to be multidisciplinary teams or EPD teams ( Engineering, Product, and Design).
Normally, these cross-functionality teams consist of about 7 people from different areas working for the same purpose in agile methodologies.
In this structure, it’s crucial to involve UX roles in early stages of the project. Not involving UX roles in a product inception could cause a lack of design in the project and eventually untested, inconsistent and non-problem solving solutions for the final client. As soon as UX roles are included in working groups for discussing new features or products, the better and accurate solutions you will get.
In this context, it’s equally important to include different roles as product or marketing roles into UX ceremonies like user feedback sessions. This little action will empower our role and our work within the final product and customer needs. There’s nothing like data to probe other roles how important is to start a project validating ideas.
Besides, designers have the opportunity to build relationships with other areas members. Building relationships with colleagues of other knowledge areas will erase barriers and will improve discussions about constraints and requirements, speeding up the design and development process.
On the other hand, sometimes designers could feel isolated.
Being surrounded by people who don’t share your skills and perspective could be exhausting and compromise the design solution. Let me explain why.
For many years, companies have been had poorly designer: developer ratios. For instance, LinkedIn has been improving from 1:11 to 1:8 in just 8 years. The last trend is to have 1:8 ratio:
Although there’s a huge change from years ago, designers still are outnumbered by engineers and they are vulnerable to the “path of least resistance” which explains that designers decide in favor of developers in pressure situations.
One solution to this problem could be pair designers as Slack does.
Pairing designers build trust in supporting design positions. Designers don’t feel isolated and powerless with a colleague next to him/her. Also, they can complement each other with feedback and quick validations.
The elevator structure
The best way to describe these teams would be on-demand.
Designers temporary work into cross-functionality teams focused on a project and when the project finishes, they return to the centralized team.
But, ¿why the comparison with an elevator? 🤔
Well, if we take the elevator as the centralized design team, we have the floors as other teams. Teams can call the elevator for a UX role and the design team provides one.
The UX lead assigns a designer depending on different requirements. Some of them could be skilled requirements like research or conceptualization, copy, prototyping or high fidelity design. Sometimes there are other reasons like schedule needs or lack of roles.
Based on this, as UX lead, you can build a specialized team with many roles as researchers, prototyping roles, visual designers, writers….and so on. However, too much specialization could become into a lack of roles problem if your organization doesn’t have sufficient scale. If other teams require the same role at the same time, the elevator will crash trying to keep one designer into two different places. There’s no reason to keep a designer in just one project, but eventually, he/she could feel overwhelmed.😨
On the other, you can build a team with cross-skills to cover almost every project need.
There’s no perfect solution and it will depend on your organization needs (also on your budget).
Besides, watch out your assignments. According to your manager role, you have to know strengths and weakness of each member of your team to make the right decision. As I mentioned before, never forget that designers could feel isolated and pressured into an unknown team, especially if they don’t have the perfect skills for that project.
Another thing to keep in mind about these teams it’s the size.
If we’re part of an organization with low designer:developer ratio, you could be in trouble. With many teams calling the elevator at the same time your team could collapse.
The good thing about these teams it’s the hybrid nature. They work like a centralized team as well so they have many strengths related.
Keeping designers together will provide consistency through many projects and products. Also, when they’re not assigned to a project, designers can work on cross-design projects like design systems, best practices or support.
Designers that are already assigned, can also come back to the elevator for design reviews, alignment sessions, get feedback or just get off their chest because they are surrounded by developers.
So, that’s it ! We’ve reviewed 3 different design-teams structures with their pros and cons. Don’t forget to give your feedback and clap clap clap!
👏👏👏👏👏👏👏👏👏👏👏👏👏👏
