Lean UX

by Jeff Gothelf

  Turns out the work he did allowed the team to see some of these ideas much sooner than before. It gave team members a glimpse into the actual product experience and allowed them to quickly iterate their designs to be more usable and feasible. From that moment on they relaxed the BDUF requirements, especially as the team pushed into features that required animations and new UI patterns.

  The irony of the team’s document-dependency and the “inspiration” it triggered in that one developer was not lost. In fact, at the end of the project, Jeff was given a mock award (Figure 8-1) for inspiring “undocumented creativity” in a teammate.

  Figure 8-1. Jeff’s “award” for inspiring undocumented creativity in engineers

  Even though most teams these days actively shun the concept of Big Design Up Front, we’ve seen a resurgence in this practice in supposedly Agile environments. This new, sneaky version of BDUF is called Agile-fall. Agile-fall is the combination of an up-front design phase that results in work that is handed off, waterfall style, to an engineering team to then break up into stories and develop in an “agile” way. The argument for this way of working centers on the engineering team’s desire to stay the course during implementation and to be able to predict when the work will ship with some degree of confidence. This is done in the name of predictability and efficiency.

  The problem, of course, is that Agile-fall removes the collaboration between design and engineering that Lean UX requires to succeed. It ends up forcing teams to create big documentation to communicate design, followed by even lengthier negotiations between designers and developers. Sound familiar? It’s BDUF in a new disguise. The waste created with Agile-fall is a symptom of a broader management issue that continues to push teams toward fixed scope and fixed deadlines. Engineers rightly feel the only way they can make scope and deadline commitments is if they have a crystal clear understanding of what needs to be developed, along with a promise that nothing will change. (Never mind that agile is about embracing change!) Of course, as we know by now, software is complex and unpredictable and, even with a locked-down design, the ability to predict exactly what will ship and when it will ship is closer to fortune-telling than it is to project management.

  If Agile-fall is the way your team works, consider amplifying the conversation about managing to outcomes with your stakeholders. By moving the conversation away from fixed time and scope, and steering toward customer behavior as a measure of success, the demands to do all the design work up front should begin to disappear.

  SHIFT: Speed first, aesthetics second

  Jason Fried, CEO of Basecamp once said, “Speed first, aesthetics second.”

  He wasn’t talking about compromising quality. He was talking about editing his ideas and process down to the core. In Lean UX, working quickly means generating many artifacts. Don’t waste time debating which type of artifact to create, and don’t waste time polishing them to perfection. Instead ask yourself the following:

  Who do I need to communicate with?

  What do I need to get across to them immediately?

  What’s the least amount of work I need to do to communicate that to them?

  If you’re working with a developer who is sitting next to you, a whiteboard sketch might suffice. If an executive is asking detailed product questions, you might need to create a visual mockup. Customers might require prototypes. Whatever the scenario, create the artifact that will take the least amount of time. Remember, these artifacts are a transient part of the project—like a conversation. Get it done. Get it out there. Discuss. Move on.

  Aesthetics—in the visual design sense—are an essential part of a finished product and experience. The fit and finish of these elements make a critical contribution to brand, emotional experience, and professionalism. At the visual design refinement stage of the process, putting the effort to obsess over this layer of presentation makes a lot of sense. However, putting in this level of polish and effort into the early-stage artifacts—wireframes, site maps, workflow diagrams—is (usually) a waste of time.

  By sacrificing the perfection of intermediate design artifacts, your team will get to market faster, and learn more quickly which elements of the whole experience (design, workflow, copy, content, performance, value propositions, etc.) are working for the users and which aren’t. And, you’ll be more willing to change and rework your ideas if you’ve put less effort into presenting them.

  SHIFT: Fall in love with the problem, not the solution

  Lean UX makes us ask hard questions about the nature of quality in our design work.

  If you’re a designer reading this, you’ve probably asked yourself a question that often comes up when speed trumps aesthetic perfection:

  If my job is now to put out concepts and ideas instead of finished work, everything I produce will feel half-assed. I feel like I’m “going for the bronze.” Nothing I produce will ever be finished. Nothing is indicative of the kind of products I am capable of designing. How can I feel pride and ownership for designs that are simply not done?

  For some designers, Lean UX threatens what they value in their work and puts their portfolio at risk. It might even feel as though it threatens their future employability. These emotions are based on what many hiring managers have valued to date—sexy deliverables (i.e., solutions). Rough sketches, “version one” of a project, and other low-fidelity artifacts are not the making of a “killer portfolio.” With the realization that software solutions continue to evolve over time, all of that is now changing.

  Although your organization must continue to value aesthetics, polish, and attention to detail, other dimensions of design are equally important. The ability to understand the context of a business problem, think fast, and build shared understanding needs to get a promotion. Designers can demonstrate their problem-solving skills by illustrating the paths they took to get from idea to validated learning to experience. In doing so, they’ll demonstrate their deep worth as designers. Organizations that seek out and reward problem-solvers will attract—and be attracted to—these designers.

  Shift: UX debt

  It’s often the case that teams working in Agile processes do not actually go back to improve the user interface of the software. But as our friend Jeff Patton likes to say, “It’s not iteration if you do it only once.” Teams need to make a commitment to continuous improvement, and that means not simply refactoring code and addressing technical debt, it also means reworking and improving user interfaces. Teams need to embrace the concept of UX debt and make a commitment to continuous improvement of the user experience.

  James O’Brien, an interaction designer working in London, describes what happened when his team began tracking UX debt in the same manner that the team used to track technical debt. “The effect was dramatic. Once we presented [rework] as debt all opposition fell away. Not only was there no question of the debt not being paid down, but it was consistently prioritized.”

  To begin tracking UX debt, you can just create a category of stories in your backlog called UX debt. Sometimes, though, experience problems are not something that a single team can solve—solving bigger problems can require the coordinated effort of many teams. For these larger efforts—experience problems that span large user journeys—try this:

  Create a customer journey map of the current experience

  Work together with your team to create a second journey map that shows the ideal experience

  Make these two artifacts clearly visible (on a wall) next to each other

  Identify teams responsible for portions of that customer journey and invite them to the wall to review the gap between current and desired states

  Work with these teams to write UX debt stories to go on their backlogs

  Clearly identify on the journey maps when the current experience has been improved and who is working on other improvements

  SHIFT: Agencies are in the deliverables business

  Applying Lean UX in an interactive agency is
