Moving my team to Lean UX

I’ve been studying Lean UX by Jeff Gothelf and Josh Seiden for the last three years. I would never imagined to find such a mature environment in my current team, LeanPanda, to start implementing it.

What has been the main ingredient? Frustration.

It’s full of people here, at LeanPanda, with more than ten years of web experience. Everybody knows waterfall’s frustrations after ten years of experience.

Estimate reading 7 minutes
Some devs from LeanPanda team

This doesn’t mean that Lean UX isn’t still hard to implement.

The first tip when trying to implement Lean UX in your team is 10% talking, 90% doing.

Well, this is a great life tip in general. In our work environment, let’s start now by reducing meetings. In project design and development, this can be done by Lean UX practices such as workshops, ITMs, Stand Up’s, etc.

One well-guided workshop is worth five meetings

And this ratio changes according to the difficulty of the project, and according to waterfall’s errors.

Waterfall needs to be prevented

How? Understanding Lean UX principles, not Lean UX techniques. The more we understand the principles behind Lean UX, the more we make the right choices. Because there is no perfect methodology in the UX world, no premium salvation plans to buy for us.

We don’t need a UX methodology, we need to deeply, deeply understand (almost meditate) the principles behind a UX methodology, and then study and experiment with all the practices suggested. Yes, this means that we need a UX methodology, but we don’t need it in term of a medicine or a strict protocol.

Lean UX was born from the frustration of UX Designers who couldn’t fit well in Agile cycles. How could we be Agile without a UX root? UX is not about usability of pages or good flows.

UX is about:

  • Ethic. Why do we do things? Are we creating something useful for humanity?
  • Business strategy. Am I going to lose money with my new cool idea?
  • Science. Testing, testing, testing. Doing things with a scientific provable reason. “We will know this feature of the product will help humanity when we see this signal from the market”.

Technology has a lot of power over humanity, and we should always have the whys as the root of everything we design.

Missing UX is like building houses without an architect

Imagine bricklayers improvising their work! That’s what we do when we throw ourselves at our keyboards as soon as we hear about a new exciting project.

So: implementing Lean UX

Here at LeanPanda moving from Agile/Scrum to Lean UX is very hard, because we are an agency with a consistent number of clients, and we are scared by practices which might steal time from developers already tied into a working machine, and we, as humans, are scared of the unknown.


  • How can I know the exact team from the early beginning of a project? We have so many people in so many projects.
  • How can I sell a way of working to a client if I’ve never tried it?
  • How many team workshops… all these people together cost money!

Reasonable questions. Where can we find the answer? through trial and error.

While facing frustration you have two roads: change or stalemate. Being passive to events and the evolution of the Web, or being active.

Waterfall is frustration, as is Agile taken by itself.

What’s the frustration for Agile companies? Being a “cook-me-this” developer team. being rooted in the “what” and not of the “why”. Creating care of deliverables based on unreasoned requirements. Companies like this will never grow in term of real quality. They think they grow because they think that quality is delivering something quickly. The quality of a house depends on the architect’s project, not on the speed it is built. Well, speed is an important factor, but not the basis of the project. Lean UX is inspired by and respects the Agile manifesto as an important part of the methodology, but the root is in UX.

The Root is always where the whys are

So how can we do it? How can we start moving towards Lean UX?

Without talking that much.

Don’t talk with your team leaders about how to implement Lean UX. Do as I did: run a presentation to the whole team. I prepared a 50-slide presentation, with some pieces of YouTube video of Jeff Gothelf talking, and some examples like the Nordstorm Innovation Lab video, as well as a little analysis of Sketchin’s method called Evo.

Track the team’s current methodology, and ask yourself: “next week, how can I experiment one piece of Lean UX?”.

Then, action.

So yesterday, at LeanPanda, we made it with the first internal workshop.

Our first lean-ux workshop

And next week we are going to do this with ten people.

We realized that this workshop is not so different from things we have already been doing in our company, and it solved a lot of problems, and brought tons of value. You know, I’ve been studying books and UX authors for the last three years, and yesterday I felt like all the pieces merged together.

Look at the bearded guy on the right (in the prev picture). He is one of the four founders at LeanPanda, and really helped me in this mission of implementing Lean UX.

This doesn’t mean that you are not going to be able to make it if you are the only person with this vision on your team. Having a UX enthusiast of course helps, but I had some troubles too at the beginning because I wanted to speak about implementing Lean UX, instead of starting to do it. So I was looking for people who had the same ideas and understandings as me and hoped to hear “wow, you are right, this is the future”. Blind alley, no way. Because, maybe it is not the future. Everything is a hypothesis, so let’s start validating it. In your team you are going to find people with frustrations, but it doesn’t mean that they have your same solutions.

So, frustration is enough. Perfect. Then:

Throw a workshop, not a meeting. Ask people to participate in your UX flow. Meanwhile, run a presentation about Lean UX. Find the perfect mix of theory and practice, but always give more space to practice. This is the best way to introduce Lean UX into your team.

As I said, next week we are going to run this workshop for a very big project: Uffizi Gallery, Florence, the 4th most important museum in the world. It would take at least three days to visit all their museum structures, and you can’t imagine the complexity of the departments of people working inside the organization.

How many risks are there of going off-topic or not capturing the relevant points? Quite apart from the fact that our initial workshop will comprise ten or more people.

By the way, we think that a structured workshop should work. Uffizi’s communication team is going to stick Post-its on the board with us, and I know it is going to be very interesting :)

We still need to experiment a lot (Design Studio workshop, iterations based on hypotheses, weekly user testing, and so on), and our plan is to experiment piece by piece. You know, working this way, monitoring of margins of error will improve progressively. UX design really is science based on experiments, so the deeper you go, the more you gain power to wisely change.

I really would like to know how you guys are doing with Lean UX implementation because I know it’s no picnic :)

Thanks for reading! And a happy new year from LeanPanda

Did you find this interesting?Know us better

Made with Middleman and DatoCMS, our CMS for static websites