From: "Jared M. Spool" <[email protected]>
Date: February 25, 2009 10:18:54 AM PST
To: "Daphne Ogle" <[email protected]>
Subject: UIEtips: 12 Best Practices for UX in an Agile Environment -
Part 1
Reply-To: [email protected]
UIEtips: 12 Best Practices for UX in an Agile Environment - Part 1
2/25/09
Contents:
- Letter from the Editor
- UIE Virtual Seminar: An Agile UX Primer
- Web App Summit: Register for Individual Days and Get a Discount
- Feature Article: Anatomy of an Iteration
===========================================
Letter from the Editor
===========================================
Greetings,
When shooting the movie, the director doesn't necessarily film the
scenes in the order they'll appear once edited. Instead, the
filmmakers shoot the pieces according to other constraints, such as
the availability of actors or locations, or accommodating
variability in the weather. It's not unusual for the movie's final
climax to be among the first scenes shot.
It occurred to me, while talking with Jeff Patton last summer, that
the same can be true in an Agile development process. Often times,
the team will start with a piece of the project that isn't the first
thing the user experiences, but instead might be at the end. For
example, they may start by building the functionality to save a file
in Photoshop format – technically an important, high-risk part of
the project, but not much of a user interface beyond a simple "Save
as PSD file" option.
Jeff mentioned that user experience designers on the Agile team end
up adopting a similar role to the person who gets the credit of
"Continuity" in a film. It becomes their job to make sure the final
experience makes sense, even though the order of construction was
not linear. This is a huge challenge and one that has come to
forefront as more teams move to an Agile development method.
Jeff Patton has been researching the new challenges that arise when
teams try to merge their UX efforts in an Agile process. In his
travels, he's assembled a slew of best practices that result in the
development of great experiences. In this week's UIEtips, we're
proud to republish the first installment of a two-part article where
Jeff describes 12 of his best practices.
On March 4, Jeff will give An Agile UX Primer as part of our UIE
Virtual Seminar series. If you're on a team that is moving into an
Agile development process, you won't want to miss this informative
90-minute online session. See all the details: http://cli.gs/2HsVm6
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, http://cli.gs/bPZUAy
Enjoy this week's article,
Jared M. Spool
Editor, UIEtips
P.S. Register for Jeff Patton's seminar with the promotion code
MYARCHIVE and get life-time access to the recorded seminar for free.
===========================================
UIE Virtual Seminar: An Agile UX Primer
===========================================
Agile is coming. It's now the solution of choice for speeding
development and delivering quality results. But where does that
leave the User Experience (UX) practice?
UIE Virtual Seminar - An Agile UX Primer, with Jeff Patton
Wednesday, March 4, 2009
1:30pm ET / 12:30pm CT / 11:30am MT / 10:30am PT
90 minutes
More details at: http://cli.gs/4L9vrb
In his presentation, Jeff Patton will discuss the essentials of
Agile Development, the distinct culture and value system that Agile
brings, and the common Agile process you're likely to see. You'll
hear about the myths of Agile and common pitfalls organizations
tend to encounter. Armed with the foundations, you'll explore some
emerging UX practices and how to thrive within an agile process.
We're offering the Archive of this presentation at no additional
cost when you register with the promotion code MYARCHIVE. Sign up
today! http://cli.gs/4L9vrb
===========================================
12 Best Practices for UX in an Agile Environment - Part 1
by Jeff Patton, AgileProductDesigns.com
Originally published: Aug 01, 2008
===========================================
[Editor's Note: For the last 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. Stay tuned.]
+ + +
Read the article on UIE's web site at: http://cli.gs/j80RY2
+ + +
On March 4, Jeff will give An Agile UX Primer as part of our UIE
Virtual Seminar series. If you're on a team that is moving into an
Agile development process, you won't want to miss this informative
90-minute online session. See all the details: http://cli.gs/2HsVm6
+ + +
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, http://cli.gs/bPZUAy
===========================================
Web App Summit: Register for Individual Days and Get a Discount
===========================================
We're very excited about the four day program we've created for the
April 19- 22, 2009, Web App Summit in Newport Beach, CA.
There is no other conference around diving in deep on web form
design, Ajax, RIAs, design deliverables, wireframes, accessibility,
design patterns, and web standards. We're so sure you'll be satisfied
with the conference that we offer a 100% money back guarantee.
View the program for yourself: http://cli.gs/8hNVZN
You now have two ways to register for the Summit, both with special
discounts to UIEtips subscribers.
You can take advantage of the 16 speakers, 2 full-day workshops, and
the
featured and new perspectives presentations by registering for all
four days of the Summit.
Or you can register for one, two or three days. Based on your
schedule and budget, you select the days you want to attend.
Either way you register, we know how tight budgets can be, so we
want to you help you. Use the promo code UIEtips and get $50 off a
day - up to $200 off the registration price. Registering with a
group? Sign up for all 4 days and take $250 off the conference price.
For full program details and pricing visit www.webappsummit.com
+ + +
Do you have feedback or comments on our article? Send us your
thoughts on the UIE Brain Sparks blog at http://cli.gs/bPZUAy
---------------------------------------------------------------
This message was sent to you as a result of your previous business
interactions with User Interface Engineering.
You are currently subscribed to uietips as: [email protected]
To change this email address go here:
http://www.uie.com/uietips/change/[email protected]&cID=11776824E
To unsubscribe go here:
http://www.uie.com/uietips/unsubscribe/[email protected]&cID=11776824E
Did a friend forward this email to you? Would you like to get your
own copy? It's easy. Just visit: http://www.uie.com/uietips/
-------------------------------------------------------------------
User Interface Engineering
510 Turnpike St., Suite 102
North Andover, MA 01845
Phone: (978) 327-5561 or (800) 588-9855
Fax: (978) 327-5568
http://www.uie.com
