Agile Usability

Posted by Mark Levison on Nov 20, 2008

Sections

Process & Practices

Topics

Agile ,

Agile Techniques

Tags

Facilitation ,

UX ,

Prototype

Jakob Nielsen, usability guru and author of Usability Engineering, raises the concern that Agile methods are a threat to traditional approaches to designing usability. He says that Agile’s greatest threat to usability is that “it's a method proposed by programmers and mainly addresses the implementation side of system development”. Alistair Cockburn counters that this claim just isn’t true:

1. It doesn’t matter who proposed a good idea, only whether the idea is good.
2. This sets up an “us versus them” split in the community instead of an “us plus them” coming together.
3. Unlike the other threats Nielsen names, he doesn’t offer a solution, so he leaves us with his “us versus them” unsolvable problem, which is unacceptable.

Proposed solution: Just use good ideas – don’t worry about where they come from. As Kurt Morris posted on the agile usability list, “It’s amazing what can get accomplished once you get past the artificial “us v them” mentality.”

Nielsen goes on to raise the issue that the Agile habit of breaking the stories down into smaller tasks threatens to obscure the total user experience, allowing features to be developed in an inconsistent manner. At its worst, he says: “the user interface can end up resembling a patchwork.”. Nielsen’s solution:

• Perform Usability testing quickly and repeatedly. He says “Weekly tests are completely feasible and give you a surefire way to integrate several user feedback rounds within even the shortest sprint.”
• Parallel Tracks allow the usability work to be done just one step ahead of the development work.
• Use low fidelity prototypes (such as paper) that don’t require coding minimizing the time spent upfront.

Jeff Patton has distilled 12 usability best practices (echoing several of Nielsen’s):

1. Drive: UX practitioners are part of the customer or product owner team
2. Research, model, and design up front - but only just enough
3. Chunk your design work
4. Use parallel track development to work ahead, and follow behind
5. Buy design time with complex engineering stories
6. Cultivate a user validation group for use for continuous user validation
7. Schedule continuous user research in a separate track from development
8. Leverage user time for multiple activities
9. Use RITE to iterate UI before development
10. Prototype in low fidelity
11. Treat prototype as specification
12. Become a design facilitator

The RITE (pdf) method that Jeff describes comes from Microsoft’s Games Studio: “RITE differs from a “traditional” usability test by emphasizing extremely rapid changes and verification of the effectiveness of these changes.”. Specifically, practitioners make changes to the UI (prototype or application) as soon as the problem is found and the solution spotted. Changes such renaming buttons, changing the text of menu items often happen before another participant arrives. More complicated, but obvious changes are made as rapidly as possible. This way the change can be tested as quickly as possible.

In addition, Jeff finds his role has changed: “As I've begun to work within Agile teams, my approach has changed to favor collaborative design. More and more 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.”

Finally, Alistair says (in reference to the developer/usability divide): “Just remember, ‘There’s only us."

1. Back to top

   Yes and No...

   by Kevin E. Schlabach

   I spent 5+ years solidly working in the usability field, and I agree with Nielson that there is a risk in allowing developers to create user interfaces on their own. But as a person who was originally a developer, I also understand that it is an issue of exposure and experience. Agile's focus on the customer puts developers a lot closer to understanding this issue.
   
   Nielson also has a tendency to over-react to things to grab attention... once again, Cockburn is taking the balanced approach of pointing to the team and not "us vs. them".
   
   Cooper's Agile 2008 keynote should have been a wake-up call for our community. I was proud to have heard it.
   
   Nielson's point that "the Agile habit of breaking the stories down into smaller tasks threatens to obscure the total user experience" is a valid point and has been addressed by Jeff Patton's backlog mulching metaphor.

   Reply

2. Back to top

   Developer and user collaboration is the key to success of usability

   by Sachin Mehra

   I don't agree that "breaking the stories down into smaller tasks threatens to obscure the total user experience", as a matter of fact, it will bring clarity to the details of the UI.
   
   Developer and user collaboration is the key to success of usability. Agile, by its very existence, advocates collaboration of efforts for a common goal.

   Reply

3. Back to top

   Usability with Agile has challenges, but also benefits

   by Katrina Lindholm

   As a user experience designer at a software company that not only practices agile but develops Agile lifecycle management software (rallydev.com), I can attest to both the challenges and benefits of integrating usability work into the Agile cycle.
   
   There is no doubt in my mind that iterative development is a huge improvement over waterfall. It is incredibly rewarding as a UX professional to listen to a customer express a need and see that need met in as little as a few short weeks. I have also found that Agile's use of user stories that are written from the customer's perspective can help guide everyone on the team to deliver highly usable solutions. Another benefit of Agile is the collaborative team environment. This allows UX professionals to be highly involved in planning and development and to have a substantial impact on what is actually delivered.
   
   I agree that one of the greatest challenges is in seeing the big picture and having ample time for research and design. For small, autonomous features, research and design can be done "just in time." But for features that need to be developed over several releases (yes, these still exist even with Agile!), having a solid understanding of the end goal is critical to making good design decisions for the earliest increments. As another UX professional said to me at a recent Usability Day event, it would be difficult to build a livable house if you're building it one room at a time - you need to have a basic idea of how it will all work together in the end.
   
   As with anything in Agile, usability professionals need to prioritize which work needs the most attention and schedule their time accordingly. Is it risky? Will it affect a large number of our customers? If so, it needs to be prioritized higher and usability research needs to be started earlier.

   Reply

• Older >