Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

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

by Jeff Patton
on August 5, 2008

Originally printed August 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

parallel track development

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:

  1. Start sooner
  2. 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.

[Editor’s note: We excerpted this article from an entry Jeff posted
on his blog, AgileProductDesign.com. You can see the original entry
here
including links to additional
articles and resources.]

Want to Learn More?

If you’re a user experience professional working inside an Agile development team, you’ll want to check out Jeff’s virtual seminar Story Mapping for UX
Practitioners: Tying Agile & UX Together
.

Share Your Thoughts With Us

Are you working to improve the user experience in Agile development projects? What practices have you found to work (or to avoid)? Share your thoughts with us at our Brain Sparks blog.