Lean UX

by Jeff Gothelf

  After those stories are in the backlog, you need to put them in priority order. This forces conversations around when to run the experiment and, equally as important, what we won’t be working on during that same time.

  Experiment stories look just like user stories, as illustrated in Figure 7-6.

  Figure 7-6. Experiment stories

  Experiment stories contain the following elements:

  The hypothesis you’re testing or the thing you’re trying to learn

  Tactic(s) for learning (e.g., customer interviews, A/B tests, and prototypes)

  Who will do the work

  A level of effort estimate (if you do estimations) for how much work you expect this to be

  After they are written, experiment stories go into your backlog. When their time comes up in the sprint, that’s the assigned person’s main focus. When the experiment is over, bring the findings to the team immediately and discuss them to determine the impact of these findings. Your team should be ready to change course, even within the current sprint, if the outcome of the experiment stories reveals insights that invalidate your current prioritization.

  User Validation Schedule

  Finally, to ensure that you have a constant stream of customer feedback to use for your experiments, plan user research sessions every single week. (See Figure 7-7.) This way your team is never more than five business days away from customer feedback and has ample time to react prior to the end of the sprint. This weekly research cadence provides a good rhythm for your experiment stories as well as a natural learning point in the sprint.

  Use the artifacts you created in the ideation sessions as the base material for your user tests. Remember that when the ideas are raw, you are testing for value (that is, do people want to use my product?). After you have established that there is a desire for your product, subsequent tests with higher-fidelity artifacts will reveal whether your solution is usable.

  Figure 7-7. Conversations with users happen every week

  Participation

  Agile methods can create a lot of time pressure on designers. Some work fits easily into the context of a user story. Other work needs more time to get right. Two-week cycles of concurrent development and design offer few opportunities for designers to ruminate on big problems. And although some Agile methods take a more flexible approach to time than Scrum does (for example, Kanban does away with the notion of a two-week batch of work, and places the emphasis on continuous flow), most designers feel pressure to fit their work into the time-box of the sprint. For this reason, designers need to participate in the sprint-planning process.

  The major reason designers feel pressure in Agile processes is that they don’t (for whatever reason) fully participate in the process. This is typically not their fault: when Agile is understood as simply a way to build software, there doesn’t appear to be any reason to include nontechnologists in the process. However, without designer participation, their concerns and needs are not taken into account in project plans. As a result, many Agile teams don’t make plans that allow designers to do their best work.

  For Lean UX to work in Agile, the entire team must participate in all activities—stand-ups, retrospectives, IPMs, brainstorming sessions—they all require everyone’s attendance to be successful. Besides negotiating the complexity of certain features, cross-functional participation allows designers and developers to create effective backlog prioritization.

  For example, imagine at the beginning of a sprint that the first story a team prioritizes has a heavy design component to it. Imagine that the designer was not there to voice her concern. That team will fail as soon as they meet for their stand-up the next day. The designer will cry out that the story has not been designed. She will say that it will take at least two to three days to complete the design before the story is ready for development. Imagine instead that the designer had participated in the prioritization of the backlog. Her concern would have been raised at planning time. The team could have selected a story card that needed less design preparation to work on first—which would have bought the designer the time she needed to complete the work.

  The other casualty of sparse participation is shared understanding. Teams make decisions in meetings. Those decisions are based on discussions. Even if 90 percent of a meeting is not relevant to your immediate need, the 10 percent that is relevant will save hours of time downstream explaining what happened at the meeting and why certain decisions were made.

  Participation gives you the ability to negotiate for the time you need to do your work. This is true for UX designers as much as it is for everyone else on the team.

  Design Is a Team Sport

  In the following case study, designer and coach Lane Goldstone details how she brought to the table all the players—development, design, marketing, stakeholders—to create a tablet game.

  Case Study: Knowsy (by Lane Goldstone)

  In my work as a product designer, I use Lean UX practices on a variety of projects. Recently I’ve worked on entertainment, ecommerce, and social-media products for different platforms, including iPad, iPhone, and the Web. The teams have been small, ranging from three to seven people. Most of my projects also share the following characteristics:

  The project is run within an Agile framework (focus on the customer, continuous delivery, team sits together, lightweight documentation, team ownership of decisions, shared rituals like stand-ups, retrospectives, and so on).

  The team contains people with a mix of skills (frontend and backend development, user experience and information architecture, product management and marketing, graphic design, and copywriting).

  The people on the team generally performed in their area of expertise/strength, but were supportive of other specialties and interested in learning new skills.

  Most of the teams I work with create entirely new products or services. They are not working within an existing product framework or structure. In “green fields” projects like these, we are simultaneously trying to discover how this new product or service will be used, how it will behave, and how we are going to build it. It’s an environment of continual change, and there isn’t a lot of time or patience for planning or up-front design.

  The Innovation Games Company

  The Innovation Games Company (TIGC) produces serious games—online and in-person—for market research. TIGC helps organizations get actionable insights into customer needs and preferences to improve performance through collaborative play. In 2010, I was invited to help TIGC create a new game for the consumer market.

  I was part of the team that created Knowsy for iPad (Figure 7-8), a pass-‘n’-play game that’s all about learning what you know about your friends, family, and coworkers—while simultaneously testing how well they know you. The person who knows the other players best wins the game. It is fast, fun, and a truly “social” game for up to six players.

  It was our first iPad application, and we had an ambitious deadline: one month to create the game and have it accepted to the Apple Store. Our small team had a combination of subject-matter expertise and skills in frontend and backend development as well as visual and interaction design. We also drew on the help of other people to help us play-test the game at various stages of development.

  Figure 7-8. The Knowsy team with the wall of artifacts behind them

  A Shared Vision Empowers Independent Work

  Until a new product is coded, it’s difficult for people to work within the same product vision. You can recognize a lack of shared vision when the team argues about what features are important or what should be done first. There can also be a general sense of tension that the team is not “moving fast enough” or it feels like the team is going back over the same issues again and again.

  While working on Knowsy, I looked for ways that I could make my UX practice more quick, visual, collaborative, and continuous. I looked for opportunities to work in real time with other people on the team (such as developers and the
product manager) and rough things out as quickly as possible at the lowest responsible level of fidelity.

  As we found the appropriate solutions and the team understood and bought into the design concept, I was able to increase fidelity of the design artifacts, confident that we shared a product vision.

  Breaking the Design Bottleneck

  Early in the project, I sat with the frontend developer to talk about the game design. We created a high-level game flow together on paper (Figure 7-9), passing the marker back and forth as we talked. This was my opportunity to listen and learn what he was thinking. As we sketched, I was able to point out inconsistencies by asking questions like, “What do we do when this happens?” This approach had the benefit of changing the dialog from, “I’m right-you’re wrong,” to “How do we solve this problem?”

  After we had this basic agreement, I was able to create a paper prototype of the game based on the flow and we play tested it with the team. The effect on the team was immediate. Suddenly, everyone “got it” and was excited about what we were doing. People began to contribute ideas that fit well together, and we were able to identify what parts we could each work on that supported the whole.

  When we were all on the same page, it was easier for me to take some time away from the team and document what we’d agreed in a clickable prototype.

  Figure 7-9. The paper prototype begins to take shape

  The Outcome

  Knowsy’s foray into Lean UX proved a success. We got the app to the Apple Store in time for the deadline. I was called back later to help the team do another variant of the product. For that go-around, I used a similar process. Because I was working remotely and the development team was not as available to collaborate, I had to make heavier deliverables. Nevertheless, the basic principle of iterating our way to higher fidelity continued.

  Figure 7-10. Lane updating the prototype and artifact wall in real time

  Beyond the Scrum Team

  Management check-ins are one of the biggest obstacles to maintaining team momentum. Designers are used to doing design reviews, but unfortunately, check-ins don’t end there. Product owners, stakeholders, CEOs, and clients all want to know how things are going. They all want to bless the project plan going forward. The challenge for outcome-focused teams is that their project plans are dependent on what they are learning. They are responsive, so their typical plan lays out only small batches of work at a time. At most, these teams plan an iteration or two ahead. This perceived “short-sightedness” tends not to satisfy most high-level managers. How then do you keep the check-ins at bay while maintaining the pace of your Lean UX and Scrum processes?

  Two words: proactive communication.

  Jeff once managed a team that radically altered the workflow for an existing product that had thousands of paying customers. The team was so excited by the changes they’d made that they went ahead with the launch without alerting anyone else in the organization. Within an hour of the new product going live the vice president of customer service was at Jeff’s desk, fuming and demanding to know why she wasn’t told of this change. The issue was this: when customers have problems with the product, they call in for help. Call center representatives use scripts to troubleshoot customer problems and to offer solutions—except they didn’t have a script for this new product. Because they didn’t know it was going to change.

  This healthy slice of humble pie served as a valuable lesson. If you want your stakeholders—both those managing you and those dependent on you—to stay out of your way, make sure that they are aware of your plans. Here are a few tips:

  Maintain a “Problem Roadmap.” Instead of using a feature roadmap to communicate with stakeholders, transform the roadmap to communicate the problems you’ll be working on. Use this Problem Roadmap to drive planning and check-in meetings with stakeholders.

  Proactively reach out to your product owners and executives to keep them updated on your plans.

  Let them know:

  how the project is going;

  what you tried so far and learned;

  what you’ll be trying next;

  what risks you see in the product and how you plan to address them.

  Keep the conversations focused on outcomes (how you’re trending toward your goal) not feature sets.

  Ensure dependent departments (customer service, marketing, operations, etc.) are aware of upcoming changes that can affect their world.

  Provide them with plenty of time to update their workflows if necessary.

  Lean UX and Agile in the Enterprise

  Many of the tactics covered in this book are focused on one team. But in the real world, enterprise organizations have multiple product development teams working in parallel. How does Lean UX scale when the number of teams grows to tens or even hundreds of concurrent workstreams? This is the question of the moment in the Agile community. As Lean and Agile methods have become more mainstream, and as they have become the default working style for technology teams across industries, many people have become focused on this question. Large organizations have a legitimate need to coordinate the activity of multiple teams—processes based on learning your way forward present a challenge to most traditional project management methods.

  A full discussion of how to create a truly Agile and Lean organization is beyond the scope of this book. It requires leadership to radically rethink the way it sets strategy, assembles teams, and plans and assigns work. That said, there are a few techniques that can help Lean UX scale in enterprise Agile environments and even take advantage of that scale. Here are just a few issues that typically arise and ways to manage for them:

  Issue

  As projects grow bigger, more teams are assigned to them. How do you ensure that all teams are aligned to the same vision and not optimizing locally?

  Solution

  The concept of managing to outcomes applies to a set of teams as much as it does to individual ones. To ensure that all the teams working on the same project have a shared vision, assign them all the same success metric. Working together, they can define the leading indicators that drive that metric and divide those leading metrics between the teams on the project. But teams must not be allowed to focus on leading metrics to the exclusion of the larger outcome: the entire set of teams succeeds only if they hit the overarching outcome together.

  Issue

  How do you ensure that teams are sharing what they’re learning and minimizing duplicate effort to learn the same things?

  Solution

  Although there’s no silver bullet to solve for this issue, the successful practices we’ve seen include a central knowledge management tool (like a wiki), regular team leadership meetings (like a Scrum of Scrums), and open-communication tools that focus on research (like a dedicated channel on Slack or your internal chat tool).

  Issue

  Cross-team dependencies can keep progress at a crawl. How do you maintain a regular pace of learning and delivery in a multiteam environment?

  Solution

  Create self-sufficient “full-stack” teams. Full-stack teams have every capability needed for them to do their work on the team. This doesn’t mean that they need a person from each department—just that there is someone on the team who can do one or more of the things the team might need. The specific disciplines on the team—designers, content people, frontend developers, backend developers, product managers—coordinate with one another at discipline-specific meetings to ensure that they are up-to-date on their practice, but the work takes place locally.

  Wrapping Up

  This chapter took a closer look at how Lean UX fits into an Agile process. In addition, we looked at how cross-functional collaboration allows a team to move forward at a brisk pace, and how to handle stakeholders and managers who always want to know what’s going on. We discussed why having everyone participate in all activities is critical and how the staggered-sprint model, once considered the path to true
agility, has evolved into design sprints and dual-track product discovery and delivery.

  In the next chapter, we take a look at the organizational shifts that need to be made to support Lean UX. This chapter can serve as a primer for managers on what they’ll need to do to set teams up for success.

  1 Desirée Sy, “Adapting Usability Investigations for Agile User-centered Design”, Journal of Usability Studies, May 2007.

  2 Teams that work on mobile apps fall into a gray zone here. You can update frequently, but not continuously, so you’ll need to become crafty with your techniques. Using feature flags to turn some features on and off can help. You can also deliver experimental features inside apps by using a browser container within the app itself. Finally, it’s possible to test really early versions of features on the mobile web.

  Chapter 8. Making Organizational Shifts

  In baseball, you don’t know nothing.

  —Yogi Berra

  In Part I of this book, we discussed the principles behind Lean UX. We hope you understand from that section that Lean UX is a mindset. In Part II, we discussed some of the key methods of Lean UX, because Lean UX is also a process. As we’ve worked with clients and taught these methods to teams, it’s become clear that Lean UX is also a management method. For this reason, you’ll need to make some changes in your organization to get the most benefit from working this way.