Usability is a quality attribute of a system, which encompasses learnability, efficiency, memorability, error recovery, and end-user satisfaction.

June 30, 2006
URL:http://www.drdobbs.com/architecture-and-design/bridging-the-gap/189401954

Scott is the practice leader of the Agile Modeling and Agile Unified Process (AUP) methods. His latest book is Refactoring Databases: Evolutionary Database Design (Addison-Wesley, 2006). He can be contacted at www.ambysoft.com/scottAmbler.html.

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.

[Click image to view at full size]

Table 1: Comparing the Agile and UED philosophies.

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

User Testing on an Agile Project

For the sake of this discussion, user testing encompasses both acceptance testing and usability testing. The agile community has embraced the importance of acceptance testing, having built tools such as Fit and Fitness to help automate this effort. The automated tests will be run often, at least daily if not several times a day. Manual user testing, on the other hand, is typically done an iteration behind. At the end of an iteration, many agile teams will deploy the working system into a QA/testing environment where user and system testing is performed. The team continues on, developing version N+1 of the system while obtaining defect reports pertaining to version N. These defect reports are treated just like any other requirement: They are estimated, prioritized, and put on the requirements stack to be addressed at some point in the future.

If you want usable software, then you're going to have to test for usability. With usability testing, you observe end users in a controlled setting to see how they actually use, or misuse, your system. True usability testing requires repeated testing with numbers of users under controlled settings, and on agile projects usability testing should occur during the user testing effort following each iteration.

Potential Challenges

It is very easy to suggest that agile practitioners take the time to learn UED skills, and to adopt appropriate guidelines. However, these skills are competing for attention along with other equally important skills such as database design and modeling. Similarly, although UED practitioners need to become generalizing specialists, the industry still rewards specialization—UED specialists are paid very well, and most organizations expect them to focus on doing that specific sort of work. Agile practitioners also suffer from this challenge: Why take an introductory UI design course when you can take a Java programming course, which leads to certification and greater pay?

The agile and UED communities are still miles apart, but luckily there is a movement afoot to bring them together. Hopefully, this column has helped the situation.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.