Lean UX has definitely been a fashionable word within the UX world in 2012 and 2013. But like anything that quickly becomes a buzzword, it can often become misunderstood and translated into something completely different. I am not claiming to be an expert of Lean UX, but have seen environments where these tools have thrived but have also seen them fail.
Last year, I had the good fortune to witness Jeff Gothelf open the second day of UX Cambridge with his Lean UX talk, largely based on his successful and equally excellent book, Lean UX. Prior to this, I had read the best-selling Lean Startup book by Eric Ries, three times to be exact. Where The Lean Startup spoke to business, Lean UX really asked pertinent questions about the design process and how well we embed ourselves into the larger picture. But long before this, I had been a massive fan of economics and manufacturing from my university studies.
FROM TOYOTA TO SPRINT BOARD
Lean itself is not a new idea, but one that has found a new flavour in a new era. Originally, Lean was a set of tools within the manufacturing process that was designed as a response to the then dominant Ford, with its mass production techniques. Mass production being characterised by working towards huge batch sizes, based on perceived future market demand; as a guide to how much to produce upfront. Toyota had to respond in a method that reduced waste, and intensified learning as they went along. This improved productivity within a far more modest foundation to work with. The Lean toolset concentrated on delivering exactly what was needed, when it was needed and where needed at the exact time of demand – otherwise known as ‘Just-In-Time’. In the instance of a market pull for a product, this would then trigger a chain of events that would deliver the exact quantity back to the market, to meet the exact demand.
If we fast-forward and apply this to modern web design and development methods, we start to see similarities with a classic Waterfall process. We have become accustom to working in large batch sizes with our endless number of deliverables, from functional specifications to detailed upfront guidelines, even before a line of code has been written. This is regularly performed out of habit for the perceived future usefulness throughout the entire development process. This behaviour can often be characterised as being high in effort and high in waste, if things, as they always do, change.
Lean UX (like Lean manufacturing before it) refocuses the need for deliverables, with the objective of providing exactly what is needed, when it is needed and where it is needed. By researching, prototyping and validating elements as they are needed, it allows the process to become more nimble and focused; thus working in smaller batch sizes on demand to gain the relevant learning. By working in a more nimble manner, it becomes easier to iterate a design or even pivot product direction than it had been with the burden of larger deliverable batch sizes.
I think we can all relate to a time where we have slaved over a polished design or interaction, making it pixel perfect only to see the whole concept fail miserably on a user test or even when a developer has given their feasibility advice. Because we have that emotional attachment based on time spent perfecting this, we find it difficult to let go and find ways to defend its existence. Lean UX allows us to break requirements into smaller assumptions that can be tested little and often, with the fidelity to match. With constant feedback loops from the wider team and users, we are learning more with each small step forward. This making each pixel pushed even more valuable and viable.
WINNING THE LEAN UX GAME
This all sounds like UX heaven to most of us, but there are many challenges and complications trying to get this to become a reality. For a start, the term itself has many interpretations. Some even see it as a way of stripping out perceived project hold-ups; this includes the process of UX itself and jump straight into visual design and code. More worryingly, it can also be interpreted as the removal of any user insights or feedback loops. Without the user insights feeding back into the process at all, we have lost sight of the original benefit of producing what is needed, when it is needed and where.
There also challenges within the wider team when embedding any new process: it needs everyone’s buy-in if it is to work like a well-oiled machine. A characteristic of being more reactive to feedback loops and validation is that teams have to work closer together with far greater transparency than they are used to in a more traditional workflow. This is especially apparent with designers, product teams and developers collaborating closer to tackle problems together. But what if some of the team believe there is nothing wrong with the status quo and things were just perfect how they were before? All of a sudden you see a single discipline (often the UXer) trying to push the whole new process themselves, which quite often leads to them burning out of enthusiasm and optimism in these new working methods.
The stimulus used to test and the interpretation of the results can also be a challenging area. If a validation test has not produced the desired results of a key project stakeholder, the situation could quickly become a question of the quality or fidelity of the prototype used and the defending of their interpretation of what was learnt. It is hugely important to agree on the quality of the ‘minimum viable’ prototype upfront and agree what success and failure of the test would look like. This, as we all know, can be far trickier in practice than in theory.
Quite often, some see large amounts of detailed deliverables as their value to the team and organisation. By asking a fellow UXer on the team to produce less upfront work could be seen as a means to devalue their input. But this is a problem that is not isolated to fellow UXers on the project, but rather it could be a company-wide issue. If productivity of these deliverables is part of what is perceived as their expertise, by adopting Lean UX methodology we are all of a sudden losing the tangible elements that crystalize our expertise and knowledge.
Because multidisciplinary teams are working much faster and closer together, remote team locations provides quite possibly the biggest obstacle to embedding Lean UX. Even if the whole team believe this is a better way of working, it is largely impossible to be embedded in one another’s process, if there are physical barriers. Yes, we have communication tools (like Skype, FaceTime and Hangout) and the ability to make the occasional visit to these remote locations, but on a day-to-day basis it is difficult for this to become sustainable or practical. In an era where remote development teams in exotic countries are becoming more popular, we are finding it increasingly difficult to embed a smooth UX process into a development process, let alone one that is dependent on frequent collaboration and shared knowledge.
LOSING SOME WEIGHT TO BECOME LEANER
I really do not want to discourage anyone who is in the process of embedding a Lean UX process to their workplace. Far from it. I am massive fan of the book and the range of tools it promotes as an efficient working environment. This post intends to highlight some of the issues I have seen and hope that someone may find great solutions to them and share them back with the UX community. Collaboration and a shared understanding is fundamental to productive and successful UX environments, but to do this effectively, the landscape has to be fertile. It has to be something that is pushed for from the wider team, and better still from those above.
Many of the tools that are described in Lean UX, could also be referred to as good practice and things we should be aspiring to achieve anyway. Much of what the term has done, is embody some of these good practices into something that can be quickly labelled and referred to. The real danger comes if the whole embodied Lean UX toolkit becomes seen as too challenging and ‘not for us’. We shouldn’t throw out all the tools it promotes as a knee jerk reaction. We should instead keep the ones that do make improvements on our own processes and actual outcomes, build on them and find new ways to work smarter and leaner.