no small challenge. Most agencies have a business model that conflicts with Lean UX. The traditional agency business model is simple: clients pay for deliverables—designs, specs, code, PowerPoint decks—not outcomes. But agency culture is also a huge obstacle. The culture of hero design is strong in places that elevate individuals to positions like executive creative director. Cross-disciplinary collaboration can also be difficult in big agencies, where the need to keep utilization high has led to processes that encourage functional silos. These, in turn, lead to “project phases” that encourage deliverable-centric work.

  Perhaps the most challenging obstacle is the client’s expectation to “throw it over the wall” to the agency, and then see the results when they’re ready. Collaboration between client and agency in this case can be limited to uninformed and unproductive critique that is based on personal bias, politics, and ass-covering.

  To make Lean UX work in an agency, everyone involved in an engagement must focus on maximizing two factors: increasing collaboration between client and agency, and working to change the focus from outputs to outcomes.

  Some agencies are attempting to focus on outcomes by experimenting with a move away from fixed-scope and deliverable-based contracts. Instead, their engagements are based on simple time-and-materials agreements or, more radically, toward outcome-based contracts. In either case, the team becomes freer to spend its time iterating toward a specified goal. Clients give up the illusion of control that a deliverables-based contract offers but gain a freedom to pursue meaningful and high-quality solutions that are defined in terms of outcomes, not feature lists.

  To increase collaboration, agencies can try to break down the walls that separate them from their clients. Clients can be pulled into the process earlier and more frequently. Check-ins can be constructed around less formal milestones. And collaborative work sessions can be arranged so that both agency and client benefit from the additional insight, feedback, and collaboration with each other.

  These are not easy transformations—neither for the agency nor the client who hires them—but it is the model under which the best products are built.

  A quick note about development partners

  In agency relationships, software development teams (either at the agency, at the client, or a third-party team) are often treated as outsiders and often brought in at the end of a design phase. It’s imperative that you change this: development partners must participate through the life of the project—not simply by including them as passive observers. Instead, you should seek to have software development begin as early as possible. Again, you are looking to create a deep and meaningful collaboration with the entire project team—and to do that, you must actually be working side by side with the developers.

  In Chapter 9 we highlight two agencies, ustwo and Hello Group, that have found different paths for addressing these challenges.

  SHIFT: Working with third-party vendors

  Third-party software development vendors pose a big challenge to Lean UX methods. If a portion of your work is outsourced to a third-party vendor—regardless of the location of the vendor—the Lean UX process is more likely to break down. This is because the contractual relationship with these vendors can make the flexibility that Lean UX requires difficult to achieve.

  When working with third-party vendors, try to create projects based on time and materials. This will make it possible for you to create a flexible relationship with your development partner. You will need this in order to respond to the changes that are part of the Lean UX process. Remember, you are building software to learn, and that learning will cause your plans to change. Plan for that change and structure your vendor relationships around it.

  When selecting partners, remember that many outsourced development shops are oriented toward production work and see rework as a problem rather than a learning opportunity. When seeking partners for Lean UX work, look for teams willing to embrace experimentation and iteration, and who clearly understand the difference between prototyping-to-learn and developing-for-production.

  SHIFT: Documentation standards

  Depending on the domain you work in, your organization might impose strict documentation standards that meet both internal and regulatory compliance. These documents might not add any value for the project while it’s in flight, yet the team still has to create them. Many teams struggle to move their projects forward when faced with these regulations. They wait until the documents are complete before beginning the design and implementation of the work slowing, down progress and team learning. Then, when the documents are complete, any adjustment of the work described within them is discouraged because of the documentation overhead that change drives.

  This situation is exactly where, as designer and coach Lane Halley put it, you “lead with conversation, and trail with documentation.” The basic philosophies and concepts of Lean UX can be executed within these environments—conversation, collaborative problem solving, sketching, experimentation, and so on—during the early parts of the project lifecycle. As hypotheses are proven and design directions solidify, transition from informal documentation practices back to the documentation standard your company requires. Use this documentation for the exact reason your company demands—to capture decision history and inform future teams working on this product. Don’t let it hold you up from making the right product decisions.

  SHIFT: Be realistic about your environment

  Change is scary. The Lean UX approach brings with it a lot of change. This can be especially disconcerting for managers who have been in their position for a while and are comfortable in their current role. Some managers can be threatened by proposals to work in a new way—which could end up having negative consequences for you. In these situations, try asking for forgiveness rather than permission. Try out some ideas and prove their value with quantifiable success. Whether you saved time and money on the project or put out a more successful update than ever before—these achievements can help make your case. If your manager still doesn’t see the value in working this way and you believe your organization is progressing down a path of continued “blind design,” perhaps it’s time to consider alternative employment.

  SHIFT: Managing up and out

  Lean UX gives teams a lot of freedom to pursue effective solutions. It does this by stepping away from a feature roadmap approach, and instead empowers teams to discover the features they think will best serve the business. But abandoning the feature roadmap has a cost—it removes a key tool that the business uses to coordinate the activity of teams. So, with the freedom to pursue your agenda comes a responsibility to communicate that agenda.

  You must constantly reach out to members of your organization who are not currently involved in your work to make them aware of what’s coming down the pike. This communication will also make you aware of what others are planning and help you to coordinate. Customer service managers, marketers, parallel business units, and sales teams all benefit from knowing what the product organization is up to. By reaching out to them proactively, you allow them to do their jobs better. In turn, they will be far less resistant to the change your product designs are making.

  Here are two valuable lessons to ensure smoother validation cycles:

  There are always other departments who are affected by your work. Ignore them at your peril.

  Ensure customers are aware of any significant upcoming changes and provide them the option to opt out (at least temporarily).

  Wrapping Up

  In this chapter, we described some of the organizational shifts you’ll probably be faced with as you implement Lean UX. In the next chapter, we look at some case studies of companies that are putting these ideas in motion, experiencing the shifts, and developing Lean UX ideas in the wild.

  1 Robert C. Daley, “The Role of Team and Task Characteristics in R&D Team Collaborative Problem Solving and Productivity”, Management Science, November 1, 1978

  Chapter 9. Case Studies

  If y
ou’re not failing every now and again, it’s a sign you’re not doing anything very innovative.

  —Woody Allen

  In the previous chapter, you looked at some of the shifts that organizations must make in order to begin working in a Lean UX style. In this chapter, we share with you some case studies that illustrate how companies across industries are making these shifts. As you read, you’ll see themes from Chapter 8 coming up. You’ll also see organizations making compromises, balancing old and new imperatives, and working to continuously adapt their processes, all the while using Lean UX principles and methods as their guides.

  Regulations and Financial Services: Lean UX at PayPal

  Industry regulation presents a challenge for Lean UX. Lean UX teams like to move quickly, to experiment with both process and product, to try new things, and learn from failure. In regulated industries, however, failure isn’t regarded casually. Regulation usually exists to prevent failures and/or limit the damage that failure can cause. Still, Lean approaches can work in regulated environments—it’s all about figuring out how to experiment safely. This case study shows how one team at PayPal began their Lean UX journey.