Moving to Lean UX: why?

If you’re working in an agile multi-disciplinary development team and starting to find the limits of ‘sprint 0’ for UX design, read on.

This post details my experience along with my recommendations when considering a move to Lean UX.

Traditional UX

I’ve always been pretty happy with my approach to UX design; taking chunky ‘epics’, discovering user pain, designing creative solutions and then cutting the design up into sprint-sized pieces to feed the development machine. Eight weeks later, the full design for the epic has been implemented.

That approach to UX — my typical approach for the last 4 or 5 years — can be described as ‘traditional’, apparently. Not my words, Jeff Gothelf’s. It wasn’t perfect, but I was happy with it. Until recently.

1. Know when to switch

A few months ago I moved to a new project to work on a new product in a new area of the market. We weren’t sure who our users were, let alone whether they would part with their money, but not uncharted territory. I set off on my usual trajectory of collaborative team sketching and half-baked research plans to “find people to talk to”. Collectively we picked three features to give us a coherent MVP and explored as much of it as we could, knowing full well that our user base would correct our course as necessary. And then three things happened:

• We learned that our user base was more diverse than we originally imagined
• Alternatives to our product became available
• As a design function, UX was stretched across multiple projects

In my head I loosely translated these circumstances into three problems:

• How can we deliver a useful product to a diverse audience?
• Will it be better, and preferable over an alternative?
• What happens to the product experience if I’m needed elsewhere?

In all honesty, Jeff Gothelf and Josh Seiden’s “Lean UX” was a book which had remained firmly on my “to read” list for quite some time. It needed this particular set of circumstances for me to reach for it, looking for answers.

The Lean UX process

The Lean UX process described in the book would struggle to be more prescriptive. It’s built on 15 principles (more on that below) and I’ve tried to summarise the process here:

1. Work out your assumptions. Your team exists to create a product that solves a problem for someone. In the early days, within the description of that problem, there exists a whole heap of assumptions (about people, technology, abilitym market, value etc); extract those assumptions as the questions you’ll need to answer.
2. Build hypotheses. Hypotheses are formed from all the questions that your assumptions raise. They are beliefs to validate (or invalidate) when talking to users.
3. Agree on Validation Signals. Each hypothesis should have a signal — what you’re looking for in order to be confident that your belief is correct. The data you collect along the way should shape your design and development decisions. Capture them somewhere visible.
4. Describe the feature. Once you’re confident your belief is correct, write a description of the component you’re going to implement in the next sprint.
5. Provide some design. Just enough design to convey the interaction experience, and for the team to anchor themselves to.

2. Understand the size of the switch

As the 15 principles of Lean UX form its foundation, I found it helpful to understand which of them we already exhibited in our team.

If you’re contemplating a switch, I’d recommend cross-referencing the way you work against the table; a tick for “doing”, a cross for “not doing”. The more crosses, the bigger your switch is going to be. We managed a switch with six crosses.

Turning crosses into ticks

In order to get the most from Lean UX, those crosses need to turn into ticks. Think about what that means for you. As an example, one of the areas that I gave a cross to was “small batch size” — in previous projects I usually left behind a mountain of unimplemented designs (or “waste”), I needed to find a way to mitigate that.

3. Setting up for the switch

Once you’ve rationalised your reasons to switch and understood the size of the change required, you’re ready to think about making it happen.

So far I’ve covered identifying why and when to switch. The next step is to plan and make the switch; building and visualising the process and involving the team in making the change (probably the most important part).

Read part two: how to move to Lean UX.