case study
Patton: 12 Best Practices for Agile UX
In October, I attended a session by Jeff Patton at UIE13 on doing user experience work in agile environments. I found it extremely helpful in understanding how to improve the process on my current team. I have not yet “arrived,” but the principles learned there have had an actual impact on my processes, as opposed to the “feels good but what do I do now” impression you sometimes get from conferences.
In a “re-print” from last August on UIE’s newsletter, Jeff outlines 12 principles for UX in an agile environment. Here’s a summary of the points in his article (originally broken into part 1 and part 2), with notes on how I have applied these principles to my current project:
- Drive: UX practitioners are part of the customer or product owner team.
This one has been part of my philosophy for many years, but it was good to get some validation. I work with a “product manager” to discover and confirm requirements, meet with end users to see how the product will actually be used, and in other ways act as a proxy owner. The product manager has the final say, but the interaction design role has significant input and is the dev team’s interface to product management. - Research, model, and design up front—but only just enough.
I found in my current project that cartoons, spare wireframes, etc. that run the breadth of the product, but don’t dive to the pixel really helped the team focus at the right level of granularity. Before I was stuck with two extremes—research and prototype everything completely before the 8 month project kicked off, or research prototype only the next 6 week dev cycle. Allowing myself to cover the whole product, but mostly at a “bare requirements” level struck the right balance.
- Chunk your design work.
Organizing and helping product management prioritize the work has been one of the things I do that product management has most valued in my current project. It has allowed us to stage the development in such a way that we can begin to develop, deploy, and test coherent bundles of functionality with end users—before the project end date is so close that changes become too expensive.
- Use parallel track development to work ahead and follow behind.
I am researching and developing one or two cycles ahead of development, while also tailing the team’s current development to make sure it’s implemented as planned. It’s sometimes hard to stay a full cycle ahead, but it’s made easier by the forethought given in #2 above.
- Buy design time with complex engineering stories.
In my case, we front-loaded the project with security work, dev & QA environment set-up, and API work that required little or no UI. This gave me a chance to get ahead without the team getting behind as a whole.
- Cultivate a user validation group for use for continuous user validation.
While I’ve been able to test with several user groups so far as we’ve gone along, I don’t yet have this in place. The strong study participant pool at Microsoft (and people hired to manage and recruit from it) is one of the things I miss most about not working there anymore. (Ellen Gasca, this one’s for you!)
- Schedule continuous user research in a separate track from development.
Again—would love to… but not there yet.
- Leverage user time for multiple activities.
When testing, I gather artifacts, ask if there are important tasks we haven’t covered in the test, and so forth. While I have face-time with end users, I try to make the most of it.
- Use RITE to iterate UI before development.
I’m not sure Jeff’s description of RITE in his article does it justice, so I’ll wax a little more verbose. RITE testing rests on the premise that it is better to remove “big rocks” after a few participants hit them than to watch participant after participant bang their heads against the same problems. Fix the big problems as soon as they are apparent, then test the solution with the next participants. In other words, by the end of the test, you are validating solutions instead of finding problems.
Michael Medlock and his team at the Games division of Microsoft coined the term RITE (Rapid Iterative Testing and Evaluation), codifying a pre-existing but ill-defined practice. RITE makes usability testing more impactful, and reduces the risk of introducing new problems when fixing others. On my current project, I have done RITE studies using paper prototypes before development began (as Jeff suggests above) as well as in a dev environment after a chunk of functionality was working. It works in both cases as long as the dev team can turn around changes quickly. A key is making sure to trying to fix only issues that have a clear cause, a clear solution, and a small price tag. Bigger or more complex problems will still have to wait till after your test is done.
If you haven’t tried it, read the original article and then give it a shot.
- Prototype in low fidelity.
I actually prefer Jeff’s quote of Bill Buxton for this principle: “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.” Amen. It depends on skills sets, the level of interaction being modeled, the amount of time you have, and a dozen other factors.
For my current project, I am prototyping first with Balsamic Mockups for the high level pre-project design phase in #2 above, and using clickable image maps (basically a Fireworks png with hotspots added in Dreamweaver), heavily annotated for most interaction details. (I give Balsamic Mockups only 2 or 3 stars by the way; very easy to get something up there fast, but very limited set of representations. If they could just add some simple line and shape drawing tools…)
For other projects I have developed the HTML and CSS myself. For certain aspects of testing I’ve used paper prototypes of screenshots supplemented with sticky notes; it all depends.
- Treat prototype as specification.
In other words, don’t over-document, a classic agile principle. Some would argue that the prototype plus a discussion should replace all documentation. But I find that a well-annotated prototype saves QA a lot of pain and makes it easier to both “work ahead and follow behind” (#4 above). Otherwise it’s difficult to keep track of the details of what the team is currently developing compared to what you are researching and prototyping for the upcoming cycle. Also, there comes a time when updating the prototype becomes a waste of time; the QA says, “I’m finding problem X.” The designer says, “You’re right; we should use solution Y.” And the developer just fixes it. You only have to update the prototype if there is a risk that somebody down the line will have missed the conversation and not know what’s going on.
- Become a design facilitator. While I haven’t yet moved into full-scale participatory design with users, I have done contextual inquiry with key users lately. I also I meet twice a week to review design ideas and confirm requirements with the product manager, and once a week with the dev team or at least the leads to review the designs, get input, and make refinements. As a group, we get it right more often than I would on my own. I am not just throwing designs over the wall at our developers.
Jeff finishes his article with two choice observations from Jim Highsmith, one of the original proponents of agile development.
Someone once said to him, “We can’t seem to finish anything on time. How do we build software and finish sooner?” Jim responded, “Start sooner.”
Later someone complained to Jim about “getting all this software built on time.” Jim answered, “Build less software.”
Getting interaction designers involved early is one way of “starting sooner”; the whole project runs faster and smoother if we have broken the ground first. And as co-owners with product management, we should be constantly looking for ways to “build less software”, to simplify, to prioritize.
Thanks Jeff, for summarizing some great agile principles to design by.