Integrating UX into Agile Development

By Janet M. Six

Published: April 18, 2011

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our experts discuss integrating UX design and user research into agile software development.

Every month in Ask UXmatters, our panel of UX experts answers readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your question to us at: ask.uxmatters@uxmatters.com.

The following experts have contributed answers to this edition of Ask UXmatters:

  • Carol Barnum—Director and Co-Founder of Usability Center at Southern Polytechnic State University and author of Usability Testing Essentials: Ready, Set… Test!
  • Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at BMC Software; Founding Director of Interaction Design Association (IxDA); UXmatters columnist
  • Adrian Howard—Specialist in Agile UX
  • Mike Hughes—User Experience Architect at IBM Internet Security Systems; UXmatters columnist
  • Tobias Komischke—Director of User Experience, Infragistics
  • Anders Ramsay—Independent Experience Designer and Agile UX Coach

Q: How do your organizations integrate UX design and user research into agile development processes? How would you map out your entire development process, step by step?—from a UXmatters reader

“Agile is not a specific process or methodology; it is a way of thinking about creating software products.”—Anders Ramsay

“Agile is not a specific process or methodology; it is a way of thinking about creating software products,” answers Anders. “So, the idea of there being a process for integrating user research and UX design with agile, is itself an agile antipattern. Instead, the changes that allow integration between agile and UX occur at a deeper level.”

“This is a lovely question,” replies Adrian, “because the request to ‘map out your entire development process, step by step’ immediately highlights a clash with one of the four values from the Agile Manifesto.

Success Factors for Agile UX

“The key to a UX professional’s successful integration with an agile team is to focus on the individuals and interactions—
not
the process.”—Adrian Howard

“That’s not to say process is not important,” continues Adrian, “but the key to a UX professional’s successful integration with an agile team is to focus on the individuals and interactions—not the process. The most successful designers and researchers I’ve encountered working on agile teams seem to have four factors in common:

  1. They are missionaries, not dictators. Spending more time facilitating UX work by the whole team reduces ongoing problems and frees up the experts to focus on the harder UX issues.
  2. They are embedded within the team. The agile approach of incremental delivery needs continual design input, and separate design groups can’t do this as well as people within the team.
  3. They adapt their deliverables. When you’re working with the rest of the team, you can answer their questions directly rather than writing a style guide. You can address the problems from a usability test immediately rather than writing a 90-page report. Less time authoring unnecessary documentation means more time for you to help make a product great.
  4. They pitch in. By getting more involved with tasks outside their immediate area of expertise, like development and testing, they find new ways to apply their UX knowledge and help make a product even better.

“Folks miss things when design and development are seen as separate domains. Products need to be beautiful all the way down.”

Adapting User Research to an Agile Approach

“Our toolkit changed to include faster methods. It now takes a shorter time to get a study going, finished, and analyzed.”
—Carol Barnum

“As an external organization, providing UX services to clients, we have faced the agile challenge,” responds Carol. “How to fit usability testing into the short timeframe of a typical sprint? We first became painfully aware of the scope of the challenge when a long-term client suddenly dropped off our radar with their adoption of agile. I have written and talked about this scenario in several places, going back to 2007 and 2008—CHI, Technical Communication, and Cutter IT Journal. From the software developers’ viewpoint, the issue at that time was that they could no longer manage the slow pace of what they called formal usability testing, so they internalized the process with what they called informal testing, by asking customers for informal feedback on features and also having IT developers in other parts of the company test the product to see if they could break it.

“Since I didn’t view either of these informal methods as adequate replacements for what we had provided in our usability lab, I set the goal of figuring out how to be more agile in our testing approach and let our current and potential clients know how we were now agile.

