When bringing our craft to software in the 1980s and 1990s, designers approached software in the same way we approached the earlier materials we worked with. In industrial design, print design, fashion design, and any field involving physical outputs, the manufacturing step is a critical constraint. When designing for physical materials, designers need to figure out what we’re making before we start production, because production is expensive. It’s expensive to set up a factory floor to produce hard goods or garments. It’s expensive to set up a printing press for a print run.
Working in software, designers faced new challenges. We had to figure out the grammar of this new medium, and as we did, we saw new specialties such as interaction design and information architecture emerge. But the process by which designers practiced remained largely unchanged. We still designed products in great detail in advance, because we still had to deal with a “manufacturing” process: our work had to be duplicated onto floppy disks and CDs, which were then distributed to market in exactly the same way that physical goods were distributed. The cost of getting it wrong remained high.
Today, we face a new reality. The Internet has changed the distribution of software in radical ways. Most software is now distributed online. We are no longer limited by a physical manufacturing process and are free to work in much shorter release cycles.
But “free” really undersells this new reality. Teams are now facing intense pressure from competitors who are using techniques such as agile software development, continuous integration, and continuous deployment to radically reduce their cycle times. Teams are pushing new code to production as fast as you can save a Photoshop file. And they are using these short cycles as a competitive advantage—releasing early and often, gaining market feedback, and iterating based on what they learn—and (perhaps inadvertently) raising customer expectations in terms of quality and response times.
In this new reality, traditional “get it all figured out first” approaches are not workable. So what should designers do?
It’s time for a change. Lean UX (UX = user experience) is the evolution of product design. It takes the best parts of the designer’s tool kit and recombines them in a way that makes them relevant to this new reality.
Lean UX is deeply collaborative and cross-functional, because we no longer have the luxury of working in isolation from the rest of the product team. We can’t continue to ask our teams to wait for us to figure it all out. We need daily, continuous engagement with our teams if we are going to be effective. This continuous engagement allows us to strip away heavy deliverables in favor of techniques that allow us to build shared understanding with our teammates.
Lean UX also lets us change the way we talk about design. Instead of talking about features and documents, we can talk about what works. In this new reality, we have more access to market feedback than ever before. This feedback allows us to reframe design conversations in terms of objective business goals. We can measure what works, learn, and adjust.
Lean UX is three things. It’s easiest to understand as a process change for designers. But it’s more than that. It’s a mindset that lets us approach our work in new ways. It’s also a way of thinking about managing software. I’ll dig into each one of these concepts throughout the book. In the next chapter we’ll take a look at the principles that lay the foundation for Lean UX design.