12 Best Practices for UX in an Agile Environment—Part 2

by Jeff Patton

Excerpt from an article originally published on Jeff Patton & Associates on June 27, 2008.

Editor’s Note: For the past few years, Jeff Patton has been working with Agile teams and user experience professionals to discover the best methods to work together to create great results. For many UX professionals, it’s not instantly clear how to dovetail into an Agile project. In this second part, Jeff shares the remaining best practices he’s uncovered in his research. You can read Part 1 of this article.

#7) Schedule Continuous User Research in a Separate Track from Development

For many commercial Agile projects, I’m starting to see user research as something that’s considered a separate and continuously running track. User research functions as an independent effort that keeps its activities and schedule transparent. User experience designers, working with the development team, can help steer future research (and even participate in it), in support of what they’re currently working on in development. User research that’s conducted is shared and communicated in lightweight ways with the rest of the team. I’ve seen some UX practitioners using comics to communicate the output of user research rather than dry reports. I commonly see presentations scheduled to “share-out”—communicate stories about users and research findings with the rest of the team.

#8) Leverage User Time for Multiple Activities

In talking with Lynn Miller and Desiree Sy about parallel track development they describe visiting customers and using that time to do some contextual-inquiry-style observation and interviewing, to then sit down and review a prototype for something that may be built in a future iteration, then to review the working software testing features just built in a previous iteration. The trick here is to leverage that user face-time for research and validation. Don’t segregate your work.

#9) Use RITE to Iterate UI Before Development

The RITE method—short for rapid iterative testing and evaluation, was first described by a game development team at Microsoft. They describe an idea that to many seems common sense.

In traditional usability engineering, it is common to conduct repeated usability tests with different participants on the same design. By doing this, you can discover usability problems that are common across users. The outcome of traditional testing is often a report that communicates problems along with possible solutions.

However, using the RITE method, we look to get errors out of the software as soon as possible. In between each test, the team discusses the problems they observed and how they might fix them. In the original Microsoft report, developers actually went to work correcting problems before they brought the next test participants in. The result isn’t a list of repeated errors and recommendations like standard usability testing, but software that has most of the errors corrected—which is what we wanted in the first place anyway.

The smart people at salesforce.com have taken RITE and cranked the dials up to 11. They build html prototypes and iteratively test and repair them using remote usability testing. They’ll complete several rounds of this on each chunk of work before it goes into a development time-box. At Google, they describe it as “lunch room testing”—testing paper prototypes of preliminary design during lunch with Google staff at a table setup in the cafeteria.

#10) Prototype in Low Fidelity

When talking to UX practitioners working in Agile environments, I continue to hear them describe the lesson learned over spending too much time crafting prototypes. I hear them chant the mantra of staying as low fidelity as possible.

I prefer paper prototypes, but I often have the benefit of working with co-located teams and customers/users I can get direct access too. I’ve seen others use PowerPoint and only simple black and white lined wireframes. Some even take the time to use “sketchy” lines to indicate roughness. Others may use html. I recently heard a talk from Matt Jones, the designer and owner of Dopplr.com, who described communicating design by sketching on the whiteboard with his developers.

My friend Larry Constantine describes the stuff we build as ‘deliverable’ and ‘consumable’. Deliverable means we have to tighten up and deliver it to someone else. They’ll need to take that work and carry it forward often without us being there. We’re often judged on the quality of that deliverable.

But, consumable work on the other hand is the stuff we build for ourselves. This is the stuff we sketch or model to better understand what we’re doing. It only needs to be good enough to understand, to learn, to communicate quickly with our co-workers, then it can be thrown away. In Agile development, prototypes are consumable.

I also remember a quote from Bill Buxton who said something like: “The idea of high fidelity and low fidelity in prototypes is silly. As far as I’m concerned there’s only right fidelity and wrong fidelity.”

#11) Treat Prototype as Specification

In an attempt to travel light, I often hear UX people describe their prototypes as their specification. It’s common to deliver only the prototype, or ideally the prototype with a team discussion. During the discussion, they annotate the prototype by hand if necessary. No need to produce detailed documentation. In her paper, Desiree Sy points out a number of different documents that were scrapped in favor of discussions over a prototype.

#12) Become a Design Facilitator

As I’ve begun to work within Agile teams, my approach has changed from building things myself to favor collaborative design. Now, I find myself acting as facilitator to harvest and model information from large groups of people. I find myself working with groups of users and developers, to write user scenarios and sketch user interface design.

Recently, I learned about collaborative approaches, such as Adaptive Path’s Sketchboarding and Jewelry Television’s Design Studio. These approaches quickly let teams put ideas out for review and refine them. In addition to them being great approaches to increase the number of great ideas and the quality of the resulting solution, they both provide a facilitation structure to allow a number of people to participate in the design process.

To allow user centered design activities:

To move quickly
To keep progress transparent
To give everyone in the team an understanding of the design, and an appreciation for the process and tradeoffs necessary for a good design.

It’s valuable to turn design activities into collaborative activities involving members of the team.

I often hear UX practitioners working in an Agile context explain to me that a big surprise is how much time they spend facilitating. UX people facilitate not just design sessions, but sessions to communicate test results or field visit results. Desiree described in her paper how they replaced their personas and scenarios with stories about real customers and real use.

Epilogue: Two Sure Fire Ways to Succeed in Software Development

I once introduced the long-time Agile expert, Jim Highsmith, to the CEO of my former company with the hopes that my CEO would hire Jim to help improve things. He’s one of the original signers of the Agile manifesto. He was one of the consultants that helped Agile-UX experts at Alias get off on the right foot in 2002. He’s got a clear head.

My CEO asked him, “We can’t seem to finish anything on time. How do we build software and finish sooner?”

Jim responded calmly “start sooner.”

I overheard Jim in another conversation with someone else years later. They were complaining about “getting all this software built on time.”

Jim’s response: “build less software.”

Let’s recap. Two secrets to success in software development are:

Start sooner
Build less software

This is sadly simple advice.

Agile development does try to short-circuit elongated research and design phases in favor of beginning sooner and continuing active research and design throughout the development cycle.

This quote from Desiree Sy of Alias/Autodesk says a lot:

“For our User Experience Team, Agile user-centered design resulted in better-designed software than waterfall user-centered design. Agile communication modes narrowed the gap between gathering usability data and acting on it.”

Of course, she’s talking about her cycle of talking to end-users, interview them or show them prototypes or working software, then take what she learns right back to her development team. They take their new understanding and act on it in code that she and her team can see a few days later. Starting sooner and keeping the customer research thread alive and active pays.

On a current project, I’m lucky enough to work with a very talented team practicing Cooper’s goal-directed design in an Agile environment. When it comes time for them to describe what to build to the developers, they sit down and talk about it in detail with wireframes and screen mockups in hand.

I’ve seen many of these conversations and they all go a bit like this: After explaining the interaction design to the developers, they say “Ok, we can do that. It’s going to take a couple weeks, but I was thinking that we could do something like this instead…” An explanation follows, “If we do that, I think it’ll still get at what you intended, but we can get it working in a few days.”

Building less software does mean keeping your software from being feature-rich and quality-starved—and it also means collaborating with developers to write a little less code on every single feature you do choose to implement. Sometimes you save a lot of code. Through strong collaboration, I see hours, days, and weeks of development time saved every day on healthy Agile projects. For me, that’s the real secret to finishing on time with high quality software.

Published here on August 5, 2008.