Integrating UX into agile teams. Part 1: 15 things to consider for teams and process

8 min readMay 5, 2021

Birds on 4 wires. One bird alone and the other in a group.

For designers new to agile or trying to figure out how to work better in agile teams, I hope this list gives you some starting points. For teams wanting to improve alignment between development and design, I hope this gives you some new perspectives. I know this isn’t a new topic but it’s my own personal experiences.

Firstly it’s worth understanding the role and value that a UX designer brings to a team. A UX designer does NOT just produce the UI for the devs to build. The ROI from having the UX discipline in a team is ultimately the reduction of risk. The risk that the team builds things that aren’t needed, or don’t meet the users’ needs, and the risk that the delivered solution isn’t usable or doesn’t meet brand values.

I learned agile ways of working in the Masters I started in 2001 and from working in agile teams for the last thirteen. My learnings come from some amazing people and experiences which I’d like to share with you.

I can remember my first client-side agile project at the BBC. How hard it was to let go of the desire to design the complete experience upfront. To research every aspect before even considering sketching the solution. It was like the stages of grief: Denial, Anger, Bargaining and Acceptance; Before learning to love the deeper level of collaboration and the lack of delivery of a tombstone functional specification.

At Sensis working on Yellowpages I was given the remit to not only design a new responsive website but redesign the way the design team worked. The whole team sketched together (I even got senior management drawing on the whiteboard), incrementally developed a design system, reduced release times from months to weeks, boosted interactions by 20%, and had a whale of a time doing it.

Noisy, argumentative, but a brilliant experience working with a team open to change and experimentation. The Devs came up with excellent UI ideas and two particularly rewarding moments were the shoulder taps from the Devs instructing me that we weren’t sketching enough and overhearing another developer correcting a member of my team on a psychological principle of design we had discussed at the whiteboard.

There are so many levels of maturity of integrating design into the agile process; it’s hard to know how to make improvements. I’m not saying that all or any of these ideas will apply to your team but please consider them as food for thought. I’m also not an agile evangelist. If waterfall works for you then that’s great! I’ve seen results from both but for me, when it works well, agile can be joyful.

This is pretty much a brain dump of things that worked for me and learnings from some of the experts in the field. Some of these ideas you might have encountered before. I’m definitely not taking credit for the items in the list and will provide citation links for further reading.

Probably my biggest source of ideas to try comes from Jeff Gothelf and his own list https://medium.com/swlh/5-rules-for-integrating-ux-with-agile-scrum-b048babb9a89 which I’m shamelessly plagiarising as they have worked on the teams I’ve been on.

Teams & process

1. One team: A dedicated designer on each team

With no dedicated designer on a team, what you have is a software engineering team. Teams will deliver a user experience, but it will not be of the same level of quality without a designer’s input. You run the risk of just falling into the build trap of becoming a feature team

A minimum of one designer is needed per team. Design and research can become a bottleneck so an additional designer is ideal. Multiple teams? Hire a design lead to ensure consistency.

2. A developer is someone that develops something of value, not just code

Scrum states there are only 3 roles in a team. Product owner, scrummaster and Developer. The developer role often understood just to be engineering roles. Personally, I think it means people who contribute to developing a solution, not just produce code.

A Cross-functional, multi-disciplinary team will deliver better outcomes. Ideally designers should have a T-shaped skill-sets. One deep area of expertise with a broad range of secondary skills (UI, Research, Ux design).

No, this doesn’t mean you have to produce production code as a designer. We call the mythical Swiss army knife designer a Unicorn for a reason (they are more or less a myth).

Having a Frontend dev who understands the principles of design is massively valuable just as a designer who understands the constraints of code is almost a prerequisite.

3. One backlog: Design shares a first-class citizenship in the backlog

Development, copywriting, business analysis, quality assurance, user interface, research, should go in one backlog. A user story should be a problem to solve and most problems require effort from lots of disciplines. Prioritise together with the team doing all of that work. A good team refines, prioritises, retros, showcases works and stands up together (and goes to the pub together). Working together promotes closer collaboration and working relationships.

Reduce the need to reach outside of a team to produce solutions. Include the required disciplines inside the team. Teams (and not just the designers) should own research and design effort. Use co-design and workshops with stakeholders to get early direction rather than playing requirement tennis.

4. Water-fail or fragile

A process that is a hybrid waterfall and agile process… is a waterfall process. If design is outside of the team and the process then you are risking losing the benefit of agile ways of working. And if the whole team aren’t working together to solve problems you are not getting the benefit of cross discipline collaboration.

5. Not just feeding the dev wall

