A challenge that we still encounter regularly is how to combine design work – especially UX work – with an agile development team. And it is clear why this is a struggle: Design work often does not fit within the confines of a typical two-week development sprint. It has to be ahead of actual implementation with its need for research, user testing and interface work – all of which need to be done and defined when development actually starts. Yes, this sounds like a typical waterfall process, and it is – but it can be adopted to work with and alongside agile development teams.
Here's how we do it.
From a Head Start to an Epic Ahead
There is no getting around the basic fact that design work should start from a product's inception. We talked about the importance of UX research, proper positioning, and ideation many times, but one core aspect of these is certainly to make sure that you know the problem that you are solving, understand the people that you are solving this problem for, and have validated your first routes with actual users. All of this happens way before the first line of code is ever written.
This research, concept work and prototyping can happen inside agile sprints, no question. But for the first few weeks (maybe months) it happens in its own space, free from the pressures of immediate implementation. Design needs a head start.
Once it has become clear that a problem is actually worth addressing, design and development grow closer together: "A Head Start" becomes an "Epic Ahead".
This means that design has now created and validated the fundamentals and basic structure, so that new decisions and features fit neatly into this context. This speeds up design work tremendously. Still, being an epic ahead with design work (while simultaneously supporting the current development sprint) is the space that we think is necessary for the design team to produce the outcomes that are needed to build a great product. It involves concept work, testing and validation, as well as the preparation and handover of the actual design files. Fitting this into the same sprint as the development work is nearly impossible and might only work for small, routine tasks. If not adhered to features are developed without user acceptance, resulting in wasted resources. Or worse still, the development gets blocked due to missing design assets.
How this work is organized and reflected in your backlog is something that each team has to figure out. There is no correct answer, as each approach has its pros and cons - be it separate backlogs for design teams, single tasks with sub-tasks for design and development or a big, unified backlog.
However you do it, though, remember to give design the head start it needs. Customers will thank you for it later down the line.
---
Recommended reading:
