Member-only story
Scaling enterprise design structure
Feature & domain designers
A year in this setup
At the beginning of 2019, we have faced a milestone in the scaling of the UX team at Kiwi.com. The human-centered product focus kept maturing, and we have been bringing more diverse designers, researchers, content strategists into our org. We have been naturally dividing the design team based on two elements:
- user type — who is the user the particular group of designers is designing for (customers, partners, internal employees)
- customer journey — the B2C product has a bunch of designers; therefore, we started to divide it also based on chronological usage of the product (Search, Booking, Managing booking, help & support, Account management & login, transactional messaging, etc…)
In the B2C product design team, we were faced with a couple of emerging challenges and knew that there would be another step we would need to take to scale further. Mainly because of the reasons I’m going to describe.
What are we trying to improve?
We tried to find a solution to multiple challenges that piled up in the last months:
- engineering wide structure change
- more people in the team -> harder communication
- not clear contact points for features spanning across multiple product parts
- overwhelmed designers with too much context switching between multiple projects
The first major challenge which prompted our thinking was an awaited shift in the entire organization structure of our engineering department.
Engineering structure changing (challenge #1)
The company shifted to a tribe <> squad structure. Tribes would be responsible for maintaining key parts of the customer journey while virtual squads across them would build & maintain new features. I will illustrate a very simplified example of how we pictured it to work.
