3 ways to organize UX design within agile development

How can you best ‘adopt’ UX designers in your product teams? As a digital product manager, you’ve probably already had this question in your stomach. Inspiring organizational models such as the Spotify Model make our agile hearts beat faster, while in practice we often struggle in a rigid top-down hierarchy.

In organizations you often see that SCRUM product teams are the first to arise within software development. Pondering how such a department should work, agile trial balloons are released. The moment the agile methodology is proven, and a framework such as SCRUM has been implemented, you will see one or more teams consisting of developers, testers and business analysts. With good luck you will have an architect ‘on the side’.

With front-end development you are dependent on a user experience or web designer. But how do you manage the collaboration between the product team and this designer? Do you make him or her a permanent part of the team or do you keep this person out of the proverbial door? In this blog article I will explain the different options for you.

1. Separated and assigned per assignment

Organizations where designers are housed in a separate team or department often initially work on a project basis. Designers are assigned per project (or assignment) to provide a product team with research, advice, wireframes, prototypes, mockups and web designs. With this, such a design department works as a shared “resource center” where assignments are requested, tested and assigned by means of a procedure. Depending on the working method, such a design team manages its own (separate) backlog.

Advantages of this approach

Promotes internal knowledge sharing within design team;
Gives the possibility to assign the right expertise more flexibly and efficiently to projects and assignments;
Offers more room for joint UX research and strategy formation;
Gives designers more variety (and challenge) in terms of assignments;
Leads to a more consistent output from the design team;
Makes UX a more visible area of expertise.

Disadvantages of this approach

Often leads to delays because a “waterfall” method arises and schedules have to be coordinated;
Designers are further away from the product team (feel less part of);
They are only partly involved and have less insight into the end product;
They feel less (or not) responsible for the final delivery of the product team;

2. Integrated and 100% allocated

The opposite way of organization is a situation where the designers are fully integrated into the product team. Each product team has assigned its own designer. UX activities are included in the backlog and therefore also follow the regular prioritization, analysis and refinement process. The product owner is in control of UX activities. In such a setup, designers often rotate periodically (every 12 months, for example) between the different product teams. This is done to ensure a healthy variety.

Advantages of this approach

Designers are integrated into the entire product cycle (from ideation to delivery) and therefore feel more involved and responsible for the end product;
They acquire a stronger affinity with technology and MVP/lean approach;
More qualitative and effective end products through more input of UX during all iteration layers;
Scaling up is easier: an extra team means an extra designer;

Disadvantages of this approach

Danger of too much focus on delivering, which can be at the expense of research and quality;
The overall user experience quickly becomes fragmented and inconsistent;
One designer per team may eventually feel isolated (/insufficient opportunity to share knowledge and experience with co-designers);

3. Hybrid UX organization

During the introduction I already mentioned the Spotify model. This model is “a human-centered, autonomous approach to agile scaling that emphasizes the importance of culture and the overall network.” It has helped Spotify and other organizations increase innovation and productivity by focusing on autonomy, communication, responsibility and quality. But what is the link with this article?

Learning from Spotify

A part of the Spotify Model is perfectly applicable to organizing UX resources in product teams. Spotify works with so-called “squads”. With a SCRUM team, a squad focuses on one feature area. The big difference is that a squad decides for itself which agile methodology / framework (such as SCRUM and Kanban) it wants to use.

Although squads are autonomous, it is important that specialists (such as designers) align with best practices. So-called “chapters” form the family that each specialist has and helps to maintain standards in a discipline. Chapters are typically led by a senior specialist, who may also be the manager of the team members in that Chapter.

Back to our issue. To get a good mix between options 1 and 2 from this article, you can learn from the Spotify Model.

Hybrid model

In our example, the organization can be set up as follows:

More generalist UX designers (short for “UX”) are divided among the different product teams/ squads. Based on the feature area (and its need for UX) you decide to assign one designer or several. More specialized designers, such as senior designers (“SUX”) or usability researchers (“UR”), have been placed in a separate cluster. These specialists provide support to the product teams. The entire UX discipline together form the UX chapter.

In this way you maintain a good cohesion within the UX discipline, but you ensure that the various generalist UX designers are more involved and responsible in the end products that the product teams deliver.