Clash of the Titans: Agile and UCD

By Richard F. Cecil

Published: December 18, 2006

“It’s possible to devise a process that is both user-centered and agile.”

Agile software development [1] 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

“An agile development method, at its core, is about delivering useful software.”

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

“Agile’s iterative development cycle is one of the method’s strengths, but it also makes for some tight deadlines.”

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 [2] 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

“Agile development methods … cannot replace the need for some up-front user research or design.”

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

“User research and agile do not play well together.”

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.

Feature Prioritization

“Feature prioritization is important in agile, because it lets engineering focus first on the features that make up basic working software.”

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 [3], 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.

Design

“Focus your efforts on designing the features in the next one or two iterations.”

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

“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.”

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 [4]. 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

“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.”

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 [5]—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.

Notes

  1. 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.
  2. 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.
  3. 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.
  4. Jakob Nielsen makes a strong case for limiting testing to only five users in “Why You Only Need to Test With 5 Users.”
  5. If you are interested in learning more about agile, you can read the full “Manifesto for Agile Software Development.”

12 Comments

Great article. I like the author’s reinforcement of the fact that an agile process is a development process. Here are a couple more questions to promote some additional chatter:

Using the approach described above, where is your first opportunity to get feedback from stakeholders and users about a particular design direction?

How / where does QA become educated on the desired behavior of the application?

A well written and useful article; particularly the point:

“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.”

Absolutely vital IMO. When I used to work more on the development side of the house, I felt like I was working in the dark if I didn’t have any contact with the client, let alone the people who were actually going to use the Web application—even if I did have good documentation.

At those times, I would very much have appreciated being more involved at that level with users and interaction design.

Good reading. Like the importance of user research to help drive design. Suggest this is still a major flaw in most projects where research is ignored or not invested in—where everyone wants to jump into design and build quickly, because it’s seen as the fun part.

Nicely written. This does a great job capturing a tough question.

Our recent experience doing interaction design with an agile development team—at Cooper of all places ;)—suggests that there might be a difference in the compatibility of the two approaches based upon the complexity and novelty of the system being constructed.

If you’re working on something that is a somewhat known beast, like a point-of-sale or help desk system, it seems like it might be workable that the development team start construction on some architecturally significant features while the design team does research and modeling—personas. In projects like this, the course corrections, or refactoring, motivated by the interaction design may be reasonable, especially if the development team is actually agile.

For large, complex, and somewhat unknown systems, our experience is that the development team needs to do upfront research just as much as the design team, and incremental iteration doesn’t necessarily ever result in a viable architecture, unless there is dramatic revision. In these cases, it behooves everyone to do upfront research and requirements definition.

Hi Richard,

Thanks for a well written article. It highlights many issues that I have found are key to a successful agile/UCD project. I have recently been lucky enough to be involved on two such projects—one with a successful outcome—that is, within deadline/budget/user approval and in its “Maybe Later” phase; the other delayed, over budget, and risking its intended delivery into the competitive market. I have since used the findings as a case study presented as my postgraduate dissertation.

Your point about “up-front user research” was one of the underlying factors behind the successful project and cannot be overemphasized. Our team conducted a user/design research exercise before and during the agile quick-start phase. During this period of concentrated activity, we endeavored to ensure that at least one team member from each discipline was involved in each activity—research, design, and coding. An atmosphere of shared vision emerged—supplemented by complementing rich data. One small example to illustrate: We found that by enhancing the agile stories with user personas and scenarios, we transformed a one-dimensional task-oriented description into a 3D epic story! One other point to note I think is that buy-in—for both agile and UCD—from the very start by all stakeholders is essential. In fact, a brief induction would be helpful.

At first glance, the marrying of agile/UCD may appear a collision course to mayhem. However, if approached sensitively, the attraction of these two opposites may provide for a truly effective mechanism for the successful creation of useful, usable systems.

One useful article I found was by McInerney, P., and Maurer: UCD in Agile Projects: Dream Team or Odd Couple?

Working one or two iterations ahead is great to allow the design team to get ahead a step, but it denies a multidisciplinary approach to design. The ideal design scenario brings the designer out of the ivory tower and in front of the project team, to facilitate a collaborative process.

I’ve found that work to be done ahead an iteration should be limited to discovery work only. This way, the design team can do the research, be ready to impart this knowledge—summarized—to the project team, who can then engage in collaborative, informed design during the scheduled iteration.