“Our toolkit changed to include faster methods. It now takes a shorter time to get a study going, finished, and analyzed. Here are some of the ways in which we have become more agile:

  • fast planning—No longer do we have to have a face-to-face planning meeting. Instead, I send out a list of things I need to know about the study goals, tasks, personas, and issues. From this, I can initiate planning of the elements, some of which I write and some my clients draft for my review. We do an email exchange, oftentimes with many email messages going back and forth in a single day, until we get the study protocol mapped out.
  • participant recruiting—If I’m recruiting and scheduling the participants, I get the dates and timeframe for the study first, along with user profiles. Then I start recruiting right away from a database of accessible potential participants.
  • rough and tumble pilots—I warn my client that the pilot is likely to be very rough because we are working under very tight deadlines, so we need to plan for an intense hour after the pilot, when we’ll make the needed changes between the pilot and the tests we’ll run for the rest of the day with participants.
  • fast debriefs at the end of each day—We print test logs throughout the day and use these at the end of the day to capture the top findings from all observers. If we are doing two days of testing, this quick meeting at the end of the day captures things we don’t want to forget during our review on the second day. If a study lasts just a single day, this meeting gets everyone together to agree on the findings and prioritize the issues the development team needs to fix. The developers, when present, walk out with their list of issues to address in the next or a future sprint. If they are not present, we send these findings, along with the logs of sessions, to everybody the same night.

“There are other ways to be agile, and we have used a number of methods. But this is our most common method, and it works.”

“Defining a clear vision for a product is essential to achieving a holistic user experience, so it’s important to take the time to do this at the beginning of an agile project.”—Pabini Gabriel-Petit

“Defining a clear vision for a product is essential to achieving a holistic user experience, so it’s important to take the time to do this at the beginning of an agile project,” advises Pabini. “One way to ensure you’re building the right product for your audience is to do generative user research, then define user profiles or personas and scenarios based on your research. These user research and analysis activities typically occur during Iteration, or Sprint, 0 and provide helpful inputs to requirements definition in the form of epics and user stories.

“During agile design cycles, paper prototyping provides a quick and effective means of validating your sketches of a design solution with users. For an in-depth description of this technique, see my UXmatters review of Carolyn Snyder’s book Paper Prototyping. Or better yet, read the book.”

Creating Lightweight Documentation

“Requirements definition is an integral part of an agile development process, and writing user stories is a fast, effective way of capturing requirements and estimating level of effort.”—Pabini Gabriel-Petit

“Requirements definition is an integral part of an agile development process, and writing user stories is a fast, effective way of capturing requirements and estimating level of effort,” suggests Pabini. “UX professionals on agile teams sometimes add value by taking responsibility for writing user stories. The best resource for learning how to write user stories is Mike Cohn’s excellent book User Stories Applied: For Agile Software Development.

“There’s no substitute for sketching as a means of exploring possible design solutions. For an agile project, you can take photos to capture your whiteboard or paper sketches for inclusion in your design documentation or create your sketches digitally to begin with.

“The degree to which you can keep your design documentation lean depends on how closely you can collaborate with product teams. If you can do the equivalent of pair programming to collaborate on interaction design with a developer, some aspects of your design can go straight into code.

“Alternatively, a UX team that includes front-end Web developers can prototype or even build an application’s actual user interface rather than writing detailed UX design specifications. But if you’re working on a distributed team and can’t create prototypes, you’ll need to create more detailed design documentation. Just provide the minimum documentation it takes to effectively communicate your design and ensure a high-quality implementation of your design.”

One Agile Process

“During the sprint, the UX Architect advises the team on UX design issues and reviews their completed work for usability and quality.”—Mike Hughes

Mike describes an “agile development process that integrates UX design and user research:

  • The UX Architect works with Product Management to review and understand requirements documents.
  • The UX Architect develops scenarios and conceptual wireframes to illustrate a general user experience that would meet the requirements. Product Management, other stakeholders, and technical subject-matter experts review and iterate on these.
  • When feasible, the UX Architect gets customer input into scenarios through interviews or social-media collaboration channels.
  • The UX Architect elaborates on these scenarios, writing user stories in the following format: As a [role], I want to [action based on a feature], so [user goal].
  • The full development team estimates each of the stories—a half-day to a full-day event—prior to sprint planning. Developers often add new stories at this time.
  • During sprint planning, the development team selects an appropriate number of stories to implement during the sprint, based on their size and priorities, and the team elaborates them into tasks and assigns the work for the sprint.
  • During the sprint, the UX Architect advises the team on UX design issues and reviews their completed work for usability and quality.
  • While the development team is working on the stories they’ve selected for sprint n, the UX Architect tries to work ahead on sprint n+1.

