Waterfall design process is a traditional approach to launching digital products that does not require much introduction. The entire cycle is divided into separate sequential phases, starting with business and user requirements gathering, moving through user research and ending up with designing, testing and development.
The corporate world is deeply attached to the waterfall system, because it mirrors the linearity of their internal processes. At first, a manager approves a strict budget for the new product, then the design team will create the experience, later the developers will take over and release a perfectly usable product. Everyone is happy and success is achieved. Or at least that is the ideal vision from management.
The only caveat is that every new project is built on top of a pile of uncertainties.
The more you delay real contact with customers, the bigger the pile becomes. To reduce the risk of an avalanche, great product teams eliminate risks through iterations of research and testing. However, only on rare occasions it is possible to estimate how many iterations are needed to reach optimal results. The lack of proper estimation comes into conflict with budgets and deadlines set at the early stages, making management unhappy. Consequently, tensions get high, the release takes longer and you run out of budget.
Designers love a problem to solve and the waterfall process is no different. Multiple companies have borrowed concepts from agile development, beloved by engineers, and have created agile design frameworks that have been blossoming in the Design community. Google came up with Design Sprints, IDEO improved Design Thinking, Startups embraced the Lean Startup.
We call our approach simply Lean UX.
Lean UX by LB*
At LB*, we break agile product design into small, self-contained chunks of work with the help of story maps, a simplification of user journeys with the focus on different features and use cases for each step of the journey.
In the example above, from our case study about designing More app by HB Reavis, the chunks are smaller features the user needs to interact with during their journey for attending an event: seeing upcoming events, subscribing, paying ticket, etc. Another example from our project of redesigning an online bookstore Martinus, these may represent individual subpages ordered according to the journey of buying a book: homepage, catalogue, product page, shopping cart and so on.
During two-week long sprints, a team of designers, engineers and business stakeholders work on a set of these chunks. Each cycle looks like this:
In the first week, we hold a workshop to fine-tune the problem, we brainstorm solutions and design a prototype. Some solutions are obvious and present low risk, therefore not requiring much validation (e.g. login). Other solutions are riskier and should be validated (e.g. are customers able to unlock an e-scooter with their phone camera?). For each risky assumption, we create hypotheses to be validated.
In the second week, we validate hypotheses through clickable prototypes, interviews, smoke testing or any suitable method. The results inform our design iterations. At the end of the second week, we may have iterated the design dozens of times. Our research, testing and validation happens in guerilla mode 一 we insert ourselves where members of our audience could be and approach them in person (e.g. a bookstore for Martinus, a hospital for Dôvera or a retail store for Orange). Alternatively, we may rely on online tools. There is also room for traditional user testing methods in the project, but speed and flexibility are the most important features in sprints.
Quantity brings multiple benefits
In the Lean methodology, we prefer quantity over quality. A higher amount of quick tests gives us better results than a lower amount of highly precise tests. It also allows us to be more flexible and make small changes in-between sessions and see the results right away. The number of small iterations boosts the output quality and lowers the risk of delays.
Lean UX shows its true power when we combine lean design and agile development. Both can run in almost parallel flows that feed into each other. Low risk small features can be coded from the get-go and as soon as riskier features are designed and validated, it can be included in the development backlog for the following cycle.
If you create a solid story map, based on real user journeys, plan the work in small chunks and work together as an agile lean team, just within a few weeks you can deliver a product that would otherwise take months or years to be released in the waterfall process. The product may be smaller in scope at first, but it will have lower risk, it will hit the market first and you will get to improve continuously while already having customers and real feedback.
Is Lean suitable for you?
We hope that by now you can grasp the benefits of the Lean methodology, but before you try something similar in your company, you should ask yourself a few questions:
1. How deeply are you and your colleagues willing to cooperate on a project?
Lean UX is a deeply collaborative activity, which requires participation of a multidisciplinary team. Designers, analysts, developers and also management have to be able to meet regularly, communicate and co-create.
2. Are you willing to give up documentation?
In the Lean methodology, direct communication takes precedence over documentation. That’s why an entire team of designers and developers sits together in our office, so they can communicate directly any time someone discovers a problem or has suggestions for improvement. Communicating through outputs and documentation is not only inefficient, but usually the biggest source of misunderstandings.
3. Are you willing to accept flexible specifications?
Lean means avoiding excessive planning and instead resetting the direction of the project continuously. Design is one big learning process, which impacts the users, the product, technologies and even the business itself.
4. Do you spend time to further improve products after its release?
A release does not end the design process, but quite the opposite. The sooner the product is out, the sooner you can gather real customer feedback and make educated improvements. Design does not last a month, or a year, but the entire product lifecycle.
Corporations are changing
Companies that can deliver products fast are able to better react to market changes. Slowly, corporations are starting to realise that long development cycles are synonymous to reduced growth and potential loss of market share to faster and more innovative companies.
Changing an entire company to working agile overnight is impossible. If you are interested in embracing a risk-free product development culture, you have a long road ahead of you, but we can help you take baby steps along the way.
Many companies like Dôvera and Orange have embarked on this journey with us and are already delivering customer-centric products faster, such as a web app helping to subdue diabetes and a new online offer of TV packages.
Are you ready to go down this path with us and start creating better products and services faster? We can set up a cooperation on a small pilot project. Let's talk.