Any design, beyond discovery, is done ahead an iteration at the risk of the development team being unable build your specified behavior in the timebox. If you’re aiming to release at the end of each iteration, as is recommended with most agile processes, this can leave you in a pickle. Half-finished code or finished code on half the design leaves egg on everyone’s face.

Forget anything other than quick-and-dirty paper prototype testing during the iteration. There just isn’t usually time to run a full test and process the results in good time. Instead, launch the feature, and test and tweak it in the next iteration. If you count the necessary usability tweaks as bugs versus features, you don’t violate the rules of introducing work to the current iteration.

Peter, as I understand agile, testing happens during development. It’s one of the strengths of having pair programming. Further, because the engineer should be delivering a working piece of the overall system at the end of each iteration, everyone on the project team has the opportunity to test that piece to ensure it is working properly. As a result, a person dedicated to quality assurance (QA) isn’t needed, which also means that documentation for QA isn’t needed. That said, there are different agile methodologies, and I am not familiar with all of them—so, there may be some methodologies that do have people dedicated to QA and require more substantial documentation than what I have described.

Dave, absolutely agreed—both user research and technical research need to be conducted before development begins on novel projects. I would even add that user research should be conducted before development begins on every project. As for technical research, I’ve found that there is always a Technical Architect assigned to a project, who has been doing research for quite some time before development begins, and when the project starts, that person becomes the subject-matter expert on the project that the other engineers go to when they have questions or problems with the new technology.

Anthony, we mostly agree.

It’s important to include the entire project team in any up front design work—especially the engineer on the project. Up front design work should be limited to some rough sketches of the design, in whatever tool the engineer and designer find appropriate—paper, Visio, iRise, etcetera. By including the engineer in the up front design work, he has the opportunity to note potential feasibility issues. What’s more, this up front design work allows the designer to conduct some rapid usability testing on the design and make revisions before any code is written.

It’s also important for the designer to realize that not all of the ideas are going to get implemented in the current iteration—much less the current release. It’s just the nature of software development—and most designers that I’ve worked with accept this as a reality. Once development begins, the engineer and designer should continue to work together, revising the design as they proceed.

Testing during development should be limited to rapid testing. Even testing at the end of an iteration should be a form of rapid testing, and any results of the tests should be filed as bugs—that can be just as critical as system bugs. Often, engineers and business managers do not acknowledge that usability bugs are as important as system bugs—though, these can be more critical. What’s worse, having a system that doesn’t work or having a system that works, but that no one uses. Not sure I can say, but both should be considered equally bad.

Ultimately, how much interaction design work happens up front will be dependent on the people on the project team. I’ve worked with some engineers who wanted nothing to do with the front end and were happy to see a polished wireframe they could comment on; while others wanted very much to be involved in the design process. One of the strengths of agile is that it values the people on the project highly enough to allow for either personality type.

Could agile be integrated with 5-Second Usability Tests?

5-Second Usability Tests are traditionally oriented toward content, but there would seem to be some synergy possible.

It’s amazing that this topic is still gathering comments. Good work and timely.

I know this may break the conventional principles of agile, but what consideration has been given to keeping the two processes, that of design and development, separate, but using the principles of agile in both?

It seems to me that as technology evolves for Web applications to use generic UI components, the abstraction of layers becomes inevitable. In theory, you can separate the UI/presentation layer from the application layer from the back-end layer.

Let’s assume an initial sprint is dedicated to creating a working simulator application or just a simple branch, where all three layers are working together. The underlying data structure is available and the application layer is operable and working with the UI or presentation layer.

If this is possible, during the design phase, the UI designer and a UI engineer can conduct a sprint of their own with the objective being a complete user experience. Even if it contains validated accessible fake data, the sprint is a success. Then follow-up sprints would have the objective of usability testing and iterating. And that’s the design phase.

Once it is complete, the development phase begins by tying up the layers.

Holes? Issues? Naive?

If anyone is still listening out there, it seems there are two types of research, and times, needed to capture good user data to inform design.

User research done in the requirements gathering stage helps solidify tasks, personas, and design direction that only contextual inquiry can provide.

Then there’s the next stage. Once you have an initial prototype, it’s also very imiportant to test the interaction. Typically, companies mistake conceptual user research for interaction testing—and the latter is just as important.

User research can happen in advance, to inform strategy, scope, and prioritization, but interaction testing, after a working prototype is created, is essential. This is what I find often gets cut out.

Join the Discussion

Asterisks (*) indicate required information.