Lean UX – Designing Great Products with Agile Teams

It had been a while since I wanted to read this book. Back in 2016, as a designer working on a project for a big Malaysian Media Company, my colleagues and I suffered from having to create lengthy Functional Spec Documents. Those were explaining in details every possible interaction on each screen. And, as we were designing a multi-platform digital service, each platform had its own Functional Spec Document. The client kept asking for changes. And each change had to be replicated across all documents. Sometimes, in order to update a single page, we had to open multiple documents and use multiple softwares (Illustrator, Photoshop, Omnigraffle…). Causing a domino effect…

… and making our lives miserable 😔

I knew at that time that something was wrong and that product design should be done more intelligently. This is when I started to read about Lean UX online. Quickly I stumbled upon the names of Jeff Gothelf and Josh Seiden and their book: “Lean UX – Designing Great Products with Agile Teams”.

A combination of several schools of thought

Lean UX is a combination of User Experience Design, Design thinking, Agile and Lean Startup methods. (Jeff Gothelf wrote a small book that you can read in 30 minutes to explain each of those). Some companies might have a tendency to lean towards one of these in particular. Even, oftentimes, departments within the same company will choose their own methods: engineers would strive for being Agile, PMs would advocate Lean Startups processes while design teams would value human-centred approaches and Design thinking methods. This resulting in different KPIs, visions and goals.
You name it: misalignment.

Lean UX advocates an eclectic approach which borrows from each. It stresses on principles such as:

  • Declaring assumptions as such: everything is an assumption until proven otherwise.
  • Small cross-functional teams: ‘minimum viable conversations’ and shared understanding that remove the need for heavy documentation and deliverables (“Getting out of the deliverable business”). Team members can then focus more on what produces the biggest impact for both users and business
  • Removing waste: anything that doesn’t contribute to improved outcomes is considered waste and should be removed from the Team’s process
  • Externalizing work: artifacts walls, printouts, sticky notes, whiteboards… The goal being to make clear, for everyone in the company, what’s going on. Sparking informal conversations can go a long way and uncover precious insights from people who, otherwise, might not have felt they had a say.

There are more principles detailed in the book. I want to highlight a couple of them that I found particularly relevant to me as a Product Designer.

Outcomes, not outputs

Teams need to aim at creating a meaningful and measurable change in customers’ behaviour rather than engaging in a risky speculation about features that haven’t been validated by users. Thinking in terms of outcomes forces team members to adopt a User Centric perspective. While thinking only in term of ‘feature’ or ‘code delivery’ will potentially produce more abstract productivity-led results. Sure, productivity is important. But that’s not the only factor for digital product success. And team members will often feel more motivated to work on something that improves other people’s lives—therefore on something meaningful—rather than just… be fast.
If you’re interested in knowing more about Outcomes vs. Outputs, I would recommend the short book from Joshua Seiden: “Outcomes over Output – Why customer behaviour is the key metric for business success”.

Design made in isolation is no longer an option

Design shouldn’t be siloed with its output only handed over to other team members at the very end. Not only designers should participate in User Research sessions. Seeing real users struggling when using a product or hearing them voicing their issues is always more striking and memorable for colleagues than reading a lengthy report written by a team member in isolation. Same goes for ‘Design Studio’ sessions that leverage the power of collective thinking from various team members. In this context, the designer must become a facilitator and open up the design process. Design truly is Team Work.

Ditch the ‘hero-guru-ninja’ Designer

The time when a solo designer would call the shots is over. Strong egos looking for spotlight and fame won’t fit the Lean UX principles. Designers—as well as other team members—have to embrace uncertainty, experiment, failure, refinement… As well as a team-based mentality fostering cohesion and collaboration. Humility is key in the face of the unknown.

High Risk, High Value

Prioritisation of hypotheses (and therefore work) is crucial in Lean UX. Using the Risk Prioritisation Matrix can help visualise what needs to be tested first so that the team focuses on what could potentially bring the highest value as soon as possible. And discard what is actually a wrong problem to solve as early as possible.

Letting go of perfection

Product Designers—especially the ‘perfectionist type’—need to adopt iterative design and aim for continuous improvement rather than perfection at every single release. There’s no such thing as perfection. Would it even be a thing, it could only be ephemeral, since our world keeps changing: technology, user habits, context of use… Something that is true today might be wrong tomorrow. Additionally, there are things that you will only learn by releasing and from subsequent monitoring of people’s usage.


Reading this book was for me a confirmation that my job as a designer has evolved. I don’t design the same way I used to 10 years ago. As in many industries, one has to evolve and adapt in order to stay afloat and relevant.
Depending on how a company operates (a start-up building its own product vs. an agency working for clients), adopting Lean UX principles and processes might turn out more or less challenging. Sometimes heavy deliverables will still be expected (as it was the case for me in 2016, working for this media company). Sometimes, you won’t be able to do as much research as you wanted. Other times, you will wish other departments would understand your operation mode better.
The mindset changes required to become ‘UX-Lean’ aren’t the responsibility of a sole person. Those SHIFTs (they are several of them described at the end of the book) are about company culture change. They are about shifting a team’s organization and processes. This is about the big picture. This is a big deal!
In the recent years, designers voiced their aspiration of ‘having a seat at the table’. Having this coveted seat means being curious about how a company operates, curious about other departments’ ways of working. It’s about understanding the business and how Design fits in the big picture. It’s about identifying areas where improvements can be made and being able to gather consensus around potential solutions. Both hard and soft skills will be needed along the way.