Agile User Experience Design
Published: April 24, 2012
In this edition of Ask UXmatters, our experts discuss the gaps between the agile development model and user experience design. Agile UX is a hot topic right now, so we’re revisiting a discussion that we began in a previous edition of Ask UXmatters, “Integrating UX into Agile Development.”
Ask UXmatters is a monthly column in which our panel of UX experts answers readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: [email protected].
The following experts have contributed answers to this edition of Ask UXmatters:
- Leo Frishberg—Principal Architect, User Experience at Tektronix Inc.
- Pabini Gabriel-Petit—Publisher and Editor in Chief, UXmatters; Principal User Experience Architect at BMC Software; Founding Director of Interaction Design Association (IxDA); UXmatters columnist
- Steven Hoober—Mobile Interaction Designer at Cummins and Author of Designing Mobile Interfaces
- Adrian Howard—Generalizing Specialist in Agile/UX
- Mike Hughes—User Assistance Architect at IBM Internet Security Systems; UXmatters columnist
- Jordan Julien—Independent Experience Strategy Consultant
- Tobias Komischke—Director of User Experience, Infragistics
Q: In your experience, what are the gaps between the agile development model and user experience design? What is the best way to fill these gaps?—from a UXmatters reader
A Key Gap: UX Needs a Clear Product Vision
“Agile is a development methodology and UX design is a design methodology, so right there is a reason why there are gaps,” answers Tobias. “Principally, in agile development, developers are fully aware that they don’t have all of the inputs and knowledge up front—that is, they don’t know what the final product will be like until they’ve completed the last iteration’s build. During each sprint, the team looks at a part of the whole product and works on that. Therefore, the team acquires knowledge and understanding during the individual sprints. Yes, there is a master set of features that the team determines up front and that carry through in the project’s backlog, but there are a lot of issues and details that they’ll identify during the course of the project. For an agile purist, there’s nothing worse than ‘Big design up front.’
“In contrast, in UX design, we want to know everything that’s relevant up front; that’s why we make so much effort to carry out proper context-of-use analyses. We want to anticipate and envision the product holistically—and not just its parts—as soon as possible. What will it look and feel like? This does not mean that we take only one shot at the design—we do ideate and iterate, but we typically want the knowledge to be as complete as possible at the beginning. For UX folks, it’s all about the big design up front, because we want to define and design the product as one holistic user experience and, at the same time, minimize concept ambiguity during implementation.
“Of course, the reality of how these two differing philosophies are lived through the reality of our projects is not black and white, but any possible shade of gray in between those two extremes.”
What should you do when you’re not getting the requirements you need? “Just volunteer to write the vision statement when everyone else seems frustrated by a lack of a clear direction,” suggests Steven. “Go to the Business Analyst and help him write the user stories. Soon, you’ll be a part of the process and can argue for better inclusion in it. For example, depending on how far you want to push it, doing pre-iteration zero holistic wireframes instead of just whiteboards, hand waving, and just sprint-ahead design work.”
“On more than one occasion, I’ve done just that,” says Pabini. “Recently, when working with a development team that didn’t have well-defined user stories that would allow them to define priorities or the scope of each iteration of the project, I volunteered to write the user stories myself. Having a clear vision and requirements are essential prerequisites to doing effective UX design, especially when working on a tight schedule. Whenever these are lacking on a project, I do whatever I can to bring clarity, even if it means that I need to take a greater role in requirements definition than a UX professional typically would.”
“Software Scrum Master: ‘What are we going to deliver in our first release?’
“UX / Product Owner: ‘It’s too soon to know—we don’t have a product vision!’
“While the agile folks decry doing ‘big design’ up front—because it fails to ‘deliver anything real and actionable, is subject to change, and doesn’t reflect true user or customer needs’—UX folks are sometimes hard pressed to take an incremental approach to defining product vision. But this is a false tension: UX folks have plenty of tools that let them engage users to rapidly identify the vision for a product, which is a key necessity to help drive the trajectory of development. In the end, defining product vision is a far better investment of resources up front, because it helps you to avoid massive refactoring downstream.”
Some Definitions of Agile Terminology
By Pabini Gabriel-Petit
theme—A collection of related user stories that has a descriptive name. To reduce the amount of time and effort they’ll spend on estimating, developers can aggregate related user stories into a theme, then treat them a single entity during estimating or release planning.
epic—A large-scale user story that gives an overview of a feature that provides value to a user. An epic often constitutes a theme on its own. Writing epics is usually preliminary to writing more detailed user stories.
user story—A description, in users’ terms, of desired functionality that provides value to a user—that is, something a user wants. User stories break down an epic into smaller, more detailed descriptions of pieces of functionality that a developer can implement during a single iteration.
conditions of satisfaction—Details of a user story that are written in the form of acceptance tests. By the time a user story gets designed, conditions of satisfaction should exist for it.
Writing User Stories
“Colocated product development teams typically capture user stories on note cards. But if you’re working on a distributed team, you can start by identifying themes that describe specific features and capture their epics and user stories in separate tables. These tables may comprise the following columns:
- User Role—As a user, I can…
- User Story—I want to…
- Value—So I can…
- Conditions of Satisfaction—Verify that…
- Notes—Details from discussions
- Level of Effort
“Write an epic describing each feature, then iteratively break the epics down into user stories. But avoid decomposing epics into user stories too far in advance. When writing user stories, determine the proper level of detail to provide, as follows:
- Write small, fine-grained user stories and conditions of satisfaction, and capture any notes from discussions for top-priority features—that is, features the development team will implement in the next few iterations. As a team, set priorities and estimate the level of effort for these user stories. User stories should typically take only 1 or 2 days to implement and no more than 10 days.
- Write an epic and the key user stories—and any other user stories your team wants to capture—for features the development team will implement during later iterations.
Write only epics for low-priority features that the team plans to develop in much later iterations, features that the team may defer to a later release, or features that the team may decide not to implement.
“There are two ways of adding detail to user stories: by writing additional, more fine-grained and subordinate user stories or by adding conditions of satisfaction to existing user stories. These approaches are not mutually exclusive.”
Getting to Clarity: Identifying Exception Cases
“With the time constraints in the design-as-you-go world of agile, I find that UX does a good job of identifying and designing for the happy path, but in my experience, the main gaps have come around the alternate paths and exception cases that did not emerge,” responds Mike. “To counter that, I often write quick use cases to identify and describe potential exception cases—for example, the system times out before the user finishes a task—to make sure we have covered those contingencies in our design.”
The Importance of Physical Proximity
“One of the most common and significant gaps is a physical one,” replies Adrian. “Designers are often physically separate from the rest of the development team. To work well, agile relies on cross-functional teams working together. The process is built upon rapid feedback loops that need close communication between everybody on the team to be effective. If a designer isn’t available to address design issues as they arise, they either become a bottleneck to progress or just get cut out of the loop.
“One of the common patterns you’ll see in successful agile/UX combinations is having the UX designer embedded with the rest of the product development team. Once the team has a designer in residence, the other issues that you encounter are much easier to address. I’ve created a presentation on some methods that UX professionals can adopt to better work with agile teams: ‘Developer/Designer Cross Training (or How to Get Developers to Do Your Work for You)’.”
“Both UX Design and Engineering should be part of a product development organization to ensure that fewer barriers exist between these teams. When UX instead resides in a services group, it’s often a struggle for UX designers to get developers to think of them as an indispensable part of a product team. A UX designer’s being colocated with a Development team is ideal. In fact, one of the principles of agile development is that entire product teams should be colocated. But if, as is all too often the case today, you’re working with a distributed team, follow the sensible advice agile guru Mike Cohn offers in his presentation ‘Scaling Agile to Work with Distributed Teams’.”
Using Sprint 0 to Combine Agile and UX
—which, in an agile development process, is when you define the backlog—to do UX design, which then feeds into the backlog.”—Tobias Komischke
“In my mind, the best way to combine agile and UX is to use Sprint 0—which, in an agile development process, is when you define the backlog—to do UX design, which then feeds into the backlog,” suggest Tobias. “This may seem to be contrary to the agile idea—no big design up front—but this is design, not coding. UX design is not carried out by architects or developers, so those roles are not affected by that workload. But they do get better inputs going into their sprints. From a project and product management perspective, you need to plan the time for an extended Sprint 0.”
Tobias recommends Daniel Rosenberg’s article, “The View from Here: Garbage In, Garbage Out, the Agile Way,” which appeared in User Experience Magazine.
“No matter what type of development process a product team is following—but especially on an agile development project—it’s imperative that sufficient time be allocated for UX design,” says Pabini. “On an agile project, that typically means UX design needs to stay one sprint ahead of Development, starting with Iteration 0. However, when front-end development is part of User Experience, it’s possible for there to be a much closer coupling between User Experience and Development, and UX deliverables can be working code instead of the detailed documentation that agile purists abhor. For more about combining UX design and front-end development, see Jim Nieters, Amit Pande, and Uday Shankar’s column, ‘Great User Experiences Require Great Front-End Development’ in this issue of UXmatters.”
What Does It Mean to Be Truly Agile?
“I’ve worked in several agencies that followed an agile or semi-agile development process,” says Jordan. “It’s definitely a different way of working. If you simply accept that agile is a development process, I think you’ve overcome the first hurdle. I once worked in a semi-agile environment in which the final deliverable was a set of PSDs—it didn’t work well. Since agile is a development process, it really needs to result in functioning software—at least a running prototype.
“The only other major hurdle I’ve faced is that very few people really understand how to run a project in a truly agile way, so most places don’t try. It’s hard enough to educate a whole product team on how to adhere to an agile process, but when you start including vendors who use a waterfall process, it becomes almost impossible to complete a project in a truly agile way.
“When agile is implemented properly, the first question to answer is how to incorporate User Experience into each sprint. The most effective way of working that I’ve witnessed is to create a site structure in Sprint 0, then team up with creative and development for the rest of the sprints. In some cases, the role of User Experience might be merely consultative, helping the Development team to create solutions to each user story or epic.”
“I believe the gaps between User Experience and any development process are all in people’s perceptions. My experience in analyzing and implementing projects using about a dozen different development processes—including 150 agile projects—is that the real gaps lie within each of these processes,” says Steven. “Assumptions get made—‘we all do that’ or ‘oh, the Business Analyst does that,’ but without formal guidelines as to how to do it. For example, in agile, epic and user story creation is often rather muddled and prone to resulting in very developer-centric products that might work, but are not necessarily useful. User Experience can fill this gap by using our processes of discovery, analysis, and design to write user stories for products that really meet user needs and business goals by truly fulfilling a singular vision of a desired product.
“Another place User Experience can help is in determining the success of a project and being a key player in acceptance testing. If you work in an organization that is sufficiently agile to launch products before they are final—and is not beholden to corporate IT launch windows—it can be hard for developers and product owners to identify the feature set for a minimally viable product. UX professionals can draw a straight line from goals, objectives, principles, and vision statements to the current product and help everyone to decide whether now or three sprints later would be the right time to launch.”
Pabini offers this advice, “For a deeper understanding of agile software development, I recommend that you read Mike Cohn’s books and other writings:
- User Stories Applied: For Agile Software Development—This is a great book on writing user stories and one of the few books on agile development that takes user experience into account at all.
- Agile Estimating and Planning—Since accurate estimation of development effort is a key part of the usefulness of user stories, this book is highly complementary to User Stories Applied.
- Mountain Goat Software—Mike Cohn’s Web site offers a treasure trove of information about agile software development. The site’s Resource Library includes articles, presentations from his workshops, and videos of some of his conference presentations.
“Armed with this information, you’ll be able to take a more proactive role on an agile product team and make contributions to the team that will give you greater credibility among developers. As a UX professional, it’s always helpful to demonstrate that you understand good software development and project management practices.”
“To fill the perceived gaps, you just need to fill them,” recommends Steven. “Be prepared to defend the value of user experience as an evidence-based practice. The perception is often that it’s drawing, drawing is art, art is opinion, and everyone has an opinion—and one beholden to schedules and processes. But demonstrating the value of user experience is the strongest proof.”