Feature & domain designers
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.
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.
Imagine that there is a full-stack development tribe. It is not entirely accurate in our current environment, but for simplicity of the illustration, let’s say it would be. A full-stack team including frontend, backend, QA, etc… taking care of the checkout process and a tribe taking care of the search experience. Also, imagine that we decide to build a new way of how adding baggage works. We would dedicate an engineer from search to build the feature in this domain, but also an engineer on checkout where the functionality needs to work a little different. Additionally, other roles need to be included in the process on each domain, and some domains require very domain-specific people on the teams (e.g., chargeback specialists in payment domain). So, in a nutshell, there would be people across the company who would be focused solely on delivering this one deliverable across multiple teams.
Of course, all of this needs to be led by a Product Manager (Virtual squad lead) for baggage who has a full understanding of how the feature will work and what impact it will have across the product. But what about design? Should there be two designers closely collaborating on our baggage example? One responsible for the search experience and one for the checkout experience? Or should there be one designer next to the one PM collaborating on bringing the feature to life and improving it further?
From the get-go, we have been leaning more towards the second option. We are firm believers in an EPD leadership where engineering leads, product managers & designers challenge each other from feasibility, business & user perspective. Resulting in decisions that bring us closer to creating an excellent service. That was the essential argument we started with when discussing the design organization structure. We firmly believed that having a designer next to the “virtual squad lead” would make a significant difference to the overall experience of a feature across the product. But not only that.
Communication (challenge #2)
A lot of the time, people reached out to me, asking which designer they should approach. When you have multiple designers working on one feature, sometimes stakeholders around the company weren’t sure who to talk to regarding a specific feature. PMs had a hard time, as they had also to coordinate a bunch of designers working towards one delivery. Explaining the same constraints multiple times and keeping everyone in the loop was hurting our agility. Ultimately it was really hard to have a clear owner of the design. Each designer did their part, but holding the holistic feature together across the journey became harder. Having a feature specific designer would help with this challenge as well.
Improving the quality of our delivery (challenge #3)
To be able to design as close as possible to the user’s needs, we try to have a deep understanding of the context & behaviors of our users. It requires a variety of research and empathy building. If you have designers switching from feature to feature and always working only on small parts of the holistic outcome, the above mentioned becomes hard to achieve. Especially in the past, when we had less workforce, the designers had to always switch focus from one feature to another without fully diving into one long term ownership of something. This way, we wanted to have a designer fully connected to one feature and fully owning it to dive deep.
Hopefully, now you have a good understanding of why we decided to switch things a little. In the next part, I will explain how this collaboration works in real life.
First and foremost, let me state that these are specific team responsibilities separated from the actual position and seniority. A Senior UX Designer can be a feature designer as well as a domain designer. The same way a junior can work on the above mentioned. It comes down more to the specific skillset a designer has rather than seniority.
Feature designers are responsible for owning a problem and delivering solutions across the entire product. A good example is how we handled baggage management adjustments. We had one designer who owned the managing baggage problem. The role of the designer was to work with research, data, service designers to deeply understand our user’s behavior when it comes to traveling with baggage. Why do people travel with it and when they decide if they need it? How do they weigh it? Together with the PM, they started iterating on concepts of storyboards, user flows, and building a map of different touchpoints of our service, which will be affected. During this exploratory phase, it becomes clear which domain designers should be involved in the feedback loop & ideation. What became very clear during the piloting of this structure was that this role is more suitable for designers who can act as a glue across the company. Maintaining relationships and having solid stakeholder management skills. A few examples of features in our environment:
- Baggage handling
- Fare types
- Booking classes
- Kiwi.com Guarantee
Domain designer (owner)
Domain designers work with domain product managers to make sure the part of the product has a long-term scalable vision. Usually, on our team, those are designers who have in-depth knowledge about a particular part of the product being it checkout, messaging, account management, etc. They have been working in those areas for a long time. They work on implementing features that are specific to their particular domains (but don’t reach far beyond them) and create guidelines for feature designers to make sure the domain is kept consistent. They are also involved in sessions to help steer the features (build by feature designers), which affect their domain. The critical skills of domain designers include strategical thinking and system thinking to ensure that the ecosystem they maintain is scalable. Guidance & feedback giving is also crucial. Domain designers collaborate with our researchers to understand how users explore the specific domain. What are the primary goals of our users and the key elements they expect around a particular domain? A couple of domains in our environment:
- Booking (Checkout)
- Manage My Booking
Let’s take the example of a domain in our environment, “Manage My Booking.” We have Tim — domain designer working on rebuilding the priorities of these sections and how the features should work together. He works with researchers and analysts to prioritize different parts of the product. What are the goals our users try to fulfill at this point in our service? Do people want to mainly see their trip details, or they want to see boarding passes first? Meanwhile, we have Michal (feature designer) working on Service packages across the entire product. You can purchase the level of support service during checkout flow, but the user’s choices affect what she will see on MMB. So Michal iterates on creating a user flow, which is understandable and follows the mental model of our user (persona). He holds critiques together with Tim to discuss the proposal for the part in Managing the Booking. Tim shares feedback based on his knowledge about how users prioritize different goals in “Manage My Booking.” This way, we challenge each other and achieve solutions.
What did we learn so far?
These particular roles bring more space for scaling further. We can have designers focusing on more specific parts of the experience and significantly improve the quality of our delivery. Domain designers can think more about strategies & systems where they see their domains in a year. Meanwhile, feature-focused designers can take a step back from a defined problem and explore the context in which this feature will play a role. It brings clarity into who works on what and what are the team dynamics in it. People outside of the team know who they should approach. It moreover promoted a feedback culture and prompts designers to collaborate often.
Piloting this approach, we thought this would enable us to have more junior designers working as feature designers. The thinking behind it was that focusing on one problem and not having to take on new issues sprint after sprint would be more suitable for them. The truth is that holding together experience across multiple domains needs solid storytelling & stakeholder management skills. It shows that the roles are more about specific design skillsets rather than seniority.
One realization that struck me while writing this piece is that it is tough to write about internal processes. Everything is changing so fast that by the time you are reading, these things are probably way different. Therefore I invite you to challenge any aspect of this approach and feel free to share your ways of dividing responsibilities around design organization.