Traditional, heavyweight development methodologies can be very effective at solving well?defined problems, where the person solving the problem has a clear understanding of the initial and goal states, the available options, and the constraints on the problem. At the opposite end of the spectrum are ill?defined, so-called wicked problems. When it’s necessary to balance numerous, often?conflicting factors, traditional development methodologies are much less effective.
Champion Advertisement
Continue Reading…
Raymonde Guindon demonstrated that—in stark contrast to the highly structured methodologies traditional software development organizations have used, moving from requirements through development to delivery—software engineers dealing with ill?defined problems move repeatedly between examining scenarios, clarifying requirements, defining their solution at a high level, and doing low?level design for difficult elements. [2] Agile development approaches are best suited to solving these kinds of thorny problems. Wikipedia defines agile software development, as follows:
“a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self?organizing cross?functional teams.”—Wikipedia [3]
Agile development is an interesting approach from a UX perspective for two reasons:
It better reflects the way people actually solve most problems.
It contrasts sharply with the way many—perhaps most—UX designers work.
Since agile methods appear to more closely match the way people typically solve problems, they can be helpful in solving the types of complex, interrelated problems organizations increasingly call upon UX designers to address. Understanding how user experience might operate in an agile development environment could help us respond more flexibly and effectively, regardless of the development methodology our organizations are using.
The Agile Approach
While there are a number of different agile development approaches, there are certain elements they have in common. The Manifesto for Agile Software Development states:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work 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
“That is, while there is value in the items on the right, we value the items on the left more.”—The Manifesto for Agile Software Development [4]
Part of the motivation for the development of agile approaches was to create software in a more people?centric way. So, philosophically, agile development approaches are more user centered than more conventional methodologies!
Agile teams are typically cross?functional—with more emphasis on the skills of the team members than on organizational roles—and small—comprising less than 10 people. Development takes place through a series of iterations—typically lasting between 1 and 4 weeks. Through all stages of the development process, the team delivers working, tested software at the end of each iteration. Thus, while a team improves and adds functionality over the course of a project, working software is always available after the first iteration. Stakeholders prioritize requirements according to their business value, and working software is the primary measure of how a project is progressing. Each agile team includes a customer representative, who is available to answer questions regarding the problem domain.
Challenges to UX
In an agile development process, the regular delivery of software to customers as a team adds functionality is probably the single biggest challenge for UX designers, who must maintain, as far as possible, a consistent user experience across features, without changing UX redesigns’ regularly requiring users to relearn how to interact with the software. Establishing broad design principles early in the development process, understanding user characteristics and their probable demands on the software, and designing in a way that anticipates these—without committing to them—can maximize the degrees of freedom for a design. For an established team or problem domain, there may also be opportunities to reuse existing design components, or patterns. (For more about reuse, see my UXmatters column “Reusing the User Experience.”)
To the furthest extent possible, UX designers must understand the planned direction for software development, particularly when designing navigation. In some development environments, it may be feasible for UX designers to work in parallel with the rest of an agile team, developing the UX design slightly in advance of the next development cycle. In later design cycles, being able to refactor the user experience can help keep an application’s design clean and flexible. (See my UXmatters column “Refactoring the User Experience.”)
Having a customer representative as part of the development team can be a huge benefit on a project—particularly if the customer representative is also a target user. Team members can question the customer representative directly rather than having to rely solely on representations of users, and at all times, the team’s awareness of who they’re developing the software for remains very clear. For software with multiple target user groups, you must take care to avoid representing one user group over others, particularly if the customer representative is not from the primary user group.
Stockholm syndrome, in which the customer representative comes to identify more with the development team than with the customer base, can sometimes be an issue. Addressing this problem could involve regularly changing the customer representative to reflect the primary user group for which the team is currently doing development. To maintain a degree of consistency across development cycles, interactions with customer representatives should supplement rather than replace established user-centered design techniques such as the development of personas and scenarios. With an actual user as part of a development team, UX designers’ role as a gateway to the understanding of users can be reduced, which may, in turn, free their time to focus on other issues.
In some agile organizations, no one individual or team clearly owns the design and development of user experience. While collaboration is vital to an agile team, it is a collaboration between generalizing specialists. In an agile context, a UX professional must own user experience, but interactions with other team members should inform their design solutions. This, in turn, implies that UX designers on agile teams must be experienced individuals, who are able to make decisions about the user experience and plan within a broad framework.
A greater challenge to implementing an agile approach exists in organizations where either some of the development work is outsourced or co?location of the entire agile team is not possible. In such situations, teleconferences and video conferences can be useful in keeping the team coordinated.
Rapidly prototyping a user experience—using tools such as Axure or even paper prototypes—can let you elicit rapid feedback on your designs. As always, whenever possible, test the usability of your designs with representative users. However, heuristic evaluation techniques can provide high value for a minimal outlay of time and resources, and they can help other development team members understand the software’s user experience.
Agile approaches present new challenges to usability testing as well, requiring you to ensure that your testing focuses tightly on the areas of the user experience that a development release affects. Some organizations using conventional development methodologies undertake usability testing just before a product’s release. However, in an agile environment, there are many releases, occurring at frequent intervals, so there is significant pressure to manage usability testing resources effectively. Usability testing may not always be appropriate, depending on the nature of a release. A development cycle with little or no UX involvement—such as one that focuses on improving the software’s performance—may require no usability testing. Having a customer representative on an agile team can offer greater access to representative users from the target user group as test participants.
Summary
Agile development approaches present huge challenges to user experience, but also offer huge opportunities, particularly by bringing UX designers and software engineers more closely together to focus on clear, short-term goals. Increased mutual understanding always promotes greater effectiveness, regardless of the development methodology your organization uses. Fundamentally, agile development approaches embrace fluid requirements and let you work the way people typically solve problems.
Agile methods challenge UX professionals to be more flexible and adaptable, to work more closely with developers, and to have closer contact with a product’s users. They force UX designers to work more closely with other participants in the development process than traditional development methodologies do. This, in turn, places greater pressure on designers to understand the constraints all team members must operate within. Agile methods are not appropriate for all projects, but working in a more agile way can help UX professionals deal with changing requirements more flexibly.
References
[1] Rich, Ben R., and Leo Janos. Skunk Works. London: Warner Books, 1994.
I agree that having a customer represented in an agile team is helpful, but I think usability testing in that situation is even more important. I’ve found that the user interface tends to be overly influenced by that user when he or she is the only expert. There’s also no way to guarantee that the customer representative is a customer! In many cases, they’ve been managers or representatives from sales. I think usability testing other customers is a very effective way to convince the customer—or sales rep—that their opinion isn’t necessarily accurate.
User feedback that doesn’t apply to a specific iteration certainly has to be separated from the recommendations we provide to the developers. But that feedback can become new stories for future iterations. I guess I’m saying that I’ve found usability testing to be incredibly valuable in agile environments.
Hi, Thanks for your feedback! I agree that one of the few absolutes across development methods is that the design must be informed by an understanding of all the users. If, in an agile process, the customer representative across the lifecycle of the project can be a user, this can provide the development team with insights from the horses mouth that they would not otherwise get. More traditional approaches to understanding users such as personas must be employed to keep the range of users and their requirements at the forefront in the development process and to avoid a single voice being heard to the exclusion of all others. As you say, testing—particularly using lightweight approaches—can provide the development team with the checks and balances needed to ensure that development is on the right track.
I wrote an article about user representatives (and similar) in agile processes. I have to say that, although they may be better than nothing at all, they are not a user-centered approach. For anyone who is interested, I run an Agile UCD course in London (and elsewhere) from time to time.
My article on user representatives, “Adopting User-Centered Design Within An Agile Process: A Conversation,” can be found here (fourth link under Talks and Papers).
Peter has been actively involved in Web design and development since 1993, working in the defense and telecommunications industries; designing a number of interactive, Web-based systems; and advising on usability. He has also worked in education, in both industry and academia, designing and delivering both classroom-based and online training. Peter is a Director at Edgerton Riley, which provides UX consultancy and research to technology firms. Peter has a PhD in software component reuse and a Bachelors degree in human factors, both from Loughborough University, in Leicestershire, UK. He has presented at international conferences and written about reuse, eLearning, and organizational design. Read More
