Does being Agile mean you’re user-centered?

How does user-centered 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-centered design (UCD) is also a framework, focusing on usability goals, user behaviors 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 the user-centered design has the challenges of involving humans. Wonderful, insight-filled, contradicting and demanding humans.

How is Agile user-centered?

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-centered 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 opportunities to apply learnings. So, Agile creates the sense that there will be future iterations on features, which gives design teams the breathing room to conduct research and apply new findings.

The fast change in priority can also work in our favour 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 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 allows us to respond to user findings and suggest iterated designs.

When Agile is not so user-centered

However, the nature of an Agile environment means that features can be de-prioritized as quickly as they are prioritized.

A common case for designers is a feature being de-prioritized and shelved for months after the feature has been marked as ‘Ready for dev’. This can mean by the time the feature is prioritized, 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-centered part of your process.

Of course, new learnings could highlight that designs are out of date months down the line. Markets change. User behaviors 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 that may have been worked on ages ago.

However, this depends on the 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 contributes 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-centered thinking

One way in which Agile helps designers to be more user-centered 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 prioritized 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-centered relies on an enormous amount of communication and empathy-building from designers. Tasks that show clear evidence of user value are a lot easier to prioritize. 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 centered 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 prioritize 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-centered 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.

To summarise

Agile as a group of methodologies and user-centered 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-centered’ to fall too.

On the flip side, Agile environments can provide a lot of opportunities for a company to be user-centered. 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 that are complementary to user-centered 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 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-centered 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-centered.