This month in Ask UXmatters, our UX experts continue their discussion on how prioritizing the use of agile or Lean development methodologies affects the practice of User Experience. (Check out Part 1 of this conversation.)
Now, in Part 2, our expert panel discusses how a company’s interpretation of the term agile can impact all of the disciplines on a product team—including User Experience. Product or development teams usually drive the adoption of agile or Lean. However, despite agile’s focus on development, our experts emphasize how crucial it is to perform discovery research and design before development sprints begin. Plus, UX designers sometimes find that, because of the frequency of sprints, agile can offer them more opportunities to have greater influence on a project.
Every month in my column Ask UXmatters, 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].
Warren Croce—Principal UX Designer at Staples, Inc.; Principal at Warren Croce Design
Peter Hornsby—Director at Edgerton Riley; UXmatters columnist
Adrian Howard—Generalizing Specialist in Agile/UX
Cory Lebson—Principal Consultant at Lebsontech; Past President, User Experience Professionals’ Association (UXPA); author of The UX Careers Handbook
Q: Do you find that the focus on agile or Lean UX is damaging the practice of UX design as a whole?—from a UXmatters reader
“Agile is an interesting topic because there are so many different interpretations of what the term means,” replies Peter. “One key concern about agile from a UX design perspective is that, because agile was originally a development methodology, agile is often strongly oriented toward the needs of development. The most extreme example of this that I have seen was a scrum master who decided that no design effort would be included in planning because design was ‘not real work.’ Needless to say, trying to fake what should be a useful metric is unethical!”
The Philosophy of the Team Is Key
“While it is completely possible to practice good UX design within an agile or Lean framework, this ultimately depends on the philosophy of the team,” answers Cory. “If a team is rigid in its agile practices—so it’s all about following the method perfectly first and putting customers or users second—agile will absolutely be damaging. But if users or customers come first and a team applies agile flexibly, User Experience can be successful. This means allowing the necessary time for UX research—which sometimes cannot be Lean no matter how much a team wants it to be—and providing opportunities for developing empathy and designing for the users of the product.”
The Importance of the Discovery Sprint
“This is such a timely question for me,” responds Warren. “I’ve now been through transitions to agile in two companies over my career—one quite recently. The thing is: agile is an engineering methodology, and it works really well for organizing development work. But I have yet to be in a situation where agile has worked really well for the design process. Agile works best for design when there is a Sprint 0—essentially a discovery sprint, during which UX professionals can do preliminary work to understand the design problem and experiment a bit. You must do big-picture design work in advance, or you’ll be building the plane while you’re flying it. While this can be exhilarating, the plane would probably crash.”
Agile: An Opportunity to Guide Product Direction
Adrian offers the following guidance: “Short answer: No. Long answer: Still no.
“I’m old and grumpy and have been involved in delivering software products and doing work that now sits under User Experience or user research for more than thirty years. I started doing UX work long before teams adopted agile and Lean practices in any major way.
“And the work is so much easier now than it used to be. These days, I work with teams whose feedback loops take minutes, hours, or days—not weeks, months, or years. This means the cadence of agile lets me slot in generative and evaluative user research that can actually steer the product direction. This is better than having a one-off user research phase, after which various layers of the organization slowly translate my findings into an opaque set of requirements that don’t actually meet the user’s needs. Or later doing a one-off usability-testing phase, during which we get to tell the development team that the product is awful when there’s no opportunity to fix it—for which they quite rightly hate us.
“Now I’m working with teams that are happy dealing with artifacts such as user-story maps. These help teams discuss prioritization within the context of actual customer journeys—instead of creating half a dozen two-inch binders full of contracts and requirements.
“Now I’m working with teams that are working with tools that blur the lines between interaction design, user-interface design, and development, making it vastly easier to experiment at different levels of fidelity—rather than arguing over static wireframes and hardcopy style guides.
“Now I’m working with teams who understand concepts such as assumptions and hypotheses, and acceptance of the need for UX research has been socialized across the whole organization because of the popularity of the ideas coming out of The Lean Startup. This means I can frame design and research work in ways that the rest of the organization can understand—rather than having to spend precious time and resources educating people about these concepts.
“Now I’m working with teams that are building in product analytics from the very start, so we can understand how our customers are using the product in real time. We have continual delivery and feature flags, so we can test options and help validate design decisions. We can spot interesting bits of customer behavior using the real product, then use our learnings to drive our research and design practice elsewhere. This is way better than sending off boxed software on a floppy disk or CD and never knowing in any way at all what the vast majority of our users actually do with it—if anything. I could go on. It’s so, so much better.
“Does this mean that everything is awesome?” asks Adrian. “Hell, no. There are still development teams that are dismissive of UX work. There are still organizations that don’t value research—where the CEO’s bad hunches drive the creation of unusable products and run the organization into the ground. There are still people whose entire focus is on adding more features rather than on designing better features. Obviously, all of this sucks.
“But these are not new problems. Organizations and teams had these problems long before agile came along. The community of practice that became agile never had creating these problems in mind. There is, as they say, no silver bullet. But agile practices give me many, many more levers for helping organizations to do better UX design and research than I’d ever had in the pre-agile days.”
Dr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research. Read More