Saturday, August 02, 2008

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

The first of a two part article by Jeff Patton ...

"#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."    (Continued via UIE, Jeff Patton)    [Usability Resources]


Post a Comment

<< Home

<< Home