In the last four years, the UX design team, in collaboration with the Product owners and Engineers, explored three different team structures. We tried the embedded team structure, centralized and a hybrid of the two. Currently, the UX team is involved in all stages of product development, from strategy to delivery.
My exploration of Agile methodologies began in 2014 when I joined Studyportals as a UX designer and the first Scrum master. In collaboration with the Engineering leadership and the teams, we established a Spotify-like organisation inspired by the Spotify culture videos (Part 1 and Part 2). I described part of that setup in the presentation at UX Camp NL in 2016. Since then, we evolved our processes and structure to place UX more strategically.
While leading the UXD team, some of the changes were initiated by me, my design and product colleagues, retrospective feedback from the team or the company structure changes.
Studyportals is a leading education choice platform visited by over 44M visitors in 2020 alone. The platform lists over 160K courses from more than 5K educational institutes on six portals like Mastersportal, Bachelorsportal, PhDportal.
Studyportal's mission is to make sure that no student would miss out on an education opportunity due to a lack of information. Studyportals helped at least 485 000 students to find their education.
The rapid growth of the Engineering and UXD teams posed a range of challenges. The biggest one was to be ahead of the development teams when it comes to user research. We already ran bi-weekly user tests. Mainly we tested what was already released, which lead to potentially developing features our visitors don't need.
Below you can see a simplified user research flow we had at the time with an approximate sample sizes guidance for each research method.
To ensure all the teams understand our users, every product team got a UX designer. That helped to grow the design maturity of Studyportals and the autonomy of the product teams. However, having designers in the different teams had some shortcomings:
- The quality and consistency of the product suffered.
- Fewer opportunities to specialize in the different areas of UX.
- Less diversity of the projects for each designer.
We wanted to reduce the shortcomings of the embedded structure and find a way to be involved in the product strategy.
The five behaviours of a cohesive team
To define the next step for the team, we did a team assessment based on the book ‘The Five Dysfunctions of a Team’ written by Patrick Lencioni.
Every designer independently ranked 38 statements about our team on a scale from 1 to 5. On the graph below, you can see that we scored quite well overall, but the Accountability behaviour had some room for improvement. This behaviour is typically the most complicated to master, and the fact that all designers were distributed in separate teams gave us fewer opportunities to challenge each other.
To create a stronger design community and elevate design quality, we introduced design critiques, product team progress updates and blocked half a day a week for collaboration and pair design. Only the first initiative had lasting success and went through numerous process improvements. The rest took a different shape entirely.
We got inspired by a great article about design critiques at Figma when we were defining our goals:
- Elevate quality & encourage consistency.
- Get feedback on the product.
- Unblock people & generate ideas.
Our new format is lightweight and open for the guests from the other departments. In the new critique structure, the Product Owners get the product feedback together with the UX designers.
Each critique takes just 30 minutes and has a simple structure:
- The presenter states the goal, type of expected feedback, context and the challenge.
- Guests note down the feedback separately from each other (in Figma or Miro).
- The presenter clusters the feedback and asks the questions she/he has about the feedback.
The simplicity of this format helped us to run critiques frequently, improve design quality and reduce our biases.
Thanks to the diverse backgrounds in the UXD team, we covered a wide range of topics like continuous user research, student and client journey mapping, design system and Studyportals design maturity scale. Each topic was led by a designer who was the most senior or most enthusiastic about each area. Designers worked on these initiatives in parallel with their regular tasks in the product teams.
Because we believe that it's faster to grow together, we held the team hard skills evaluation meetings every year. The format was loosely based on the Building an enterprise UX team article. We looked at our combined skills within the umbrella of UX skills (user research, interaction design, visual design, etc.), discussed our growth plans and how we can help each other to become better designers. For instance, we identified Interaction design, Usability testing and Prototyping as our strongest areas. These sessions also helped to see the gaps and areas we chose to rely on the other team's expertise, like UX writing in our case.
For the designer's growth scale we adopted a common system, from Junior to Senior and branching to the Lead and Team Lead levels. As not everyone wants to become a manager the role of the Lead was introduced as a specialist track. Each designer can progress within the scale with experience and growing area of their influence in the company. Junior designers are stimulated to become self-sustainable as soon as possible and grow to the Medior position within two years. Medior designers are expected to exhibit leadership skills before progressing to the Senior level.
Every designer is responsible for their own personal development and monthly personal growth meetings. During these meetings we look at soft and hard skills development, non-urgent feedback and future ambitions. As a team of driven designers we tried to visit and present at various conferences, explore design and research methods and collaborate with the UX teams outside of Studyportals. For instance in 2017, we organised three cross-company collaborations, attended 12 conferences, spoke at five of them and released three Medium articles about our process.
Moving the UXD team focus to the product strategy level was one of the most difficult challenges. Involving Product Owners in user research, running design sprints, defining our responsibilities and running multiple workshops together reduced resistance from both sides. And as a result, since the summer of 2020, we planned roadmaps together, and the new ideas went through validation before coming to the product teams backlogs.
Additionally, we are collaborating on user research and use its results as one of the main inputs for the product strategy. One of the regular methods we use I described in my article about measuring user experience.
After moving designers out of the product teams, we gained more flexibility, improved design quality and consistency. However, not being present in the product teams has a risk of losing connection with the engineers, especially in the long-term. To reduce this risk, we join relevant backlog refinements, organise story kick-offs, share and collaborate on the user research. We can continue to grow the company's design maturity further with this setup while being mindful of its limitations and adjusting when necessary.
For the delivery and discovery prioritisation, we moved from Scrum to the Kanban process. While product teams run sprints, we have a continuous backlog that we maintain with the Product Owners. Every week there is a possibility for adjustment to the incoming stories after we discuss and scope them together.
- There is no one correct design team structure that would work for all companies. The structure should evolve together with the design culture and company objectives.
- Not everyone is a designer, but everyone makes design decisions. As we can't control everything, we as designers should be ready to facilitate better design decisions.
- It's essential to balance large projects with quick wins to keep the motivation high and impact visible.
- As a leader, you have to take more responsibility, but it is crucial to understand how far your responsibility goes.
- It was challenging to ask Product Owners to facilitate user research as they were already busy with other priorities. However, after my design colleague challenged me about it, we involved the Product Owners in generative user research, our process and understanding improved immensely.
- A larger team can lead to better designs but doesn't guarantee efficiency.
- Dual Track Agile: Level Up Enterprise Product Design with UX
- Org Design for Design Orgs
- The Five Dysfunctions of a Team: A Leadership Fable
- Building an enterprise UX team
- Design critiques at Figma
- A Growth Plan for Designers