“There are also general user research activities that are not tied to a particular sprint or project—such as contextual inquiries,” adds Mike, “but these usually feed into the requirements definition process, not into agile development.”

Team Dynamics

“UX designers do not work alone and wait until they have something polished to present to developers, but instead receive ongoing and informal feedback.”—Anders Ramsay

“Agile development is fundamentally a collaborative process,” observes Pabini. “So from a user experience standpoint, the success of an agile development process hinges on the inclusiveness of an agile product team and developers’ willingness to work in close collaboration with UX professionals.”

“One example of taking an agile approach is replacing passive team communication,” replies Anders, “in which team members work individually, then hand off artifacts from one team member to another, with active team communication, in which team members work together actively across disciplines and phases of work. This means developers are actively involved in user research work and speak directly with users rather than a sole user researcher’s doing the work, then later handing off some document to the developers. Such a document takes time to produce, and developers probably wouldn’t read it anyway.

This means UX designers sit physically next to developers and collaborate continually throughout the design process. In other words, UX designers do not work alone and wait until they have something polished to present to developers, but instead receive ongoing and informal feedback.

“Increased overlap between the work of team members in various disciplines not only changes their social and cultural interrelationships, instilling increased cross-disciplinary empathy and understanding, but also replaces traditional document-centered communication….”—Anders Ramsay

“This increased overlap between the work of team members in various disciplines not only changes their social and cultural interrelationships, instilling increased cross-disciplinary empathy and understanding, but also replaces traditional document-centered communication—which is slow, unwieldy, and incompatible with the velocity of contemporary agile software development projects—with fast, lightweight communication that reflects the current project reality.

“This type of change does not come easily to organizations. It frequently requires changing how and where people work, how an organization plans projects and builds product teams, and the nature of an organization’s psychological relationship to documents, which ultimately tend to be little more than imaginary assurances of progress. Therefore, I recommend starting small, with a pilot team of energetic team members, who can then become a living testimonial of success for the rest of the organization.”

For More Information About Agile UX

“At the IA Summit this year, there were a number of excellent sessions that focused on agile UX,” notes Pabini. “For in-depth recaps of these sessions, I suggest you read my review of the IA Summit 2011 in this issue.

“We’ve already published two other excellent articles focusing on agile UX on UXmatters and will be publishing more in the near future. Check out:

“Other good Web resources on agile UX include the following:

Tobias recommends Daniel Rosenberg’s article “The View from Here: Garbage In, Garbage Out, the Agile Way,” saying “I totally agree with his take.” This article appeared in User Experience Magazine, Volume 9, Issue 1, 2010.

2 Comments

Carol Barnum’s description of how she adapted her usability testing for agile is spot on. It is consistent with the agile principle of “just barely good enough”— that is, you just need to do what’s required to get to the next stage. When I was at Checkfree we were in fast development cycles and had a heavy emphasis on usability testing. We often recruited users not knowing what story we would be testing, because the recruiting lead time exceeded our sprint window. We could do that because our user profile was stable.

My experience with agile is that doing usability testing on Sprint n’s work during Sprint n+1 doesn’t work very well. It’s hard enough to go back to fix bugs; making usability changes is even harder. So by all means, get the usability work done up front whenever possible.

This is always an interesting subject. Agile, by its very nature, lends itself well to the kinds of rapid investigative and prototyping techniques that are commonplace within the UX community.

I actually blogged about this a while ago. Read my take.

But in a nutshell, I reckon that it can work given some care—although it might not always be the most appropriate solution for every development.

John

Always welcome new contacts on Twitter. I’m #webfeedback there.

Join the Discussion

Asterisks (*) indicate required information.