Lean UX: Designing Great Products with Agile Teams

by Jeff Gothelf

You’ll find during this exercise that there are gaps in your initial brainstorms. Some business outcomes might have no features created for them, whereas some features might not drive any value for the customer or the business. That’s the point of this exercise: to make sense of your initial round of thinking. After you’ve identified the gaps in your brainstorms, fill them in with new sticky notes or leave the less relevant ideas off the chart, as depicted in Figure 3-13. This will help make sense of the undoubtedly large number of ideas your team generates.

It’s not unusual to find solutions that serve more than one at a time. It’s also not unusual to create a hypothesis in which multiple features drive similar outcomes. When you see that happening, refine the hypothesis to focus on just one feature. Hypotheses with multiple features are not easy to test. The important thing to remember in this entire process is to keep your ideas specific enough so that you can create meaningful tests to see if your ideas hold water.

There is no discussion as to whether the solution is usable or desirable, much less delightful. The only testing being done is whether the system “works as designed.”

Our team’s success is not measured in how fast they can get features launched. Instead we measure success by how well our customers can achieve “some goal” initially and ongoing. This is the key difference between user stories and hypotheses. They refocus the team on what’s really important — making the customer successful and thus achieving a business goal — as opposed to measuring team productivity as success.

It’s rare to have a project budget focused strictly on learning. In most cases, we need to ship product at some point, as well. The reason we declare our assumptions at the outset of our work is so that we can identify project risks. After we string them together into hypotheses we create a backlog of potential work. Next, we need to figure out which ones are the riskiest ones — so that we can work on them first.

The higher the risk and the more perceived value involved, the higher the priority is to test those hypotheses first.

This does not mean that assumptions that don’t make the first cut are gone forever. Keep a backlog of the other hypotheses you’ve created so that you can come back to them and test them if and when it makes sense to do so.

If you’ve gone through this process to this point with your entire team (and we strongly recommend that you do), you’ll be in a great position to move forward together. This process is an effective way to create a shared understanding and shared mission across your entire team.

important Lean UX technique: framing our work with outcomes frees us (and our teams) to search for the best solutions to the problem at hand.

As you navigate through the rest of your life, be open to collaboration. Other people and other people’s ideas are often better than your own. Find a group of people who challenge and inspire you, spend a lot of time with them, and it will change your life. — Amy Poehler

Lean UX begins with the idea that user experience design should be a collaborative process.

Lean UX increases your team’s ownership over the work by providing an opportunity for individual points of view to be shared much earlier in the process.

creating hypotheses together increases the Product IQ of the team, designing together increases the Design IQ of the team.

Collaborative design is still a designer-led activity. It’s the designer’s responsibility to not only call collaborative design meetings but to facilitate them, as well. Sometimes, you’ll have informal chats and sketching sessions. Sometimes, more structured one-on-one sessions with a developer at a whiteboard. Other times, you will gather the entire team for a Design Studio exercise. The key is to collaborate with a diverse group of team members. In a typical collaborative design session, teams sketch together, critique the work as it emerges, and ultimately converge on a solution they feel has the greatest chance of success. The designer, while still producing designs, takes on the additional role of facilitator to lead the team through a series of exercises.

Lean UX promotes conversation as the primary means of communication among team members.

Parallel paths for software development and design are the fastest route to reach an actual experience.

Find ways to have more conversations with your teammates, both work-related and not. Time spent cultivating social ties with your team — eating meals together, for example — can make work-related conversations easier, more honest, and more productive.

By putting designers, developers, subject matter experts, product managers, business analysts, and other competencies together in the same space focused on the same challenge, you create an outcome far greater than working in silos allows. It has another benefit. It begins to build the trust your team will need to move from these formal sessions to more frequent and informal collaborations.

Design Studio works within the following flow: Problem definition and constraints Individual idea generation (diverge) Presentation and critique Iterate and refine in pairs (emerge) Team idea generation (converge)

Problem definition and constraints (15–45 minutes)

The first step in Design Studio is to ensure that everyone is aware of the problem you are trying to solve, the assumptions you’ve declared, the users you are serving, the hypotheses you’ve generated, and the constraints within which you are working. This can be a formal presentation with slides or it can be a group discussion.

Individual idea generation (10 minutes)

Sometimes, people find they have hard time facing a blank page. If that’s the case, try this optional step. Ask everyone to label each box on their sheets with one of your personas and the specific pain point or problem they will be addressing for that persona.

Presentation and critique (3 minutes per person)

Pair up to iterate and refine (10 minutes)

Team idea generation (45 minutes)

Now that all team members have feedback on their individual ideas and people have paired up to develop ideas further, the team must converge on one idea. In this step, the team is trying to select the ideas they feel have the best chance for success.

