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

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 2-part article, Jeff gives us 12 best practices he’s uncovered in his work.

1) Drive: UX Practitioners Are Part of the Customer or Product Owner Team

In the best teams, the UX folks have an active hand in deciding what is built, the overall business strategy that drives what’s built, and the tactical prioritization of work done first. In some successful Agile organizations the UX team is the Agile customer team or product owner team.

For UX practitioners not familiar with the terms ‘customer’ or ‘product owner’ in the Agile context, they refer to a process role and not necessarily the actual customers who purchase a commercial product. However there is a bias in Agile environments to get end-users more frequently and directly involved. Do this also. More on that in #6.

2) Research, Model, and Design up Front—but Only Just Enough

In spite of what a dogmatic Agile trainer may tell you, companies that are successful at incorporating UX work and Agile do some up front user research and modeling that results in things like personas, workflow models, task analysis grids, or even something like Indi Young’s Mental Models.

However, they have learned how to compress the timeframe for this work by:

• aggressively prioritizing the types of users researched to the those that are the highest priority, and shortening the amount of time spent with users of lower priority
• modeling quickly, in a lightweight and collaborative way often involving other team members to help analyze data and construct time consuming models like affinity diagrams
• defer some less urgent research to be completed while the software is being constructed

Since the UX team is ideally part of the customer/product owner team, they have a hand in determining an incremental release strategy—that is determining what coherent collection of features to release first. Leveraging this understanding, high level scenarios and/or wireframes are usually built to communicate screen flow, general look and feel, and general user interaction patterns.

All this research, modeling, and high level design often occurs in weeks, not months. Organizations, such as Yahoo, have been effective at packaging and leveraging user research across projects to shorten the time between initial concept and beginning construction. UX practitioners should leverage the time while the organization is finding production staff, such as developers and testers, to begin their research and modeling.

Some Agile teams use “iteration 0” or “sprint 0” to mean a first development timebox that they set aside for this initial research. They also use this time to get the development environment setup and ready to go and do some initial architectural prototyping or “spiking”—the rough equivalent of high-level design from an architectural perspective. For years now, I’ve done a quick treatment of user centered design modeling to build a backlog and plan initial product releases.

3) Chunk Your Design Work

Once high-level research, modeling, and design is done, it’s time to start construction.

Construction in Agile development is done in small chunks usually called user stories—or bits of functionality valuable and demonstrable from a user’s perspective. This can be a problem for designers because they need to guess what the stories will be, then later design their interaction and look, in sync with development. Hopefully, the high level design has left us with a bit of a “sketch” of how thing might look and a high level roadmap of where the software is going functionally. We don’t want to be flying too blind.

The idea of “chunking” or breaking down work into coherent chunks that can be both designed, build, and validated somewhat independently is both art and skill. Some take apart their high level sketches of the software and chunk a screen or screen-component at a time. I work using the “user task” as a building block layering in functional user tasks into the system one at a time. When a system begins to mature functionally, chunks begin to take the form of adjustments and refinements to existing software.

I believe most UX practitioners are afraid of building something akin to the Winchester Mystery House. It’s not an unfounded concern. But, given a high level sketch of the design, some practice at chunking, and some course correction along the way and things tend to come out OK.

Chunking work into small bits turns out to be difficult for everyone. Developers new to Agile have difficulty with it. Business people or product managers have difficulty in breaking their system down into small parts that can be considered independently. And over time Agile practitioners have recommended breaking functionality down into smaller and smaller parts.

4) Use Parallel Track Development to Work Ahead and Follow Behind

Lynn Miller of Alias, now Autodesk’s Toronto office, first described the pattern of parallel track development in her 2005 paper, Case Study of Customer Input For a Successful Product. For Alias’s Sketchbook Pro product, she described the emerging pattern of the Agile customer team working ahead one or two timeboxes to research or design what will be built in future development time boxes.

It’s actually a bit more complicated than that. The design team works ahead a development time-box or two. In a given timebox they might be:

• researching work to be done 2 timeboxes from now (T + 2)
• validating design prototypes to be built 1 timebox from now (T + 1)
• being available to collaborate with development to support work done in the current development timebox (T)
• working with customers to validate working software built in the previous timebox (T – 1)

User experience people working on Agile teams become masters of development time travel nimbly moving back and forth through past, present, and future development work.

5) Buy Design Time with Complex Engineering Stories

At times, it takes more time to design and validate a feature. That next Agile development timebox is coming whether you want it to or not. Ideally developers will keep working on software while design and design validation is ongoing. To buy time, it’s common to have chunks of work that are technically complex, but trivial from an interaction design perspective. In her paper, Lynn described starting development work on Sketchbook Pro by beginning the construction on the feature that saved drawings as layered PhotoShop files. From the user interface, it’s a simple “file, save as” menu choice, but from the development perspective, it was heavy lifting. Having the development team work on this very important feature early bought designers time to get ahead.

I used to have a friend in the newspaper business. Newspapers release every day whether writers are ready with stories or not. One of the things she did was keep stories sitting around that she called “evergreens.” These were stories that stayed fresh—stories that she could put into the paper at any time to fill space. Interaction designers would do well to identify work that’s “evergreen”—work the team can do any time, but that buys time to do the time-sensitive design or design-validation work.

6) Cultivate a User Validation Group for Use for Continuous User Validation

Many times now, I’ve seen the pattern of UX people building up a pool of users they collaborate with to validate design before and after it’s built. This pool of users needs to be large enough that the designer doesn’t call on the same user repeatedly every week, but talks with them every month or two. My friend Heather described what she calls “development partners” at Elsevier. Desiree Sy describes design partners in her paper on Agile User-centered design.

Organizations, like Salesforce.com, keep a continuous flow of users scheduled to validate design work. I’ve seen many instances of users scheduled for remote usability testing or site visits well in advance of knowing what will be being tested. The one thing you can depend on in an Agile context is that there will always be something.

[In Part 2, we’ll look at tricks for scheduling continuous user research, using the RITE method, and becoming a design facilitator, as we continue with Jeff’s 12 best practices.]