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