Encourage the team to create a “parking lot” for good ideas that don’t make the cut. This will make it easier to let go of ideas. Again, it’s important to make decisions here: resist the temptation to get consensus by generalizing or deferring decisions.

You can use the designs you’ve created in this process as the basis for building MVPs, for running experiments, for production design and development

it’s generally a good idea to photograph everything and keep it in an archive folder of some sort.

design systems (which we’ll call design systems for the sake of brevity) are a kind of mash up of all of these ideas. A good design system contains comprehensive documentation of the elements of a design, rules and examples that govern the use of these elements, and crucially, contains the code and other assets that actually implement the design.

In practice, a design system functions as a single source of truth for the presentation layer of a product. Teams can sketch at the whiteboard and then quickly use the elements found in the design system to assemble a prototype or production-ready frontend.

Design systems are a powerful enabler of Lean UX.

This has a couple of big benefits for teams: It allows the team to design faster, because they’re not reinventing the wheel every time they design a screen. It allows the team to prototype faster, because frontend developers are working from a kit of parts — they don’t need to recreate the elements of a solution each time, they can just go get the appropriate pieces out of the design system.

Their high-quality work can be implemented by other less-specialized developers in the organization to produce top-notch results.

Collaborative design takes many forms. Sometimes it means designing with your cross-functional team. Sometimes it means designing with your end users. In this instance, it was a hybrid: designing with a cross-functional team of designers and developers who actually are your users.

Whether you are creating a full-blown design system or a more limited style guide, consider these important characteristics: It takes into account audience needs Remember that the audience for your style guide is the entire product team. Designers, developers, QA people, will all rely on the design system for their work.

Continual improvement Design systems must be considered living documents. They must be a single source of truth for your organization. As your product evolves, so too must your design system. The design system should be malleable enough to add updates easily, and you must have a clear process for making these updates.

There is clear ownership Assign an owner to the design system. This could be a dedicated team with a product owner, an editor, or curator who works with content creators, or simply a single responsible person, but it needs to be clear who is responsible for keeping the design system up-to-date. If this becomes a burdensome responsibility, consider rotating this role on a regular basis every three months.

For teams that can’t justify the effort, you can still get a lot of value out of a wiki-based style guide.

We asked the team to come up with as many ideas as they could think of to solve the problem we presented. Each team member wrote one idea per cell in the column marked with that individual’s name. We gave the team five minutes to generate as many ideas as they could. Next, to make sure everyone in each location was aware of all of the proposals, we asked the team members to read their ideas to the distributed team. Some ideas went by quickly, whereas others generated more discussion.

The facilitator created some initial column headers in the second sheet that reflected recurring themes that emerged from discussion. Then, we asked the team to group the ideas under the themes. Everyone moved their own ideas into the theme sheet, and people were free to add new themes if they felt their ideas didn’t fit into any of the existing themes. At the end of this process, we had created a spreadsheet filled with ideas that were sorted into themes. Some themes had just a pair of ideas; others had as many as eight.

At each retrospective, the team should check in with their Working Agreement to see if they’re still following it and if they need to update it to include new agreements or remove old ones that no longer make sense.

Sometimes, teams create an MVP primarily to learn something. They’re not concerned with delivering value to the market — they’re just trying to figure out what the market wants. In other cases, teams create a small version of a product or a feature because they want to start delivering value to the market as quickly as possible. In this second case, if you design and deploy the MVP correctly, you should also be able to learn from it, even if that’s not the primary focus.

Creating an MVP

Your prioritized list of hypotheses has given you several paths to explore. As a team, discuss the first hypothesis in your list with the following framework: What’s the most important thing we need to learn first (or next) about this hypothesis? In other words, what’s the biggest risk currently associated with this approach? What’s the least amount of work we can do to learn that? This isn’t lazy: it’s Lean. There’s no reason to do any more work than you need to in order to determine your next step. The answer to the second question is your MVP. You will use your MVP to run experiments and the outcome of those experiments will inform you as to whether your hypothesis was correct. These experiments should provide you with enough evidence to decide whether the direction you are exploring should be pursued, refined, or abandoned.

Creating an MVP to Understand Value

Get to the point Regardless of the MVP method you choose to use, focus your time distilling your idea to its core value proposition and present that to your customers. The things that surround your idea (things like navigation, logins, and password retrieval flows) will be irrelevant if your idea itself has no value to your target audience. Leave that stuff for later.

Use a clear call to action You will know people value your solution when they demonstrate intent to use it or, gasp, pay for it. Giving people a way to opt in to or sign up for a service is a great way to know if they’re interested and whether they’d actually give you money for it.

Prioritize ruthlessly Ideas, like artifacts, are transient. Let the best ones prove themselves and don’t hold onto invalidated ideas just because you like them. As designers ourselves, we know ...