Clash of the Titans: Agile and UCD
Published: December 18, 2006
Agile software development  has become fairly popular in the last few years, leaving many UX professionals wondering how user-centered design (UCD) can fit into an extremely fast-paced development process that uses little documentation. User-centered design can involve a variety of techniques that provide insights into users’ wants, needs, and goals, including ethnography, contextual inquiry, contextual interviewing, usability testing, task analysis, and others. But all of these take time—time that an agile development process might not allow. There is hope, though. Agile and UCD methods are not completely at odds with each other—and in some cases, agile development can even enable a more user-centered approach. By taking the time to understand the differences and similarities between agile development and UCD, it’s possible to devise a process that is both user-centered and agile.
Similarities Between Agile and UCD Methods
Let’s start by exploring the similarities between the two approaches.
I particularly like Alistair Cockburn’s comparison of an agile development process to a cooperative game: “Software development is a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game.” Thus, according to Cockburn, an agile development method, at its core, is about delivering useful software. According to Rassa Katz-Haas, user-centered design is about understanding people’s needs—so we can provide useful software. She writes: “[User-centered design] places the person (as opposed to the thing) at the center…. UCD seeks to answer questions about users and their tasks and goals, then use the findings to drive development and design.”
A human-centered design approach allows us to better understand the people who use our products, while agile development techniques let us build, test, deliver, and revise our products faster. This is what software design and development is all about: delivering meaningful products to people. So, if these two methods seem to complement each other so well, why is there so much friction and frustration when it comes time to integrate them? A surface examination of the issues can’t answer this question. We must dig into the details of these methods, where integration gets more complicated.
Differences Between Agile and UCD Methods
Defining a development process is a tricky thing. The most challenging aspect is that of defining how people are going to work together. People who have egos and opinions. People whose skills may be undervalued or who may not be fully committed to the process. Define a process too strictly and it becomes unbearable and unadaptable; define it too loosely and there is a risk of not including the right people at the right time.
Agile’s iterative development cycle is one of the method’s strengths, but it also makes for some tight deadlines. As the now infamous interview between Alan Cooper and Kent Beck  shows, the timeline is perhaps the most controversial aspect of agile methods. In such a high-speed development cycle, do we have time to fully understand users’ needs? The short answer is no. The long answer: If we’re defining users’ needs during development—even in an agile development process—something has gone horribly wrong.
Case in point: One of the engineering teams I’ve worked with used six-week cycles and two-week iterations. My original plan was to stay one iteration ahead of them, but that proved problematic—especially when I got to the second iteration. By that time, I was supporting revisions to iteration 1, supporting development on iteration 2, while designing for iteration 3. Needless to say, I drank a lot of coffee and burned the midnight oil for several weeks.
Redesigning a Development Process
What to do? I started out by taking a deep dive into agile development methods. I needed to better understand the theory behind these methods before I could even begin to resolve the friction between the two processes. In doing this study, the first thing that became apparent to me was that agile is a method of development. It’s certainly not a research process, and it’s only loosely a design process. Despite what many proponents of agile development methods would have you believe, they cannot replace the need for some up-front user research or design. Agile proponents may cringe at that statement, but I stand by it. That said, though, while agile methods can significantly reduce the amount of up-front design that’s required, it does not, in any way, reduce the time user research requires.
User research and agile do not play well together. The time to conduct field research is not during development. Research should occur before any design or development work begins. This may seem obvious, but is an extremely important point—especially when you consider that agile development is about writing code as early as possible and delivering working software as often as possible. Conducting user research slows things down. However—and I’m probably preaching to the choir here—user research provides insights into customers and their needs that will help a product team to identify useful new features and products as well as to prioritize those features and products for development.
The outcome of user research is documentation that describes users and their needs and goals—for example, personas that represent a product’s primary and secondary audiences. Many agile development methods employ user stories—which are somewhat similar to scenarios—and personas can become the main actors in these user stories. By creating behavior and goal-based personas, you can make your user stories much more effective. At this stage—before design has begun—user stories should be fairly high level and detail only how people will generally interact with your product.
I recommend involving a representative from engineering in your field research. By seeing users in the wild, engineers will develop some empathy toward them. Of course, doing this is helpful no matter what type of development method your team is using. Also, include this engineer in the process of developing personas and user stories. Getting buy-in from engineering is critical to the successful use of personas and user stories during the development cycle.
Once user research is complete, and you’ve created your personas and high-level user stories, it’s time to define and prioritize product features.
Feature prioritization is important in agile, because it lets engineering focus first on the features that make up basic working software. There are many different prioritization techniques—some belonging to the different agile methods. Of all the techniques for ranking features I’ve encountered, I prefer Janice Fraser’s approach , because it’s simple, objective, and accounts for three important perspectives on product definition: the business, users, and technology. Using her prioritization technique, stakeholders rank the importance of each feature to the business, UX professionals rank the importance of each feature to the users, and technical analysts rank the feasibility of implementing the feature. Once they have all ranked the features, the product team combines the different rankings and compares them to identify the most important features.
Once you’ve defined the feature priorities for your product, it’s time for design. Most agile development cycles comprise a time-boxed development period, or iteration, of 2–4 weeks, and the expectation is that a developer will have produced working software by the end of that cycle. As a designer, you should focus your efforts on designing the features in the next one or two iterations. If you get too far ahead of the engineers, you run the risk of requirements changing, necessitating a lot of rework. However, you need to stay far enough ahead so you have time to do usability testing and remedy any usability problems in the previous iteration, support development on the current iteration, and design for future iterations. If your development team’s iterations are brief, I recommend designing at least two iterations ahead. But with four-week iterations, designing one iteration ahead will probably be sufficient.
All design should start with the creation of detailed user stories. Be sure to involve the engineers who are developing related features in creating the user stories. You must have their buy-in for this technique to be effective. Once your user stories are complete, create your design documentation of choice. Keep in mind that there is a delicate balancing act you must manage. First, you must consider that you don’t have much time for producing a lot of design documentation, so the documentation you do create needs to be as concise, effective, and useful as possible. I’ve found wireframes and workflows to be most useful for engineers.
Second, in many agile development methods, documentation is nearly considered taboo. Some would say that the attitude “don’t document, do” is a core strength of agile, but where does that leave designers, whose main deliverables are information architecture diagrams, usability reports, wireframes, workflows, specifications, prototypes, and a myriad of other documents? This documentation helps designers model user interactions with a technology product, so it’s important—especially when you consider that it can actually reduce development time by identifying common patterns and eliminating unnecessary steps before any code has actually been written. The challenge, then, is to find a balance between providing too little documentation and too much documentation. Determining how much documentation is enough is not easy.
I have found that defining the 20 percent of a feature that includes its most important aspects gets it to a relatively good place. You can generally define and design the most important user interactions for a feature. Then, whiteboard sessions throughout an iteration let you define the remaining 80 percent.
Develop and Test
One of the core principles of agile development is its focus on delivering working software frequently. In some agile methods, a customer review of the working product even caps each biweekly or monthly iteration. In addition to or, sometimes, instead of these reviews, you can run iterative usability tests. According to Jakob Nielsen, if you do three rounds of usability testing, testing five people in each round, you can discover the majority of usability problems . With agile development, you can test and revise a feature over three iterations, allowing you to discover and correct most usability problems before launching a product.
Conclusion: Integration of Agile and UCD Requires Collaboration
In this article, I’ve described some of my experiences and shared my thoughts on how to integrate agile software development and UCD. Of course, the goal for any process is to create something that will work for both the designers and the engineers working on a project, not to impose a canned process on a team. What’s actually pretty amazing about agile is that, at its core, it’s simply a manifesto that emphasizes the importance of collaboration to delivering useful, working software —a manifesto that nearly anyone can get behind. Regardless of whether your development team adopts agile techniques, they hold plenty of valuable lessons that make it worthwhile for UCD practitioners to learn more about them.
- There are many different agile development methods, including Scrum, Crystal, and XP. In this article, I focus on only the concept of agile software development, not any particular agile method.
- In “Extreme Programming vs. Interaction Design,” Elden Nelson interviewed Alan Cooper and Kent Beck. By the end of their discussion, neither seemed to understand the value of the processes the other had defined.
- In “Setting Priorities,” Janice Fraser outlines a simple and effective way of prioritizing features. The only thing I would consider adding is a column for weighting the feasibility of assigning a UCD resource to define a specific feature, which would be especially helpful on product teams where one designer is supporting several engineers across several features or products.
- Jakob Nielsen makes a strong case for limiting testing to only five users in “Why You Only Need to Test With 5 Users.”
- If you are interested in learning more about agile, you can read the full “Manifesto for Agile Software Development.”