Scaling user-centred design
Last week I published a post about making design work in large organisations. All about design leadership and the importance of becoming a design-led organisation.
One of the challenges I’ve faced over the last year is how to build and scale a user-centred design function for a large organisation.
To give you something more practical. This is the model that I now use to think about scaling design for agile delivery teams.
Some people call this the ‘Spotify model’ and it’s close to that.
We’ve drawn our own illustrations, but acknowledge these are based almost entirely on the original Spotify ideas. I should also say that we had stumbled upon this and were already doing something very similar before someone first shared the Spotify model with me.
If you’re familiar with the Spotify model, I’m going to explain the ideas more broadly because we don’t follow the terminology they use – you can read more about tribes, squads, chapters, and guilds here if you want to learn more.
As the illustration above shows, people working in specialist roles are all part of different agile delivery teams. For example, most of our delivery teams have someone responsible for Content Design, Interaction Design, User Research, etc. They all work to a Delivery Manager and a Product Owner as part of these teams.
In agile teams, this means that they sit together, have daily stand ups, and work together over 2 week sprints.
This is organised so most of these delivery or feature teams are part of a wider group of services like ‘retirement’. These services are then based in the same location.
On a day-to-day basis this works well but has taken time to get right as we’ve developed a community of strong Delivery Managers.
The very best Delivery Managers make sure people in their teams can do their best work, and that they do it collaboratively, delivering at pace. Working with our design team, they remove anything that might stop this from happening.
The importance of cross-cutting design teams
Looking at how we work, the most important thing to highlight is the principle of a ‘cross-cutting’ design team.
The significance of this is that we haven’t just hired designers to work individually in agile teams. We’ve hired people to be part of a design team. This way they also work together, no matter which delivery team they’re part of and which office they’re based in.
So, to recap. Everyone is ‘task’ managed by a Delivery Manager in an agile team on a daily basis but they all come back together to work as a design team. That means I’m then responsible for making sure the design team functions well together.
When we get this right the impact of user-centred design starts to cut across all of our delivery teams and, when it really works, the entire organisation. We work independently across a large portfolio of work, but importantly, we’re also working together, collaborating and sharing.
Practically, this means designers communicating with each other daily to solve common problems, share knowledge, and work on design patterns. All things that start to help the organisation think outside of individual features or product delivery.
Most importantly, and this is the biggest challenge, we don’t work on the same problem separately, without knowing or before talking to each other.
Understanding that service design is more than delivery teams
I’ve found that a cross-cutting design team is the only way to really start to get an organisation thinking about service design.
Individual delivery teams are rarely responsible for an entire service. For us, it’s the difference between a single transaction and looking much wider at the service model of what government should be delivering to meet user needs in areas like retirement or health and disability (shown as groups of delivery teams in the illustration).
Bringing everyone back together
When we bring everyone back together how we work looks more like this.
This is a cross-cutting design team functioning as a single user-centred design community.
We do this with some simple principles which we’ve used for building a design community. We have regular face-to-face meetings for everyone, and this requires the right tools as we’re a large distributed design team. We’ve found that Slack channels and mailing lists have worked well to support time with the right people in the same room.
Community of practice
The idea of a cross-cutting design team is all part of developing strong communities of practice.
This is about more than just design. It needs to expand to all job families within agile teams and delivery environments. If you want to know more I recommend Emily Webber’s book – Building Successful Communities of Practice.
You have to work hard to build a community of practice. But I’m convinced it’s the only way to scale design teams properly for agile delivery.
This is my blog where I’ve been writing for 18 years. You can follow all of my posts by subscribing to this RSS feed. You can also find me on Bluesky, less frequently now on X (formally Twitter), and on LinkedIn.