Emphasis on outcome not output: an extra sprint to know more about the problem will reduce rework, wasted build time and produce better quality. Deliverables such as personas or customer journey maps might not directly influence the output but can have a huge impact on outcomes.

6. Outcomes as prioritisation filters for the backlog

Use outcomes and team goals as lenses to filter backlog items. If the desired outcome doesn’t align then don’t work on those items. Don’t fall into the build trap of just churning out features. Without research to understand the value of the outcomes you are taking the risk of relying on assumptions.

7. Estimate and prioritise

Stories should be Estimated, prioritised and refined together as a team. This includes the design work, as it’s an opportunity for all members of the team to understand what is going into a sprint. The total effort of all disciplines involved should contribute to estimates.

8. Track the velocity of the entire team effort

Track the complete effort of all the team members not just Devs. Enable the team to know how long from start to finish a piece of work will take. This helps to make work more predictable. Without doing this it’s hard to predict where bottlenecks will happen or the amount of effort that truly went into a solution.

Many managers seem to think that design just magically happens and as such don’t feel the need to track it. Don’t get fixated on the velocity, it’s a tool to estimate how much work can be completed not an objective in itself.

9. Reduce context switching

Multitasking is a myth. Typically 20% of productivity is lost for every distinct problem worked on. Sharing a designer across 2 teams can equal 40% wasted time if the work is too different. Prioritisation and sequencing is better than trying to multitask. To a point hiring an additional designer is more cost-effective and will deliver better results than stretching one too thin. (consider the stress levels as well…).

10. Muda (無駄), Mura (斑) Muri (無理)

Lean principles that work very well for all teams.

They are especially good principles to consider for design effort

Mura = reduce unevenness, non-uniformity, and irregularity of work. Understanding users’ needs through research reduces the amount of Muda
Muri = reduce overburdening a person’s workload. Most teams have fewer designers than engineers. To avoid Muri design work needs a work in progress limit.
Muda = reducing wastefulness, uselessness and futility. Align the cadence of design to development work and set a schedule for regular research.

12. Set a WIP limit

In a sprint a designer can end up doing multiple activities. Research, UI, user testing, running workshops and experiments. Stress has a direct negative impact on creative problem solving. An overstretched (and stressed out) designer won’t produce the same level of solution.

Set an achievable work in progress limit. Work needs to be sized, prioritised and agreement needs to be made on what goes into a sprint. Once a sprint starts no extra design effort should be added. . (say no to adhock “can you just redesign…” requests).

13. Shu (守)Ha (破) Ri (離) — iterate on how you work not just what you work on

Shu Ha Ri is a concept of learning that comes from martial arts.

Adapting to including designers into a team can be difficult: designers might be used to Waterfalls, developers might be frustrated that output seems slower.

Start with a framework (Scrum, Kanban, SAFe, etc) but purposely think about how you will adapt.

Shu: is follow the master. = Establish frameworks to follow.
Ha: Understanding the principles and branching out = Adapt to the way the team works.
Ri: Following your own principles = Let the team establish their own ways of working.

There is not just one way of working. Teams are going to be different. Set guide rails but let individual teams figure out what works best for them. Experiment with different approaches: Staggered sprints? didn’t work! Try a Just in time or dual-track approach.

Retros are your friends! Be open, candid and constructive.

14. Kaizen

Continuous incremental improvement. Both in terms of what is produced and how the team works together. For me this is the heart of an agile mindset but one of the hardest thing

Think about continuous discovery and continuous delivery rather than big upfront discovery or design effort. It’s hard as it flies in the face of our desire as designers to understand the holistic nature of a problem. Fundamentally if agile (and UX) is about risk reduction then spending more effort upfront without knowing the feasibility might not reduce risk. If design is incorporated into an agile team then there will need to be some acceptance of rework and getting some element wrong. (QA is a function to spot development bugs just as Usability testing help weed out issues with the experience).

15. Stub stories

User stories should be informed by research. Don’t go straight to detailing the solutions. Write the story as a hypothesis rather than a solution, a “stub” for the final story. kill the story if the research demonstrates its low value. It’s hard to do this on every hypothesis so prioritise the ones you know least about.

Once you have some certainty that it’s a problem worth solving, collaborate with the team. Sketch together to define the solution. Don’t then just waterfall definitions from one discipline to the next.

Use low-fi design to quickly explore the stories as a team and validate the solution. Is it viable (has business value), desirable (something that customers want) and feasible (something that can be built).

I’m in the process of writing parts 2 and 3 where I’ll discuss some of the ideas and principles I’ve used in agile research and agile UI design.