Author of Lean UX for Startups and Build Better Products, Laura Klein is a product management and UX expert with over 20 years experience in tech.
She started her career when the waterfall process dominated product development. In the years since then, she’s practiced multiple forms of Agile.
We sat down with Laura to explore the best practices she’s learned along the way.
For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile.
How do you see Agile and UX working together?
Agile was created for engineers, so it originally didn’t address UX – and honestly, that’s kind of fine. We’ve learned to adapt.
The saying is that “Lean helps you build the right thing. Agile helps you build the thing right.”
Lean Startup is about constantly making sure that you’re working on things that customers will use. Agile is about delivering those things to them quickly and efficiently. They’re both about helping you learn quickly and adapt.
I would argue that any kind of user-centered design contributes to all of that, especially learning. If you use all three of them together it’s easier to build the right thing, and it’s easier to build it the right way, and that is helpful.
But I’m not religious about it, the only thing I don’t love is building things without talking to users.
Could you help walk us through how you’ve seen that Lean/Agile/UCD hybrid process play out successfully in projects?
The Lean Startup process is very much about understanding what you want to build by testing your assumptions with customers. You’ll see that overlaps with UCD methodologies since customer development is a form of user research. We’ve been observing users in the UX community for many years already, so the two work very nicely together.
On the other hand, Agile is a way of organizing your engineering team to release features faster and deliver customer value more quickly.
I’m a big fan, not just of the Lean and Agile philosophy, but also the related discipline of Extreme Programming which includes things like test-driven development, pair programming, and continuous deployment.
Continuous deployment helps deliver the hybrid process – Lean Startup, Agile, and User-Centered Design – because we can be talking to users, observing them, studying their problems, coming up with solutions for them quickly and getting them out in front of users and then measuring the results within a very short period of time
This can be a very Lean Startup, hypothesis-driven process: “If we make this change, we predict it will have this effect. Now let’s test to see if we were right or wrong.” A great advantage, of course, is that we can complete the whole process from hypothesis to validated solution in a matter of hours or days rather than weeks or months.
The key is to always drive your process based on a clear hypothesis. You want to design a small complete thing (not an under-designed thing) as a quick experiment. You can then use Agile processes to break down that complete thing into bite-sized tasks for engineers.
If you involve engineers in the user research, you also gain a greater shared understanding of the problem, which always helps with efficiency. So we come up with our experiment, build it, ship it, measure it, and all of a sudden we’ve gathered meaningful results in a very short period of time. That’s a great cycle to follow, and how I’d combine the different processes.
Now you’ll notice that I didn’t say things like, “Well you always need two-week sprints, and you need a planning meeting, etc”. Daily standups and Scrum are not the point. Those are tactics. They’re not bad! In many cases, they’re incredibly helpful tactics. But they don’t define the process.
The strategy behind Agile is being able to focus on small chunks of work that you can quickly get in front of people to learn if you need to change direction. Continuous integration and continuous deployment help you figure out very quickly if things are broken. You don’t find out 6 months later and then cycle back into the process again.
Agile is not specific tactics. Just like Lean Startup isn’t only A/B testing or customer development and user-centered design isn’t just writing things on post-it notes or making wireframes. Those are just tools. Occasionally using a hammer doesn’t make you a carpenter.
Know the strategies behind your process and adapt the tactics and tools to your team.
How do you fit user research into an Agile process?
Companies newest to Agile struggle most with fitting user research into the process.
They worry about design teams working ahead of engineering, which is really tough at the very beginning of the Agile transition because it means that engineers are sitting around waiting for people to finish designing the stuff that they’re supposed to start building. So, people try to dramatically shorten the design process.
You end up with a collection of tiny waterfalls.
Of course, you can’t avoid that altogether. I don’t believe teams need to do everything together. Not everyone needs to do user research together or sit around and create wireframes together. Designers will need to do some work ahead of engineering so that engineers have something to work on. But they don’t need to design everything ahead of time.
Also, don’t think of user research as something that only happens at the beginning of a project. Certain types of user research do tend to happen early – the generative stuff where you’re learning a lot about your prospective customers and their needs often gets frontloaded – but we need to stay in constant contact with users throughout the project and involve everybody on the team in some of the regular research activities.
In your almost 20+ years in tech as a designer and developer, what are some of the most dangerous UX mistakes you see Agile companies make?
Setting the designer up as the user champion. We should all be user champions.
The other problem I see is creating this series of mini-waterfalls where engineers are just handed very specific things to build with no input into the design or research process, so they don’t have the context to make good decisions.
We need to work together on many product decisions. You can’t just say “I did all the work upfront, now it’s your turn”.
The situation is even worse honestly when you’re dealing with a design agency where the conversation is very much “Here are some comps, implement this,” and then all of a sudden the engineers are left with so many questions that they just answer in the simplest way possible.
It also absolutely drives me nuts when it’s set up as designers versus engineers, and every decision is, “Oh, is this going to be good for the user or good for the engineering team?” We should have a process that’s good for everybody, and that comes from collaborative teams where everybody has an understanding of the user and the ability to contribute to important decisions.
How do you run retros so that people actually “fail better”? instead of just “fail faster”?
In terms of time length, the retros usually run 15-30 minutes. Any longer and it costs a lot – not just in terms of salaries, but also morale. Designers and developers hate disrupting their flow with meetings.
To focus the discussion, I start every retro with the “Start-Stop-Keep” format. Based on our progress in the past sprint:
- What should we start doing that we haven’t already?
- What did we try that we should stop doing?
- What worked so well that we should keep doing it?
We also review metrics of any recent features that shipped. One thing I don’t like about Agile is the misleading feeling of “Done”.
We even have a column on the Kanban board that’s called ‘Done’, right? So, “Oh, I moved it to Done, that task is done.”
That task is not done. It’s just in users’ hands. It’s not done until it’s changed the user behavior in a way that meets the business goal we set. Until then, all you’ve created is output without an outcome.
You might ask some other variations of the questions in your retro, but you must change the conversation from “What did we accomplish in terms of getting working features out the door?” to “What did we accomplish in terms of impacting the business and changing user behavior?”
In an Agile UX process, what else can we do to redefine the meaning of “Done”?
Understand that the job of anyone on a product team is not to ship a feature. Your job is not to write code, your job is to increase a business metric. We need to show that number on a big information dashboard so that everyone can see it.
If we’re telling engineers, “Hey, your job is to knock off 6 tasks a day and hit this particular velocity and close this many issues,” that’s all you will get.
We need to tell the whole team “Hey, your job is to increase this number. Nothing is done until that number’s where it needs to be (and these other numbers haven’t suffered).”
For example, “Increase user activation from 15% to 20% without decreasing retention”.
When you focus on a common goal like that, it also creates a stronger sense of “the product team” versus “the development team” and “the UX team”. Companies need to reward their teams fairly based on those business goals, which is admittedly really hard to do.
For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile.
