(As seen in Dr. Dobbs)
Lean User Experience (Lean UX) is a discipline that will likely become a game changer in web and mobile development of digital experiences (apps, websites, gadgets, etc.) as it introduces changes in the design process that better align with agile methodologies for development.
I am openly standing on the shoulders of people who put forth a lot of effort to bring Lean UX to light, despite all the criticism and pushback from traditional UX professionals and digital agencies that might see Lean UX as too much of a change, or even a threat to their status quo. The Lean UX professional naturally works together with other designers and developers, as opposed to the traditional waterfall model where the UX professional is the “hero” in charge of finding all the solutions and getting the client’s approval before development starts.
Many people think that Lean UX should only be applied to startups, possibly because Steve Blank’s Customer Development and Eric Ries’s Lean Startup methodologies resonate very well with the Lean UX approach to design. This exclusive connection is a misconception. Rather, wherever there is a team developing software from inception to delivery, there is an opportunity to make the whole process more efficient, or lean. For years the development community has been working towards this goal. Now, with Lean UX, the design community can do its part. The shared goal is to validate product decisions with real users as early as possible through workable software.
In this article I intend to shed some light to the Lean UX concept and how it can be integrated to Agile Development to form a true Agile end-to-end process.
* PREAMBLE: USER EXPERIENCE (UX)
There has been a lot of discussion about a more academic definition of UX as a design discipline and I have no intention to dive into it. The UX professional is the person responsible for creating interaction models that aim to improve the experience of a user.
I am going to use the term “Lean UX Designer” to refer to the person whose job it is to make sure that the roles of those involved in the design and development processes converge to amplify the UX of a particular system being designed in light of the business vision they represent. The Lean UX Designer (sometimes referred to as “Product Steward”) is, in fact, less of a jack of all trades and more of a maestro.
We live in a digital world where highly graphical interactive software has become ubiquitous. Well-built digital experiences are valued equally by all parties, including established companies, entrepreneurs and the usual suspects, digital agencies. Lean UX Designers are in the right place at the right time, because success of digital ventures critically depends on them. But they cannot do it alone, since there’s no maestro without an orchestra.
Successful software is no longer the one that is delivered on time, on budget and with quality. This is the minimum expected. Successful software adds value to its users and promotes a great user experience. Lean UX makes it possible to bring digital products to market very quickly after the idea is born – all while maximizing the odds of building successful software, and without compromising quality.
* DEFINITION OF LEAN UX
The word “lean” in Lean UX can be misleading and is often incorrectly associated with using a shallow approach that seeks to speed up software development at the expense of user centered design and design fine tuning.
“Lean,” as in “Lean UX,” was probably borrowed from Ries’ Lean Startup. Ries was inspired by the principles of the Toyota Production System. Toyota revolutionized manufacturing by introducing process changes that simultaneously increased value and reduced waste. Some elements of Toyota’s approach have recently been rediscovered in software development with the emergence of Lean IT or Lean Software Development, an evolution of agile methodologies.
Luxr originally coined the term Lean UX and defined it as “a cross-functional, principle-driven process characterized by rituals that predispose teams to high-quality, high-velocity user experience outcomes.” While “quality” is self-explanatory, “velocity” in agile methodologies is a measure of the productivity a team achieves in a given time-slot and should be maximized at all times.
In my opinion, a true Lean UX cannot be achieved without a Lean UX Designer orchestrating a solution finding process, comprised of design and development teams working together. Although you can still be lean while executing a “design phase,” the real opportunity to maximize value to the client while minimizing waste is when you promote a solution finding stream that culminates with a product that brings a great user experience and value to the user.
I define Lean UX as the process that makes it possible for two fundamentally different teams – designers and developers – to work as one team towards the same goal, maximizing the delivery of successful interactive experiences while minimizing waste. I don’t need to emphasize how difficult it is to have designers and developers working together. It is often comparable to mixing water and oil.
* IS LEAN UX ACCURATE?
So, is Lean UX an accurate definition? It can be. If you are following the Lean Principles when implementing your UX/design strategy integrated with a lean, agile development process, you are doing Lean UX. But even if you are not being so strict, just by leveraging a solution finding process that promotes a better conversation between design and development teams, you are certainly moving towards a leaner UX.
* WHAT IS THE PARADIGM SHIFT?
Lean UX is a disruptive approach to design disciplines. During the traditional software product development life cycle (known as the 4Ds: Discovery [or Define], Design, Development and Deploy), we will find a waterfall transition at least in one step. Specifically, some of the steps occur sequentially, with a hand-off from one team to another taking place at the end of the phase. It is also very hard to make the whole process iterate.
Lean UX comes to break up this paradigm: designers (which include Information Architects, Interaction designers, UI designers, UX designers, etc.) work side-by-side with developers as a solution finding team. This is the main aspect that differentiates the Lean UX approach from a traditional model, and it fundamentally changes everything.
In the traditional approach, all of the SPECS – site maps, wireframes, flow diagrams, content inventory, taxonomies, and mockups – are a final result of the “design phase.” In contrast, in the Lean UX approach, all of the SPECs are discussed and laid out throughout the process of designing and developing interactive solutions and the right emphasis is given to the deliverables necessary in each step of the process.
I was an eye witness to a big transition from RUP to agile methodology (SCRUM) inside Ci&T back in 2002, which ultimately was a transition from a heavy documentation-driven process to a very light people-driven and dynamic one. In the past nine years we have discovered that even the projects with complex business rules benefit from the agile approach. Over the past three years we have also started to promote the next much-needed transformation: an end-to-end process using Lean UX + Lean Agile.
The traditional process to develop a software project could be summarized as:
The first obvious aspect of it is that this is a typical waterfall model, even when a specific part has its own particularities. This is a reality in the vast majority of projects being carried out every day. To make things more tangible, let me describe a very common scenario of how this would happen in any organization building a new piece of software, no matter its size.
To simplify, let’s assume Discovery is a phase you completed already, since it is typically necessary before you realize you actually have a project. If you are an established business, you probably involved your business areas, product and marketing managers to carry out many ideation sessions that produced an awesome briefing document about the software to be built. The document represents the business vision, but is still missing the secret sauce: the materialization of the idea in visual forms and interactions flows, which make it easy for people to buy it.
This leads us to the Design phase where many, many steps take place. To name a few:
- Transform the briefing document into a formal requirements document
- Get approval from a bunch of people
- Transform the requirements documents into high-level site maps and wireframes
- Get approval from a bunch of people
- Produce a lot of wireframes to describe, in detail, everything the product will do
- Get approval from a bunch of people
- Go creative: each wireframe will become a beautiful designed digital masterpiece (a lot of work)
- Try to approve it. At this point many people that never discussed wireframes with you will join the approval board, because now it’s all about visuals. They will request a lot of changes
- Do a lot of design rework, reflect all the changes on the massive documentation you have completed so far
- Iterate until you get every single piece of design signed off (sigh)
- Finish up your pixel-perfect spec with a massive amount of details
- (sometimes) Do usability testing
At this point, after nearly one to six months of extensive work, you realize those pieces of design need to be brought to life through a development team, so you hand it off to the brightest engineers you can get to carry out the project. Their goal is to make it work and look exactly how it was designed.
Now you are at Development and you have at your disposal a great Agile development team, one of the best development methodologies available. You will probably go through the following steps, to name a few:
- Consume the SPECs
- Prepare the product backlog (collection of stories to be implemented)
- Validate and groom it while involving software architects for feasibility and software infrastructure analysis
- Do value engineering to prioritize stories in Sprints
- Interact daily with a product owner (PO) who is the client representation
- Develop the stories
- Do demo meetings (workable software) at the end of each sprint
- The PO invariably notes there are details that don’t look the way they were designed – uh oh.
- Do retrospective meetings to learn with project metrics and improve
- Necessary changes have to be made by that team that designed it. Rework. A very costly one.
- Move on to other sprints, but remember to get back to what needs rework
- After several sprints, deliver an awesome product that may, or may not, look exactly how it was designed originally, but works.
So, in a way, we could represent the traditional software development process as in the picture below:
Don’t forget, even with so many processes and wishful thinking, around 50 percent of all software developed fails during execution. A good percentage of the remaining 50 percent will still fail to reach business goals, or at least make their users happy.
Wouldn’t make sense then to shorten the path to find out if your idea has good potential to succeed? If you agree, Lean UX + Agile is one of the possible paths you can try. The Lean Startup process can also spice it up if you will, but this would be subject of another post. I will now describe our journey to dramatically change our end-to-end process to something that looks like the following:
The basic and fundamental change between what I presented before and this new flow isn’t obvious; it isn’t the fact that we moved from a linear approach to an iterative one. It’s not even the fact that instead of many months to get to workable software you can reduce the timeframe to weeks. The fundamental change that makes it possible to run this process is the fact that you have to get designers and developers to work together, in the same room and with the same mindset. They look at the stories in the product backlog as problems for which they need to find solutions, together.
It takes time and effort to change designers’ and developers’ mindsets and make them comfortable with working together, but the transition is possible. We started the change by promoting more interaction between the teams through the agile rituals, but they were still working independently in their silos. We recently took a bold step when we created a mobile studio by merging a creative team with a mobile software development team and put everybody to work together under the same roof and separated by projects, not functions.
To orchestrate the process, we created the role of the Lean User Experience Designer and assigned it to our previously creative directors. We call them now UX Experts and they are responsible for representing the business vision and user needs, providing creative direction and promoting solution-finding collaboration across the project stakeholders. They can be seen as co-product owners, similar to Tim McCoy’s definition of a Product Steward (see LeanUX, Product Stewardship, and Integrated Teams). I particularly like Tim’s statement that “Lean UX is not interaction design shoehorned into agile frameworks. Product vision, user research and modeling and truly evolutionary iteration are central to this approach. It stresses lightweight, collaborative, right-fidelity UX techniques to generate, test and evolve the design of your product.”
In any lean-inspired methodology, visualization is key and the use of kanbans is widespread in agile methodologies. Inspired by Forrester’s POST strategy and kanban, we created a tool to promote the product vision inside the teams: the product canvas. This extremely simple visualization tool makes it easy for us to get initial product vision from the client and materialize it for the entire team even before we start the project. As the project evolves, our UX Expert constantly updates the canvas and posts it as a big print board next to the agile story cards for everyone to interact with. I will write about the product canvas in a later post.
So let’s get back to our process. The iterative flow occurring into sprints could be summarized as follows:
- Do backlog grooming
- Select stories from the product backlog prioritizing them by business value
- Get the team to find solutions;
- Put designers to work side-by-side with developers on each story
- Draw low-fidelity wireframes;
- Validate them quickly with the PO;
- Build low-fidelity prototypes after necessary changes;
- Do usability testing (with 5-10 people from different backgrounds);
- Document results, validate findings with the PO and make necessary corrections;
- Design UI;
- Do coding;
- Do Testing (usability testing, A/B, functional, design, etc.);
- Demo the package to the PO;
- Necessary changes go to the next sprint’s backlog
- If product ready to meet its users:
- Deploy features
- Collect metrics
- Validate stories (Are they producing the expected result?).
A high-level overview of the entire process is:
A common question that arises from the diagram above is how you get enough information for developers to start working before design is done. This is really tricky. The secret is to have developers comfortable with implementing low-fidelity prototypes for which you do not really need to make a lot of design decisions. Use of rapid prototyping tools can accelerate the peer work between designer and developer and increase confidence among them. Moreover, while designers are laying out wireframes, supporting code can be built in parallel by developers.
I strongly discourage the use of the “one sprint ahead” approach where designers would always be working one sprint ahead to make sure developers will have the assets for their sprint. This is simply micro-waterfall (or the anecdotal “Agile-fall”) with lots of hand-offs between two teams working in constant conflict. Some projects do require a deeper discussion on site mapping, information architecture and user flows and user journey mapping but even when this is the case, you should start the project with everybody on board and have the technical team influence the design decisions and do parallel coding to prepare the basis for the first prototypes.
Whatever rework you face during the process will prove to be constructive, because convergence will occur quicker when you have everyone on the same page. Also, the cost of correcting something in your software after you ship it can be as high as one hundred times the cost that it would have been to do it when the feature was being tested for the first time. Talk about ROI!
I acknowledge that some projects, like highly experimental marketing campaigns and content heavy portals, will face challenges when following the Lean UX + Agile approach because they need more time in the Discovery and Design phases to have a comprehensive view of the whole product. But even in those cases, you will be able to see the benefits of bringing developers to discussions during very early stages of the project.
Outside of my work at Ci&T, but funded by the company through its entrepreneurship program, I applied this approach very successfully during the product development of a social running mobile application called runens. My co-founder and I built our first version of the product in record time and with a tight budget using a small team of two designers, one iOS developer and one cloud developer. The result was astounding. I’ve been asked many times what agency was involved to do the UI design. There was no agency involved, the product was a result of a Lean UX process.
It is safe to say that Lean UX makes the Lean Startup even leaner. By the way, in most startups designers and developers are seamlessly and effectively working together towards the same goals. Why should this be different inside established companies?
After reading this article, if your main takeaway is that you should tear down the walls and put your developers to work with designers, I have accomplished my goal. If you currently work with a digital agency and now believe that you pay too much for those pixel-perfect specs that ultimately are not what you need to maximize value to your users and your business, then I accomplished much more than I expected.
 Pressman, R.S. 2000. What a Tangled Web We Weave. IEEE Software, Jan.-Feb.:18-21
(a shorter version of this article has featured on both Dr. Dobbs and InformationWeek magazines: http://drdobbs.com/architecture-and-design/231902070)