Chapter 1. More Important Now than Ever Before
Design Is Always Evolving
When designers first brought their craft to software in the ’80s and ’90s, they approached the work in the same way they approached the earlier materials they worked with. In industrial design, print design, fashion design, or any field involving physical outputs, the manufacturing step is a critical constraint. When designing for physical materials, designers need to figure out what they’re making before they begin 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. They had to figure out the grammar of this new medium, and as they did, they saw new specialties like interaction design and information architecture emerge. But the process by which designers practiced remained mostly unquestioned. Designers still designed products in great detail in advance, because they still had to deal with a “manufacturing” process: the 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. Paradoxically, though, this way of working didn’t really prevent anyone from getting it wrong. Too often, designers worked in isolation—siloed—before passing their work to developers, who in turn worked in a silo before passing the work on to QA, and so on. And everyone was working with limited market feedback.
Today, we face a new reality. Software production has become continuous. The internet has changed the way we distribute software. The proliferation of mobile devices, wearables, and the Internet of Things has changed the way we consume it. We are no longer limited by a physical manufacturing process, and we are able to get our digital products and services into customers’ hands at a pace unheard of just a few years ago.
This changes everything.
Teams now are facing intense pressure from competitors who are using techniques like Agile software development, continuous integration, and continuous deployment to radically reduce their cycle times. Take Amazon as an example. The ecommerce giant pushes new code live to their customers every single second of every minute.1 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 to create a continuous conversation with customers. In essence, they are discovering their product at the same time they are delivering it. This has many results, but these are perhaps the two most important ones:
The ability to learn, continuously and quickly, how well their products are meeting customer needs
Raising customer expectations in terms of product quality and company response times to their concerns and feedback
What’s more, this new way of working is not based on expensive technologies. The platforms and services that make this possible are available for free or nearly free to just about every startup team. This exposes incumbent businesses to a threat they haven’t known before. Specifically, the barriers to entry—in almost every domain—have never been lower. Without the need to “manufacture” a physical product, anyone with access to the web can design, code, and deploy services to anyone else. Faced with these new threats, traditional “get it all figured out first” approaches are simply not workable. So what should product teams do?
It’s time for a change.
Lean UX is the evolution of product design and team collaboration. It takes the best parts of the designer’s toolkit, combines that with Agile software development and Lean Startup thinking, and makes all of this available to the entire product team. It allows teams to exploit this new reality to maximize learning, continuously discover the best path forward, and amplify the voice of the customer.
Lean UX is deeply collaborative and cross-functional because designers, product managers, and software engineers no longer have the luxury of working in isolation from each other. The days of the waterfall process are over. Work is continuous. We can’t afford to wait on the work of others, nor can we keep others waiting on our work. Instead, we need daily, continuous engagement with our colleagues if we are going to be successful. This continuous engagement allows us to strip away heavy deliverables (and the time required to create them) in favor of techniques that build shared understanding with our teammates. Shared understanding allows our teams to make decisions faster and empowers us to engage in more strategic conversations. Yes, we still have the responsibility of getting the details right: crafting beautiful interface elements and elegant workflows, and thinking about all the little things that make a product design work, from accessibility to page load times, and from button labels to error messages. But by eliminating communication overhead, we have more time to focus on more fundamental activities like gathering insight that can affect strategic choices for our product.
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—the outcomes that we are trying to create. In this new reality, we have more access to market feedback than ever before. This allows us to reframe design conversations in terms of objective business, customer, and user goals. We can measure what works, learn, and adjust.
Lean UX is three things. It begins as a process change for designers and product teams. But it’s much more than that. It’s a culture change that lets us approach our work with humility; we acknowledge that our initial solutions will probably be wrong and use many sources of insight to continuously improve our thinking. Finally, it implies a set of organizational changes to the way we organize and manage software design and development teams to be more inclusive, collaborative, and transparent. We’ll dig deeply into each of these aspects of Lean UX in the rest of the book.
1 Jon Jenkins, “Velocity 2011: Jon Jenkins, ‘Velocity Culture,’” O’Reilly, June 20, 2011, YouTube video, 15:13, https://oreil.ly/Yh7Co; Joe McKendrick, “How Amazon Handles a New Software Deployment Every Second,” ZDNet, March 24, 2105, https://oreil.ly/zXFoo; Werner Vogels, “The Story of Apollo - Amazon’s Deployment Engine,” All Things Distributed, November 12, 2014, https://oreil.ly/HrMRs.