4 Reflections on "Lean UX"

| Comments

I recently read Lean UX - Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seiden.

The book is part of the Lean series published by O’Reilly and curated by Eric Ries. I’d previously read Ash Maurya’s excellent Running Lean, and thought I’d give a couple of the other books in the series a go. This book did not disappoint. It is a short and practical guide, expanding on the ideas in the Lean Startup book and applying them to UX design – not only in the context of startups but in any kind of software production.

There’s a lot of thought provoking material in the book, but there were four things that were especially interesting to me.

Design Thinking

Lean UX, as defined in the book, is the combination of design thinking, agile development, and the Lean Startup. When it comes to the first two, I was pretty much sold already: I’ve been working in agile projects pretty much exclusively for several years, and have also gotten pretty familiar with the Lean Startup method over the past few months, since I started at Deveo. Combining the two seems like an excellent idea to me, and I’ve actually written about why I think so.

However, design thinking is something I’m not that familiar with as a concept. This is probably mostly due to the fact that I’ve never been a professional designer, but even the authors seemed to struggle defining what design thinking means, having to resort to something that reads like consultant-speak:

Design thinking takes a solution-focused approach to problem solving, working collaboratively to iterate an endless, shifting path toward perfection.

The Wikipedia page has a slightly different take:

Design thinking refers to the methods and processes for investigating ill-defined problems, acquiring information, analyzing knowledge, and positing solutions in the design and planning fields.

It seems to me that design thinking is a term that refers to a range of techniques and thinking styles that people in the design world use to solve difficult problems. While I can’t quite perceive yet what it brings to the Lean UX approach specifically, it’s something I definitely want to learn more about. There’s no shortage of hard problems in, say, programming or business development, that are not strictly design related, and if there are tools designers have that I could apply to solve some of these hard problems, I’d like to know about them.

From Features to Outcomes

To me, this is the most powerful idea in the book: A software development team should not be working from a backlog of features. Instead, it should be working towards specific business outcomes, using a backlog of hypotheses about those outcomes. A feature should not be the main unit of progress. A feature is merely a tactic for achieving an outcome.

We should acknowledge that whenever we begin a software project, we’re making a huge number of assumptions about the product, the market, the users, and the competitors that may or may not be true. It is dangerous to make big, far-reaching plans based on those assumptions. While agile development does away with much of this Big Planning, there’s still a lot of assumptions baked into a typical user story backlog.

This is where the Lean Startup method comes in: When we acknowledge our plans are based on assumptions, we can form falsifiable hypotheses based on those assumptions, and then we can apply the scientific method and test whether those hypotheses (and the underlying assumptions) are true or not. This is something every lean startup does, but it is also something I’ve never seen done with any kind of rigor in an agile project within an established organization.

This method gives the team a whole lot of power: They are no longer working from a feature backlog handed down to them from “business experts”. They need to understand what the business needs from them, and based on that they get to explore and find out how to achieve those goals. This demands a lot from the organization and the management culture, and the book outlines several techniques for getting there.

I’d also argue this demands a lot from the team. We are talking about difficult work, and even a highly performing team is going to fail repeatedly – that is a big part of the learning process. But I think doing this consistently and reliably when pressure is on does require a certain level of maturity from the team. Martin Fowler’s recent discussion on Agile Fluency seems like a decent tool for gauging whether a team is ready for a full-blown outcomes-based process.

Continuous Testing

At Deveo we have incorporated usability testing as part of our process, but so far we’ve only done it sporadically, when there are some bigger changes happening that seem to warrant the extra effort.

Given that I felt pretty good about having been doing some testing, what the book suggested was quite a jolt: We should be running these tests every single week. One morning every week, we should get the whole team together, get some test subjects in, and test whatever we have going on at the moment. It wouldn’t have to be production-quality code, but it could also be prototypes - whatever is ready when the tests are scheduled.

At first this felt like an unpractical and expensive thing to do. Right now I’m not so sure. Our experiences from doing usability testing have been excellent, so why not? It would help keep us honest about what we’re doing and that it meets the needs of our users.

There is, of course, a budget involved, and a lot of practicalities to sort out. Recruiting test subjects, for example, would need to be outsourced since we wouldn’t want to spend our precious time on things like that. But we will definitely consider it.

UX Design and Scrum

Although at Deveo we’re doing Kanban style development instead of Scrum, I do like Scrum and it’s been my main mode of operation for the last 7 years or so. This is why I was interested in seeings what the book has to say about doing UX design in Scrum projects.

The most common approach for combining Scrum and UX design is what the book calls staggered sprints: The UX designer or design team are working a sprint ahead of the development team, designing the features to be implemented in the next sprint.

While this approach does work, particularly while still transitioning to agile, it does have its problems: There is little collaboration between designers and developers because they’re at no point in time all working on the same thing. This also makes the focus of the designers shift from working software to deliverables: They need to produce design assets for the developers to use, and they don’t get to work on the final product so much.

What the book proposes as an improvement to staggered sprints is a model where the UX design process is baked right into the flow of Scrum: In release and sprint planning meetings, outcomes are planned and hypotheses formed. Since user tests are held each week, there’s time within each sprint to validate the hypotheses and react to the results. Designers are working in the project full time and they participate in all meetings – they are part of the team.

The approach seems solid, but of course that’s often the case when you’re reading things from a book. I’d love to hear more about applications of the combination of Lean UX and Scrum, and how it’s playing out in different contexts.

Comments