Usability is a quality attribute of a system, which encompasses learnability, efficiency, memorability, error recovery, and end-user satisfaction. There are several common methods for addressing usability within software development: Alan Cooper's interaction design, user-centered design that was popularized in the late 1980s, and more recently Larry Constantine's usage-centered design (UCD). Although each method has its nuances, for simplicity I use the term "user experience design" (UED) to refer to them.
I believe that UED is critical to the success of agile software development techniques. UED helps to increase your chances of building the right software by placing emphasis on the usage necessary for roles to meet their goals and thereby identifying the behavior the software should have. Because UED practices can be applied with varying degrees of formality, they are compatible with the variety of agile methodologies available to us today.
Current State of the Art
There is a growing recognition within both the agile and UED communities that they can benefit by working closely with each other. There is even an active agile usability mailing list, [email protected], where agile and UED practitioners interact regularly. Unfortunately, there are several challenges that need to be overcome if we're to work together effectively, and just the fact that we talk about two different communities indicates that we have a problem. These challenges are embodied by the different philosophies (see Table 1) within each community.
So how can we overcome the differences between the two communities? The key is to make UED practices usable to agile software developers, and to do that they must reflect the realities of the agile lifecycle.
This can be accomplished by:
- Doing some UI modeling up front. To build a usable system, you need to establish overall organization for the parts of the UI that fit with the structure of user tasks; a common scheme for navigation among all the parts; a visual and interaction scheme that provides a consistent look-and-feel to support user tasks. Yes, this takes some up-front work, but for the vast majority of systems, this could easily be accomplished during your initial modeling efforts during Cycle 0. By doing a bit of up-front modeling, you will reduce the chance that future UI refactorings will be prohibitively expensive.
- Using modeling tools, which reflect agile practices. For example, XP teams prefer to work with index cards, not documents, and AUP teams prefer whiteboard sketches. Luckily, paper and whiteboards are common tools with many UED practitioners. In fact, as Constantine and Lockwood show in their Jolt Award winning book Software For Use (Addison-Wesley, 1999), paper-based low-fidelity prototypes enable quick iteration when gathering user information. Although agile methods favor the development of a working prototype, which gradually evolves into the working system, you can easily combine both approaches.
- Modeling a bit ahead when appropriate. If you need to, you should explore important aspects of the UI before you implement them. Some UED techniques, such as usability sessions with users, are time consuming and require you to stay a few steps ahead of development. For example, conducting a user session often involves scheduling specialized facilities that are in high demand and making appointments with the appropriate stakeholders. These realities pretty much force you to model a bit ahead of the rest of the team.
- Doing the majority of UI development on a JIT basis. The UI is important, but then again so are many other aspects of a system (such as the network, the database design, and so on) and therefore the UI should be treated differently only when appropriate. When you're building a single feature or small set of features, you should perform UED activities as part of the development of those features during the iteration. There are few visual design aspects that cannot be addressed within the current iteration, and therefore you don't need to model ahead very often.
- Adopt UED-friendly requirements artifacts. Methods include the Agile Unified Process (AUP), Open Unified Process (Open UP), Dynamic System Design Method (DSDM), and Microsoft Solutions Framework (MSF). Agile already does this. They have adopted modeling artifacts such as scenarios, personas, low-fidelity prototypes, high-fidelity prototypes, and use cases, all of which enable developers to gain a better understanding of user-experience issues. Other methods should consider doing the same.
- Embed UED practitioners on agile projects. UED practitioners have valuable skills, which they can bring to agile teams, but to fit in on an agile team they need to be willing to become generalizing specialists who can do more than just UED activities. Of course, this strategy only works when you have UED professionals available. Few organizations have such people on staff, and worse yet may not even see the need to hire anyone with these skills.
