Does being Agile mean you’re user-centred?
How does user-centred design (UCD) fit into Agile, a project management methodology designed to manage development in a quick and incremental way?
By definition, Agile is a set of development methodologies of dividing work into quick and short ‘sprints’, allowing for frequent reassessments of project direction and adaptation of plans where necessary.
User-centred design (UCD) is also a framework, focusing on usability goals, user behaviours which aims to put the user at the heart of the process.
But when priorities can change as frequently as every two weeks, how can we as UX designers ensure research and design meet demanding deadlines? Especially when user-centred design has the challenges of involving humans. Wonderful, insight-filled, contradicting and demanding humans.
How is Agile user-centred?
Let’s start with looking at the foundations of Agile via its manifesto and principles.
The Agile manifesto says: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
While there are arguments in the industry as to whether we are designing for ‘users’ or ‘customers’, Agile places the end-‘person’ at the core of its purpose. This very sentence also places emphasis on building valuable software, which is at the core of user-centred design; building products people need and want.
In addition to the manifest, an Agile principle includes “welcoming changing requirements, even in late development.” In mature Agile environments, you’ll find attitudes that are more tolerable to failures and provide opportunity to apply learnings. So, Agile creates the sense that there will be future iterations on features, which gives design teams breathing room to conduct research and apply new findings.
The fast change in priority can also work in our favours as designers. We know that research is never complete. Sample bias in user research can show a pattern in the first set of users, but then show the complete opposite pattern the next week.
For example, we can interview five users who all find and love the primary call-to-action on the interface, for the next five users to then not notice the same call-to-action. The quick change in priorities in an Agile environment allow us to respond to user findings and suggest iterated designs.
For a free, in-depth guide to running user research in Agile Sprints, read our comprehensive e-book:
When Agile is not so user-centred
However, the nature of an Agile environment means that features can be de-prioritised as quickly as they are prioritised.
A common case for designers is a feature being de-prioritised and shelved for months after the feature has been marked as ‘Ready for dev’. This can mean by the time the feature is prioritised, the research is out of date, and no one is entirely sure why the design decisions exist. From this, because the work had been marked as done, there is little to no budget to start the research and design again.
This problem is amplified by the common situation of the original designer having left the team or company. The intimate knowledge of the research is no longer with the team. From here it’s easy for the assumptions and untested design decisions to start to creep in.
The second possible issue comes from the level of detail in research and design documentation. If documentation lacks the research that was done to justify or showcase the design decisions, it is very hard for these design decisions to persist months later, even if you are the designer who did the original research. If you don’t have budget to then test the new designs with users, you lose the user-centred part of your process.
Of course, new learnings could highlight that designs are out of date months down the line. Markets change. User behaviours change. For good or bad and in a matter of weeks or months. If you have a consistent stream of budget for user testing, then an Agile environment is a great way to confirm design decisions of features which may have been worked on ages ago.
However, this depends on business and relies on iterations of features being planned into the workload. As Darius Kumana and Jon Dickinson point out, iterations are often forgotten in planning, leaving no room for designers or developers to respond to user feedback of features.
Agile is about understanding the smallest amount of work needed to be of value to a user. Developers break down their stories into epics and tasks, with the mindset of delivering the feature in its basic form which solve the user’s problem.
Designers often work on features holistically, looking at the ‘razzle dazzle’ version of a feature with all the usability bells and whistles. Then we have to strip the design down into different iteration states, judging which features can solve user problems in the simplest and quickest (development) way.
First version answering the question of “what’s the minimum we can deliver now which solves this user problem?” Second and third versions being “what are the next features users should or could have which will improve this feature?”
Unfortunately, this can turn into, “What’s the simplest design with the quickest development time?”. This in turn strips out a lot of the usability features that users have asked for and contribute to a positive user experience.
Small design tasks paired with continuous development can often mean time is not dedicated to looking at the product holistically. It’s one thing to research each design problem separately, but we must plan to test all final implementations in a product altogether. It’s here that you find usability problems with one feature, caused by another feature that would never have been obvious in siloed research.
Using Agile to encourage user-centred thinking
One way in which Agile helps designers to be more user-centred is through ‘team ceremonies’. As designers we should be attending as many team ceremonies as possible to champion the user throughout every stand up, planning session and refinement.
Planning sessions are when the team discusses the work that will be planned for the next sprint. During these sessions we get the heads up that a feature which may have been worked on months ago or last year, has now been prioritised and may need a sense check on the designs.
Refinements are also a great time for users and research to be championed. It’s here where designers, developers, QAs and product owners come together to understand all the requirements and acceptance criteria for each ticket, so that it’s ready to be built by the developers. Here is where designers can clarify any misinterpreted acceptance criteria and answer any questions from developers.
Stand-ups then provide the opportunity for developers to say when work has been done, so that a designer and a QA can arrange desk checks before the code is pushed for review or merged with a staging environment.
When it depends
Ensuring your Agile environment is user-centred relies on an enormous amount of communication and empathy-building from designers. Tasks which show clear evidence of user value are a lot easier to prioritise. Developers are also more enthusiastic on building stories when they understand the purpose.
Understanding the purpose comes from designers communicating the user value, whether that’s through sharing user feedback and allowing other team members to spend time with their users.
Another challenge of whether an Agile environment is user centred often comes from the differences in working styles between design and development. The Agile principle of: ‘Business people and developers must work together daily throughout the project’ aims to solve this, however the differences in work styles and Agile sprints can make this difficult.
Design work does not fit into two week sprints the same way that development does because designs need to be ‘finished’ before the business can prioritise the work and the developers build the solution. So, collaborating between design and development becomes onerous when developers are building solutions that were designed weeks or months before and designers are working on features for months or quarters in the future.
Here, the empathy needed to be user-centred in an Agile environment is more difficult to build between teams. This can also cause tensions where designers need to be aware of technical limitations imposed on designs and where developers need to balance building what is necessary now and for future features.
Agile as a group of methodologies and user-centred design as a framework only work together when followed. Realistically, businesses aren’t perfect and it can be difficult to even remember all the principles to follow them. So, when the discipline of being ‘Agile’ falls, it’s easy for the discipline of being ‘user-centred’ to fall too.
On the flip side, Agile environments can provide a lot of opportunity for a company to be user-centred. One very core aspect of Agile is the ability to quickly adapt to changes; whether those changes are driven from business or user needs. There are also a number of Agile principles which are complementary to user-centred design, like ‘satisfying the customer’ and ‘daily collaboration’. Then through team ceremonies like stand-ups, refinements and plannings, there are plenty of opportunities for us as designers to communicate the changes and build the empathy with developers, QAs and business, so that we can ‘satisfy the customer’ and work towards a shared vision.
While Agile environments tend to focus on development, there is no reason why we can’t use the opportunities mentioned, like standups and planning sessions to discuss design. Again, Agile and user-centred design are just methodologies and frameworks. It’s down to us as teams to use them, adapt them to our situations and follow them, so that Agile means you’re user-centred.
If you’d like to know more about how UserZoom can help test, measure and improve your own site’s UX, please get in touch!