Adrian Howard is passionate about creating great teams and great products. With over 15 years of experience working with startups, established businesses, and agencies, Adrian is an active member of the Agile and Lean UX communities. He co-founded his agency Quietstars to specifically help companies integrate business processes with design and Agile methodologies.
We recently spoke with Adrian to explore how to avoid the common pitfalls of integrating UX and Agile. Here’s what he had to say.
For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile.
Have you seen any gaps between Agile processes and user-centered design?
I don’t think Agile and UCD are misaligned in intent. We only create gaps through malpractice and misunderstanding.
People often say Agile is a very developer-focused set of practices. That’s not entirely true.
While Agile definitely originated from the developer world, the focus was very much on, “Let’s stop building crap products. Let’s start making our customer happier. Let’s start listening to our customer. Let’s have much tighter feedback loops. Let’s deliver actual value.” All those principles completely align with UX goals.
You’ll find a lot of stuff out there that’s Agile in name only. It’s the same as passing off rubbish design in Photoshop as UX work. There’s a lot of, “We’re going to jump on the latest buzzword because we hear it’s good.”
But the company does’nt understand the underlying strategy behind Agile. So you get a lot of Cargo Cult Scrum, especially in larger organizations where people run the sausage machine at the development team as fast as possible, pushing functionally sound features out all the time without enough user validation.
As far as I’m concerned, that’s not Agile at all. That’s just a superficial interpretation.
What is one of the top mistakes you’ve seen companies repeat as they practice UX in an Agile environment?
Because a consistent stream of feedback usually pours in during Agile product development, some companies might assume usability testing and user research skills aren’t required. The product team is already pushing incremental features live and hearing from customers quickly, so what more do they need?
The fallacy is that unless your team has at least basic skills in user research or usability testing, you might hear about the problems from users, but you won’t know how to steer the product out of those problems.
So how can Agile teams build up more UX competency to better act on user feedback?
Increase the whole product team’s user exposure hours. Don’t just rely on passive user feedback coming through customer support, or usability reports delivered by a researcher or designer.
In fact, if you look at the origins of Extreme Programming, the creator Kent Beck actually embedded a user into the product development for Chrysler’s Compensation System (the test bed for his XP methdology).
Of course, that kind of Stockholm Syndrome-esque approach does come with potential bias since the customer becomes part of the development team. But still, even at that level, the whole team at least was in regular contact with the end-user.
Usability reports are easily ignored by development teams. However, if a developer attends even just 1 hour of usability testing a week, the feedback hits home immediately. People will instantly believe and understand a designer’s recommendations because they’ve experienced the visceral power of seeing a poor old end-user having a horrible time with the product. You don’t need as much documentation to convey your point.
Try an incremental process of drip-feeding your exposure hours. Every other week spend a few hours with developers interviewing users and moderating usability testing. Incremental research provides more value because people apply insights by the next sprint.
Spreading out your user research is an easier sell to organizations than trying to convince them to spend $60-70,000 on a month’s worth of user interviews all at once. You spend less upfront, show results quicker, which earns more support for thorough research.
You spend much less on user research upfront, and you gain buy-in more quickly since you can show the problems you fixed. Plus, you’re constantly steering the product in the right direction as you uncover new customer needs since the time you started the project.
I have a cliche slogan which is: “Do less more often together to do more”.
Do you think component-based design helps with UX in Agile processes?
It certainly relieves many pain points.
For example, I run this workshop exercise where I show wireframes of popular sites to developers, and designers. I give everyone a few minutes to write down their observations. Developers will say “These are the elements of the application, this is the form X1 for next the page, this is the edge case, etc”. Designers will talk about vertical rhythm, typography, and overall interaction flow.
Everyone sees a different part of the elephant. Component-based design helps you reduce that misinterpretation and resulting approval bottlenecks.
When you have a shared design language that breaks down into universal UI patterns and elements, designers no longer need to create everything for signoff. The whole team now has a toolbox for exploring new ideas or refactoring the existing UI.
As a result, the product team’s conversations are much more strategic.
Instead of developers wading through minutiae when asking a designer to recreate a whole page, everyone knows how the pieces fit together. We know the forms we should use and the interactions we should support. Your sprint release quality improves since developers with little design background can implement mockups and prototypes with less risk of inconsistency.
By democratizing the design implementation, the designers are then freed up to focus on the more difficult business problems. You get to “done” faster and better.
Does the fast pace of Agile UX increase risk of experience debt?
Only if you focus purely on speed of release.
Agile is not just about delivering faster. In fact, the more crap you release, the more crap you need to wade through, and the slower you’ll become anyways.
The issue of UX debt in an Agile process all depends on your organizational values. Does the company care more about keeping the development team at 100% capacity, throwing out tons of features, or about delivering value?
Because if it’s the former, then nobody is really incentivized to dedicate time to “payback sprints” to clean up as they go.
You need to develop against a hypothesis (like Lean UX advocates) and prioritize your work according to the Kano model, otherwise you will inevitably create unmanageable UX debt.
Going back to my earlier point, you need collaborative incremental user research to keep your Agile sprints in check. When the product manager and developer sees five people in a usability testing all fail miserably to register for an account, the designer doesn’t need to fight as hard to justify an iteration sprint versus being forced to dive into the next feature.
When an experimental strategy drives the Agile UX process, you can better remove the danger of people sticking to their plans for fear of losing face.
For more advice and case studies from 10 UX practitioners, download theDefinitive Guide to Integrating UX and Agile.