Jeff Gothelf’s Lean UX (2013) advocates bringing “lean” product strategies into the design process. The broad outline of this book will come as no surprise to people who have read Eric Ries’s The Lean Startup (2011) and earlier books like Cooper’s Winning at New Products (1986): It’s all about staunching the flow of time and money in the service of creating something minimal that is honed to provide opportunities for learning; then you test, learn, and iteratively eliminate what fails and improve what succeeds. If you’re intrigued by what I’m about to tell you, I’d advise you to snag a copy of the book, and read the first section, on principles; then read Chapter 4 on collaborative design. If you like that, then read Chapters 7 and 8 regarding implementation. If you think you’re up for the kind of change Gothelf envisions, read the rest of the book and go for it.
There are a couple of ways UX and front-end designers sometimes interact with agile teams. One way is that they will conduct quite a bit of design discovery, mocking, and implementation before software development begins: Sometimes this is called “Big Design Up Front” (BDUF) (pp. 114-115). I don’t think many designers who work with agile teams do this very much anymore, though they will sometimes say that they really need BDUF in order to figure everything out and get clarity with stakeholders. Another strategy is a “staggered sprint” for design; in this technique, design kicks off a “Sprint Zero” prior to the initial software sprint in an attempt to define what is to be built; afterward, there is a design sprint going on simultaneously with each software sprint, where the design sprint tries to lead or get ahead of the train (see pp. 97-98). In these models, design authority rests with the designers, and designs are typically validated with stakeholders and then “handed off” to software.
Why has it worked this way? Design seems to be special: Design can be hard, detailed, elaborate, and sweated over. Many designers are perfectionists. Designers are judged by their artifacts, and they don’t like to look bad; their ego is on the line. There is constant concern that if the design isn’t vetted with stakeholders before development, the implementation might be judged inadequate later; and thus a lot of money and time would be wasted. Meanwhile, many software developers think they have little aptitude for design, and welcome the handoff of finished or semi-finished designs they can implement. Finally, a lot of our software tools for merging visual design and behavior are weak; changes in the user experience or design can be costly simply because our tools are optimized for the “hand off,” not for flow and layout changes.
Lean UX takes a critical view of these habits. The very phrase “Lean UX” strikes fear and arouses anger in the hearts of many great user experience designers, product managers, and front-end designers, and the author knows it from personal experience. Gothelf has partaken of at least two moments of clarity. In one BDUF exercise, his team charged a customer $600,000 for a fresh product refashioning; on delivery, the client clapped! But the new design was shelved and never got implemented (pp. xiv-xv). Now that’s a waste of time, effort, and money! Then back “in the early 200s,” Gothelf tells us,
I was a user interface designer at AOL, working on a new browser. The team was working on coming up with ways to innovate upon existing browser feature sets. But they always had to wait to implement anything until I’d created the appropriate mockups, specifications, and flow diagrams that described these new ideas.
One developer got tired of waiting for me and started implementing some of these ideas before the documents were complete. Boy, was I upset! How could he have gone ahead without me? How could he possibly know what to build? What if it was wrong or didn’t work? He’d have to rewrite all the code!
Turned out that the work he did allowed us to see some of these ideas much sooner than before. It gave us a glimpse into the actual product experience and allowed us to quickly iterate our designs to be more usable and feasible. From that moment on, we relaxed our BDUF [“big design up front”] requirements, especially as we pushed into features that required animations and new UI patterns. (p. 115)
In this little story, design collaboration brings insight earlier in the game. What’s not to like?
Bringing this idea to the design/engineering process is a scary proposition for many, even for those of us in startups who in almost every other way strive to favor “working software over comprehensive documentation” and “individuals and interactions over process and tools” (so sayeth the Agile Manifesto).
If I had to boil the book down to one idea, it is that the “handoff” of design is wasteful. The “deliverable” is not the product; in place of the “deliverable,” Gothelf says we should shift our attention to creating testable “outcomes” (pp. 8, 17), i.e., business value that solves a problem. Here’s what Gothelf says about design:
The most effective way I’ve found to rally a team around a design direction is through collaboration. Over the long haul, collaboration yields better results than hero-based design (the practice of calling in a designer or design team to drop in, come up with something beautiful, and take off to rescue the next project). Teams rarely learn or get better from working with heroes. Instead, designing together increases the design IQ of the entire team. It allows every member of the team to articulate his or her ideas. It gives designers a much broader set of ideas to draw upon as they refine the user experience. This collaboration, in turn, breeds increased feelings of ownership over the work being done by the entire team. Finally, collaborative design builds team-wide shared understanding. It is this shared understanding that is the currency of Lean UX. The more the team collectively understands, the less it has to document in order to move forward. (p. 34)
And regarding experience research:
Lean UX research is collaborative; you don’t rely on the work of specialized researchers to deliver learning to your team. Instead, research activities and and responsibilities are distributed and shared across the entire team. (p. 74)
And why? This is where we get to the core benefit of team collaboration:
By eliminating the handoff between researchers and and team members, we increase the quality of our learning. (p. 74; emphasis added)
Here we have it: More data; higher quality of learning.
Lean UX is supported by principles. Among the most important: it requires cross-functional teams that are small, dedicated, and (if possible) co-located; progress is measured not by deliverables but by outcomes that can be tested; teams are focused on a problem; teams produce with a “small batch size” (“keep inventory small and quality high”). I’m particularly interested in the composition of the small team. When it comes to implementation, the team Gothelf imagines seems to be composed typically of a stakeholder, a UX designer, a front-end designer, a software developer, and a support / training / services person. He’s polite enough not to make these recommendations very concrete, but he cites examples that do exactly this. He supports Jeff Bezos’s notion of a “two-pizza team” so that the team can maintain discipline and be organized by the same goals (p. 113).
There are two rather cunning shifts / redefinitions that this book makes; how consciously, I’m not sure.
The Nature of the MVP
The first is that the definition of the “minimum viable product” (MVP) is radically changed. One version is the smallest bit of functionality that can deliver real value to a customer or market — this is the definition I’ve always known. The other idea of MVP, which is the one promoted by the book, is that the MVP is designed to make it possible to learn something (see p. 56). This is different. The MVP is not, in the view of these authors, about delivering an artifact per se; it about validating a hypothesis. This affects a lot. It means that the MVP is about learning — as much as you can, as fast as you can. It means that the MVP is going to be revised or thrown out. Once settled with this idea of the MVP, a lot is affected. For example, if affects the choice of prototyping tools. Gothelf goes through a number of tools, from paper to actual code, but he lists “cons” for each level. The negatives are all about being slow: For paper, “Rapid iteration and duplication of the prototype can become time-consuming and tedious” (p. 60); for medium-fidelity (Axure) they note that “it can be time-consuming to create and maintain” (p. 64); for “coded prototypes”: “time-consuming to create” (p. 65). They bury the lede here a bit: Use Balsamiq or similar tools for prototypes and mockups. For prototypes, “you can always go leaner” (p. 68). That could be the motto for the book.
The Role of the Designer
The other redefinition is about the role of the designer. While on the one hand Gothelf dismantles the “heroic” designer, at the same time, he makes the designer the implicit leader and facilitator of the team. Design becomes the encompassing idea of the product (see esp. p. 112). This shifts some power from the product manager (who perhaps becomes more collaborative) to the person who has the most experience with design. Now in my experience, all of the best product managers have been designers or have deep design intuition (even when they might deny it). So what I think is going on here is a reorganization of the weights of different roles.
Gaps
In a discussion with my own engineering and product teams, we identified some gaps in the book. Here they are:
- If you look at the small team composition on p. 122, one version of Lean UX imagines a UX Researcher, UX Designer, PM, engineering, and QA. Fair enough. But where is the stakeholder who sits in with the team? This is a crucial piece of agile dogma, and I think that if eliminating handoffs is important, you also have to internalize the role of the stakeholder/customer into your cross-functional team.
- What about coordination between teams? The book sees teams as pretty self-contained. But for non-green-field development there are severe dependencies between teams (e.g., behind-the-firewall apps; devops; customer-facing apps): Don’t the deliverables and handoffs just come back in when you’re face with a really big project?
- The book seems to under-estimate the amount of time it takes to conduct user testing. The tone of the book says: “test with users all the time.” Great idea. But if the whole team is collaborating on that, are you going to have enough time to build? One answer (which is in the book) is: Rely on metrics. But there will always be user experience tests that require eyeballing actual human behavior.
Should You Do It?
Of course I don’t know. If your current process is so invested in handoffs that you can’t even try it, then I’m sad. But it strikes me that the cost of at leasting this for 3 or 4 iterations is very low, and is entirely in the spirit of agile, which seems to improve process continually.
{ 0 comments }
