Written by Henry Poskitt, originally published in July 2014
What is the problem?
Since the Agile approach to development became an industry standard, external design agencies have had to learn to adapt their approach to accommodate the sprint cycle system.
On the face of it, User-Centred Design (UCD) and Agile are not that different. Relatively short iterations, or cycles, of work are fundamental to both processes. Designers design and test and review, refining as they go. Agile developers operate in sprint cycles, typically pushing out chunks of testable functionality every two weeks.
Where does the disconnect occur?
It is a question of world-view. UCD is obsessed with the big picture. It is design that likes to take in the macro-level architecture of an application, as well as the micro. Designers want a story with a beginning, middle, and end, based on a user’s experience, before they begin designing.
Compare this to the Agile approach to development, a fundamentally fragmented model that focuses on producing individual finished pieces of functionality, one at a time. In the Agile model, those pieces are not planned at the same time, which increases the risk of producing an application that lacks coherence for the end user.
How do Agile and UCD speak to each other?
The Agile developer’s question might be: how can a big picture approach to design effectively serve development that progresses in isolated spurts? Isn’t this the Big Design up Front (BDUF) approach we are trying to avoid? On the other hand, the user-centred designer might say: how do you produce discrete chunks of designed functionality without losing sight of the big picture?
What is the solution?
One way to tackle the issue is to mimic the sprint cycle structure of an Agile process within a UCD approach, while staying true to the principles of research, testing, and review. It is essentially a hybrid version of the two – Agile UCD, if you like. This method started as a coping mechanism among the Frontend.com UX design team, but over time it has evolved into a more formalised system.
At the Macro Level
Our UX design teams like to start projects by generating an information architecture (IA). It is a two-part approach. We call it ‘across and down’. We take a first pass across the entire application and generate a superficial, high-level architecture of the product. This gives an overarching, end-to-end picture, satisfying the designer’s desire for coherence.
At the Micro Level
The next step is to drill down on specific parts to find out in detail what is going on. It is an example of designing from specific to general, or ‘bottom up’ design. Detailed design addressing a few specific examples can be used to develop a more generic solution that can be applied throughout the application.
Forget the page
Paradoxically, even though we always keep the big picture in mind, we reduce everything within that to a small set of UI components. Essentially, we forget the page. Instead of thinking in terms of pages, we think in terms of small pieces of reusable functionality, single items that will sit together on pages. The real advantage of these pieces of functionality is they are flexible and extensible, meaning they can be applied repeatedly across the application.
Get ahead of the scrum
Once the IA is generated, we plot a series of design iterations that track the sprint cycles of the development team. As is common when UCD teams work with Agile developers, the plan is offset by up to six weeks, so the design is delivered into the individual sprints ahead of time. This means the developers always have concrete, user-tested UI to base their work on.
UCD and Agile are two systems that have developed separately, share superficial similarities (in terms of featuring iterations or cycles), but are based on fundamentally different worldviews – the holistic versus the compartmentalised. The system described above is a solution in flux that will continue to adapt and grow as the Agile approach to development is refined.