June 2009
Volume 24 Number 06
Usability in Practice - Agile Ux Development
By Dr. Charles B. Kreitzberg , Ambrose Little | June 2009
Dr. Charles B. Kreitzberg
Fitting user experience activities into the development process is a persnickety problem but it's one we need to solve. Agile development is becoming increasingly mainstream, and with good reason. It's impossible to construct an accurate and exhaustive list of requirements and then transform them into a truly useful, usable, and desirable product. People don't really learn what they want until they use a product, so a product needs to go through multiple iterations before it achieves a high level of utility and polish.
But the fit between user experience and the Agile development process is problematic. It's somewhat surprising because the philosophies of Ux designers and Agile software designers both emphasize iterative refinement and learning from users. But it's also a real problem because as Agile methods become more widely employed, the risk to the quality of user experience also increases. Jakob Nielsen suggests that the problem has its roots in the fact that Agile was conceived of by programmers as a way of improving the development process. He has said that Agile "mainly addresses the implementation side of system development. As a result, it often overlooks interaction design and usability, which are left to happen as a side effect of the coding."
Ambrose Little
To create great products, Agile methods need to incorporate user experience design in a way that is synergistic with software engineering. Achieving this will require that both developers and Ux designers rethink a few assumptions. One area where we need to reexamine our assumptions is design planning.
Scott Ambler suggests that, among other conflicts, the Agile community's rejection of early-stage modeling or Big Design Up Front (BDUF) clashes with the Ux community's desire to nail down the user interaction before construction begins.
Agile Values
We are uncovering better ways of developing software by doing it and helping others to do it. According to the Agile Manifesto we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
On the face of it, this seems like a big issue. Agile developers "learn by building" and this tends to make them skeptical of the value of Big Design Up Front. But in more fundamental ways, Agile and Ux share a common philosophy. The Ux design process of building a UI prototype and testing it with users is similar to an Agile iteration. Ux design is built intrinsically on iteration, testing and learning from user reactions. The four Agile values that were presented in the Agile Manifesto, which were presented earlier,2 fit equally well with Ux's philosophy.
Recently we had a conversation about our views concerning Agile and usability. We invite you to listen in. Ambrose, the developer/architect asked most of the questions.
Ambrose: Why can't Ux folks just design on the fly with the Agile team?
Charlie: I think they can. User-Centered Design (UCD) as it's traditionally practiced has a rather heavyweight style. First you study the users, then you build competing designs, then you test them empirically, refine them, continue to test them, and finally publish them as programming specifications. It's a pretty good process that consistently yields high-quality results if you have enough time and money. But like waterfall development it's often inappropriate in the real world.
So the key question is, how do you manage to maintain a holistic and consistent view of the UI while developing it in short iterative cycles? The answer is that you need to separate the elements that are essential to have up front from those that can be deferred to later iterations.
One of the functions of the usability test is to provide Ux designers with information about how people respond to the UI behaviorally. That's not very different from the kind of learning that Agile seeks when it deploys the results of an iteration and gathers data about user reactions to it. In fact, assessing user reaction to a release is potentially more powerful than the traditional usability test that uses mockups of the UI with minimal, or perhaps no, functionality. UI mockups only let you test initial reactions. They don't tell you how people are using the tool a week or month after release. They're also not great when you are testing a highly dynamic UI as you might in a multi-touch situation. In these regards, Agile has advantages.
Ambrose: But isn't a fundamental assumption of Ux that you need to create the design up front? And Agile abhors BDUF. Can you reconcile that?
Charlie: The more radical forms of Agile, like extreme programming (XP), don't make a lot of use of design up front. Actually, I think it would be interesting to see how little initial design is really needed to create a high-quality Ux. I think a really good designer could be effective in that environment. But there's no need to be quite so radical. The risk in not doing enough design up front is that you will either be unable to create a holistic experience for the user or that you will be forced to rethink the UI design after you have already released early iterations and the users have spent time learning how to use the product.
What I would propose is that we limit up-front design to the elements essential for creating a holistic experience and do the remaining design iteratively. You need a framework that enables developers and designers to maintain UI consistency as the product evolves, and you need the UI to expand in a graceful and expected manner to accommodate the evolution. You cannot constantly restructure the UI with each release or you will confuse your audience and create usability problems. You also need to maintain the UI's connection to the business tasks and user characteristics.
So what you want is a minimal design up front that conveys the right elements. If you're an acronym fan, think of it as replacing BDUF (Big Design Up Front) with ENUF (elements needed up front) and do just ENUF design going into the project.
Larry Constantine cites three characteristics essential to a minimal up-front design:
- An overall organization for all the parts of the user interface that fits with the structure of user tasks.
- A versatile common scheme for navigation among all the parts.
- A visual and interaction scheme that provides a consistent look and feel to support user tasks.
Recall that Agile's second value is to prefer "working software over comprehensive documentation"; early Ux prototypes serve the same function of supporting learning through building.
Ambrose: You mention "product conceptual design." What do you mean by that?
Charlie: By conceptual design I mean the high-level design elements that define the design space and serve as scaffolding for the detailed design that follows. Conceptual design starts with the three characteristics that Larry Constantine outlined. When I am designing a product, I create a UI mockup that I call a "key screen prototype," which is a set of wireframes that define the product. The key screen prototype shows how the user will navigate to key functionality and how that functionality will look to the audience. It defines the basic information architecture and the rules for presenting information as well. I often include a visual design so that the key screen prototype conveys more of the user experience than would be possible with schematic wireframes and develop a style guide to document the screen layout, information architecture, and visual design conventions so developers have a ready reference available.
The key screen prototype and style guides are both lightweight and easily refined as new ideas are introduced.
If I can, I start the conceptual design and key screen prototype during the business case analysis phase of the project so that the stakeholders deciding whether the project should be funded can better understand what is being proposed. I use the key screen prototype to show to prospective users and get their feedback. I also do some usability testing on it to weed out any major design flaws.
When the project is approved, the key screen prototype is useful input to help the developers quickly understand the project.
The initial design does not have to be set in stone. It is possible to rethink it as you progress through the iterations. But you cannot refactor the UI as easily as you refactor code. When you change the UI you are changing the way people interact with the program, and you need to think about the impact the changes will have. It's easy to create confusion, annoyance, and what psychologists call proactive interference (the prior experience with the UI making it hard for the user to learn a new way of doing things). All in all, making UI changes after release is generally unadvisable, so it pays to get the conceptual design right at the beginning.
Ambrose: So, how do you foresee integrating Ux into Agile iterations?
Charlie: Start the conceptual design as early as possible and get it as accurate as you can. Conduct usability tests on your key screen prototype and learn as much as possible from your users and refine the design. Do as much Ux work as possible before the development starts so you can provide the development team with a user validated model to work from.
Once development begins, continue the Ux development but work in a way that does not conflict with the development activity. One technique that is growing in popularity is to create parallel Ux and development tracks and conduct the project so that the Ux design remains one iteration ahead of the programmers. You can see this flow in Figure 1.
Figure 1 Integrating Agile with Ux
On entry to each iteration, the developers have a UI model to work from. While the coding for iteration j is underway, the Ux designers are working on the UI for iteration j+1. When iteration j is released, the Ux team will usability test it to identify any usability design issues and feed that information back to the developers.
In practice you need to be flexible about how you implement this kind of flow. The Ux designers should work closely with the developers so that they can assist with the detailed design. As new functionality is envisioned, the Ux team may develop and test mockups to work out the UI. The Ux team will also address issues that arise late in the development process. The goal is always to give the software engineering team the ability to avoid the expense and frustration of rework.
Ambrose: Can this flow work when you don't have the Ux expertise on the development team? One of the nice things about waterfall methods is that you can hire a Ux consultant up front who can deliver and then make a graceful exit. With Agile it seems as if you need to have the Ux expertise throughout the project.
Charlie: That's true. Of course, many waterfall projects have usability problems precisely because the designer was not around when the actual UI was produced, but there is no question that in a waterfall environment it is easier to use a consultant who can deliver and disappear.
In an Agile setting, I'd like to see the intitial design led by an experienced and competent Ux designer, but once the conceptual design is in place, you can generally use a less experienced designer to create the individual screens. A developer who is willing to champion the cause of Ux can do this, though if you can get someone dedicated to Ux concerns, that's better. That works because the decisions that are made generally have local rather than global consequences and local design is always easier than global design. If you are using a pattern library like Quince, a lot of the design decisions will be simplified.
Ambrose: Okay. Another source of consternation I've found is that Ux guys don't understand how hard things are to implement sometimes. I've found that some developers react to conflict by just saying "we can't do that" when a reasonable compromise would be possible. How can we manage these situations so we work together instead of against each other?
Charlie: The trick is to avoid conflict in the first place. In my experience, there are three sources of conflict that commonly arise:
The first is that developers are often overworked and do not have adequate time to do the job in the way they would like. That's more a management than a Ux problem. But by starting the Ux design upfront you reduce some of the pressure since the development team has a model to start from.
The second sort of conflict takes place when the Ux designers and the developers step on each other's toes. Keeping the Ux an iteration ahead can help circumvent this. And as the team gets more experienced with the process, you can manage this better.
The third source of conflict is more cultural. It occurs when developers don't respect the importance of Ux or when Ux designers fail to understand what's important to the developers. Working toward better understanding is a good goal. But more directly, you can set up a shared accountability situation in which developers and Ux designers succeed or fail together. At the end of the day, it's the quality of the product that matters.
Every study that I've seen and every senior Ux manager I've talked with is clear that integrating Ux into the project saves time and money. The reality is Ux design always makes things easier and if it's not, you're doing something wrong.
So from a process point of view, the key steps are to:
- Design your Agile process to explicitly include Ux as a key component and assign an owner or champion to it.
- Perform essential conceptual design up front so that you can ensure the integrity of the UI as the product evolves.
- Use a lightweight UI process and keep it ahead of the coding so that the developers are not slowed down.
It's as simple as that! Treat Ux as an essential dimension of the development process and make certain that the Ux voice is heard when the going gets rough. Get someone on your team to champion Ux or, better yet, hire a Ux professional and let them do just ENUF design as part of the business analysis and as part of Iteration Zero so you have a solid conceptual design going into the iterations. If you do the ground work, and then work on keeping the design ahead of development so you can work out the major design kinks before coding, you'll improve the user experience while retaining the advantages of Agile.
And if you are using a waterfall process, you can integrate the Ux design practices into it by following similar principles.
Send your questions and comments for Charlie and Ambrose to magux@microsoft.com.
Dr. Charles Kreitzberg is CEO of Cognetics Corporation (www.cognetics.com), which offers usability consulting and user experience design services. His passion is creating intuitive interfaces that engage and delight users while supporting the product's business goals. Charles lives in Central New Jersey where he moonlights as a performing musician.
Ambrose Little lives with his wife and four children in central New Jersey. He's been designing and developing software for more than 10 years and is honored to be an INETA speaker and Microsoft MVP. Lately, he's shifted from technical design to designing for people and is now a user experience designer for Infragistics.