Fwd: UIEtips: 12 Best Practices for UX in an Agile Environment - Part 1

[Daphne Ogle]

Thought this might be of interest to some on the list.  Notice the UIE  
Virtual Seminar available too.  We've purchased it here and are  
watching it tomorrow.  We'll report out...

-Daphne

Begin forwarded message:

> From: "Jared M. Spool" <jared.m.spool at uie.com>
> Date: February 25, 2009 10:18:54 AM PST
> To: "Daphne Ogle" <dogle at umich.edu>
> Subject: UIEtips: 12 Best Practices for UX in an Agile Environment -  
> Part 1
> Reply-To: jared.m.spool at uie.com
>
> 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: dogle at umich.edu
> To change this email address go here: http://www.uie.com/uietips/change/?cEmail=dogle@umich.edu&cID=11776824E
>
> To unsubscribe go here: http://www.uie.com/uietips/unsubscribe/?cEmail=dogle@umich.edu&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

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090303/21a9f2b3/attachment.html>