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.”