According to Lean UX, everything that does not directly increase the value of the end result is seen as waste. Could cutting “the fluff” lead to faster and cheaper deliveries of higher quality?
How often have you been enthused by a brilliant strategy, insight presentation or graphic design, only to be endlessly disappointed with the product that came out in the other end? Some of that great work done upfront might be made use of later.
- But what if the product failed after initial launch?
- Could cutting the fluff mean faster, cheaper and better product development?
These are the lean and mean questions we’re asking in UX these days. Lean appears to be on everyone’s lips these days. What is it and why is it worth considering?
The foundation of Lean
If you have a “dark past” from business school like myself, you will have heard about lean manufacturing, Toyota Production System (TPS) or just-in-time production. These ideas and principles originated in Japan after the second world war and onwards. The main objectives of TPS are to design out overburden (muri) and inconsistency (mura), and to eliminate waste (muda).
A scene of the Design Office at the Koromo Plant, examining design drawings for the model BX truck, April 6, 1950. Photo: Toyota.
As the firms in the US and Europe started taking the thinking on board, the process became known under the more generic term of “lean manufacturing” in the 1990s.
The general idea of Lean is to reduce waste in the production process and only perform those activities that creates end customer value.
This makes sense for the development of user experiences too, not just cars, as end user value is what we all care about, right?
Reducing waste in UX projects
Waste is a tough ball game. One thing is to get rid of the waste that everyone agrees upon as waste of time and effort. But in Lean, we’re talking about getting rid of all the activities that do not directly feed into the end user experience or outcome of the project.
The product is the only thing the customer gets to see and use, and everything that does not directly lead to value in this end result is seen as wasteful.
Your end user never sees the flow charts, wireframes, or specifications. Do you need to make them?
This does not mean that wireframes aren’t useful, but you need the right reasons to spend valuable time. If it could be useful later, lets do it later. Because guess what, phase 2 may never happen.
Being Lean can also mean making the deliverables smaller and quicker. Your customer never gets to see your strategy document or project charter, so why not make it into a “one-pager”, instead of a long document? And while we’re at it, put it on a wall for everyone to see.
Reducing waste of time and effort in the deliverables can make it possible to get a desired product to customers’ hands faster – and possibly, cheaper. But Lean isn’t simply about spending less money, it is also about testing ideas and concepts sooner.
Minimum effort, maximum learning
Often in UX, a project is managed based on input (hours) and output (features or deliverables). In Lean UX, there shouldn’t be a detailed spec or feature list. Instead, we manage based on outcome and ability to solve a problem.
It may seem counter intuitive, but the more uncertainty there is when you get started, the less time you should spend on specifications.
With a lot of uncertainty, you can’t predict the future and what will happen in the project. Projects or businesses that are innovative and new, could benefit from a lean approach because Lean is a tool and a process made for testing out visions, ideas and concepts continuously through iterative cycles of Build, Measure and Learn. The process is iterative and based on agile and creative problem solving or design thinking.
Through making things, testing on real users in various experiments, measuring their feedback and learning what we need to change, we have a way to figure out if we are on the right track. This also means that user testing and research needs to be an integrated part throughout the duration of the project, not just at the beginning or the end.
In Lean, the first outcome to this process that can be tested on a real market is the MVP, or Minimum Viable Product. The MVP is the smallest thing you can make in order to get feedback from a real market (though it does not have to be the whole market).
Don’t build it if no-one wants it
The MVP has to strike a balance between perfecting a product and shipping it (before it is ready), and may be a real dream crusher. However, the MVP can help reduce risk, by allowing us to learn as early as possible what the critical success factors are.
Remember Zune? It was Microsoft’s attempt to take on the iPod. Great product design. Cool brand. Great user experience. Massive flop. The product did not excite the early adopters and the main stream market just did not get it.
Spending too much effort on design before validating with users will just make the failure more expensive. This is the reasoning behind the MVP: Fail fast, fail cheap – to suceed early.
Lessons learned from applying Lean UX
These are some of the lessons we have learned so far in applying a Lean approach to some of our projects:
#1 Keep teams small and cross-functional
In order to reduce waste and overhead, teams should be as small as possible. Keeping the team small also means that at least some of the team members should be hybrids, i.e. have a wide enough experience so that they may fill more than one pair of shoes.
#2 Dedicated team members
If the project is small, it may be tough to dedicate a team 100% for the duration of the project, but it is essential to keep the neccesary focus to get things done. A way around this is to shorten down project timeline – or dedicate a team to a business area or a client, rather than a single project, ensuring a dedicated team within the same domain.
#3 Allow self-organizing
A flexible mindset, open decision making where everyone has their say (no gurus!) and an ability to get things done is vital in order to adapt to the problem and environment at hand.
#4 Focus on the outcome, reduce wasteful output
Oral hand-overs and brief meetings. One-pagers instead of long documentation. The team should be allowed to figure out which deliverables are important to getting the right outcome.
#5 Continuous discovery
The earlier you can get feedback and pinpoint problems from actual users, the faster you can get a good product to market. User testing and research is not a deliverable in itself and everyone should get involved in the user testing and experiments, even developers and project managers.
#6 Shared location
Teams should share a physical work space, encouraging more and closer collaboration. Think of the “war room” in the miltary, these command centres are set up temporarily to be able to strategize and respond fast to changes in a crisis.
There is a ton of books and articles about Lean out there. Here are some of the references we have found useful:
- Lean UX – Applying Lean Principles to Improve User Experience by Jeff Gothelf
- Principles behind the Lean Start Up method
- “You’re not practicing lean UX if…” and Lean UX manifesto
- Take a look at the agile manifesto to understand the underlying principles for agile software development
- The Toyota Manufacturing System
- Undercurrent’s open letter to Yahoo! and Marissa Mayer outlining their idea of the Responsive OS
- Agile Software Development
- Lean UX, getting out of the deliverables business
- Don’t build a product unless you can validate it
Making Waves also has a blog in Norwegian – you find it here.