Lean UX: Designing Great Products with Agile Teams

by Jeff Gothelf

Stay agile Learnings will come in quickly; make sure you’re working in a medium or tool that allows you to make updates easily.

Don’t reinvent the wheel Lots of the mechanisms and systems that you need to test your ideas already exist. Consider how you could use email, SMS, chat apps, Facebook Groups, eBay storefronts, discussion forums, and other existing tools to get the learning you’re seeking.

Measure behavior Build MVPs with which you can observe and mea...

Talk to your users

some guidelines to building valuable MVPs:

Be clear about your learning goals Make sure that you know what you’re trying to learn, and make sure you are clear about what data you need to collect to learn.

Go small Regardless of your desired outcome, build the smallest MVP possible. Remember that it is a tool for learning. You will be iterating.

You don’t necessarily need code In many cases, your MVP won’t involve any code at all. Instead you will rely on many of the UX designer’s existing tools: sketching, prototyping, copywriting, and visual design.

The Truth Curve The amount of effort you put into your MVP should be proportional to the amount of evidence you have that your idea is a good one.

Remember the key question: What’s the smallest thing that you can do to learn the next most important thing? Anything more than that is waste.

Feature fakes should be used sparingly and taken down as soon as a success threshold has been reached. If you feel they might negatively affect your relationship with your customer, you can make it right by offering those that found your mousetrap a gift card or some other kind of compensation. And they’re not right for every business or every context.

It’s critical to define the intended audience for your prototype. This allows you to create the smallest possible prototype that will generate meaningful feedback from this audience.

Focusing on the primary workflows when you create your MVP gives the team a sense of temporary tunnel vision (in a good way!), allowing them to focus on a specific portion of the experience and assess its validity and efficacy.

too often, research activities take place on rare occasions — either at the beginning of a project or at the end. Lean UX solves the problems these tactics create by making research both continuous and collaborative.

Lean UX research is continuous.

Lean UX research is collaborative. This means that you don’t rely on the work of specialized researchers to deliver learning to your team. Instead, research activities and responsibilities are distributed and shared across the entire team. By eliminating the handoff between researchers and team members, we increase the quality of our learning.

you should include a researcher on your team if you can. Just don’t outsource the work to that person. Instead, use the researcher as an expert guide to help your team plan their work and lead the team through their research activities. In the same way that Lean UX encourages designers to take a more facilitative approach, Lean UX asks the same of the researcher. Use your expertise to help the team plan good research, ask good questions, and select the right methods for the job. Just don’t do all the research for them.

We routinely run tests with remote observers using nothing more exotic than Google Hangouts. The ability to connect remote observers is a key element. It makes it possible for you to bring the test sessions to team members and stakeholders who can’t be present. This has an enormous impact on collaboration because it spreads understanding of your customers deep into your organization. It’s hard to overstate how powerful this is.

As soon as possible after the research sessions are over — preferably the same day, if not then the following day — gather the team together for a review session. When the team has reassembled, ask everyone to read their findings to one another. One really efficient way to do this is to transcribe the notes people read out loud onto index cards or sticky notes, and then sort the notes into themes. This process of reading, grouping, and discussing gets everyone’s input out on the table and builds the shared understanding that you seek. With themes identified, you and your team can then determine the next steps for your MVP.

Here are a couple of ways to maintain your momentum and ensure that you’re maximizing your learning:

Look for patterns As you review the research, keep an eye out for patterns in the data. These patterns reveal multiple instances of user opinion that represent elements to explore. If something doesn’t fall into a pattern, it is likely an outlier.

Place your outliers in a “parking lot” Tempting as it is to ignore outliers (or try to serve them in your solution), don’t do it. Instead, create a parking lot or backlog. As your research progresses over time (remember: you’re doing this every week), y...

Verify with other sources If you’re not convinced the feedback you’re seeing through one channel is valid, look for it in other channels. Are the customer support emails reflecting the same concerns as your usability studies? Is the value of your prototype echoed with customers inside and outsi...

To maintain a regular cadence of user testing, your team must adopt a “test what you got” policy. Whatever is ready on testing day is what goes in front of the users. This policy liberates your team from rushing toward testing day deadlines.

Monitoring Techniques for Continuous and Collaborative Discovery

Customer Service

On-Site Feedback Surveys

Search logs Search terms are clear indicators of what customers are seeking on your site. Search patterns indicate what they’re finding and what they’re not finding. Repeated queries with slight variations show a user’s challenge in finding certain information. One way to use search logs for MVP validation is to launch a test page for the feature you’re planning. Following the search, logs will inform you as to whether the test content (or feature) on that page is meeting the user’s needs. If users continue to search on variations of that content, your experiment has failed.

Site usage analytics

A/B testing

Dual-track Agile How to plan product discovery activities along with delivery.

Product discovery A term used to describe any learning activities the team undertakes to help them determine what to deliver. Lean UX powers the product discovery process.

Design sprint A term popularized by the design team at Google Ventures used to describe a time-boxed collection of collaborative activities that help a team move quickly from ideas to prototypes. Running a design sprint as “sprint zero” is an increasingly common practice.

Dual-track Agile Popularized by product management guru Marty Cagan, dual-track Agile is an attempt to build a continuous product discovery and delivery model for Scrum teams. It champions a process in which teams manage two backlogs — a discovery backlog and a delivery backlog. They work through their discovery backlogs with only validated items graduating into the delivery cycle.

Staggered sprints can work well for some teams. If your development environment does not allow for frequent releases (for example, you work on embedded software, or deliver software to an environment in which continuous deployment is difficult or impossible),2 the premium on getting the design right is higher. (In these cases, Lean UX might not be a great fit for your team because you’ll need to work hard to get the market feedback you need to make many of these techniques work.) For these teams, staggered sprints can allow for more validation of design work — provided you are still working in a very collaborative manner.

However, this model works best as a transition. It is not where you want your team to end up. Here’s why: it becomes very easy to create a situation in which the entire team is never working on the same thing at the same time. You never realize the benefits of cross-functional collaboration because the different disciplines are focused on different things. Without that collaboration, you don’t build shared understanding, so you end up relying heavily on documentation and handoffs for communication.

There’s another reason this process is less than ideal: it can create unnecessary waste. You waste time creating documentation to describe what happened during the design sprints. And, if developers haven’t participated in the design sprint, they haven’t had a chance to assess the work for feasibility or scope. That conversation doesn’t happen until handoff. Can they actually build the specified designs in the next two weeks? If not, the work that went into designing those elements is wasted.

In our experience, the ideal result of a design sprint is a backlog of hypotheses. This prioritized list of risks defines the work that the team must continue to validate throughout the project lifecycle. Design sprints also help us to better define the scope of our work — at least for the foreseeable future — allowing teams, both in-house and consulting, to provide their stakeholders with a more accurate timeline for product launch.

There are a few pitfalls to watch out for when running a full five-day design sprint:

Use them on the right projects Ensure that the problem space you’re exploring is big enough to warrant putting your entire team in a room for five days. New projects, initiative...

Keep the team size small Design sprints are touted as a great tool for collaboration. This is true, but collaboration can get diluted if too many people are involved. Run these sprints with the core team and their immediate stakeholders. Try to keep the participant number to about 10 people.

Adapt the recipe to your needs There are many detailed descriptions of exactly how to facilitate a design sprint. These are phenomenal resources for early practitioners of this technique. But don’t become stuck following the rules. As you gain experience with design sprints, ask yourself which elements of the design sprint add value given your current project and time constraints, and which can be discarded to save time.

Learning doesn’t end at the end of the...

a single team manages two backlogs: a discovery backlog and a delivery backlog. The team splits into two units to do the work: a discovery unit and a delivery unit. The discovery unit works through the discovery items, running experiments and speaking to customers in an effort to discover which ideas merit further exploration and which don’t. Ideas that graduate from discovery to delivery are built by the delivery unit of the team. This reduces the amount of documentation necessary to drive the delivery process because the people who validated the feature are in close contact with, or in some cases are, the same people who design and implement it.

Our recommendation is to have as many team members involved in discovery as possible, especially early on in an initiative, so that the core decisions about your project are made with everyone’s participation. As the project continues, there will certainly be situations in which not everyone is available for research work. In these cases, those who do the research are responsible for bringing it back to the team as soon as it’s over and discussing their findings while they’re fresh.

Not feeding back evidence from the delivery work to the discovery backlog This challenge is symptomatic of an organization that is still thinking incrementally. After a feature makes it from discovery to delivery, the team will implement it as designed and ship it. The great thing about that is that, as soon as it’s live, this new feature begins to provide a new set of data about how well it’s working and where to focus your next discovery activities. Ensure that your team is continuing to collect feedback on shipped features and using that information to regularly assess the prioritization of their discovery work.

Start work on each theme with some version of a Design Studio or design sprint. (See Figure 7-4.) Depending on the scope of the hypothesis, the design sprint can be as short as an afternoon or as long as a week. You can do them with your immediate team but should include a broader group if it’s a larger-scale effort.

The point of this kickoff is to get the entire team sketching, ideating, and speaking to customers together, creating a backlog of ideas from which to test and learn. In addition, this activity will help define the scope of your theme a bit better — assuming that you’ve built in some customer feedback loops.

After you’ve started your regular sprints, your ideas will be tested, validated, and developed: new insights will come in, and you’ll need to decide what to do with them. You make these decisions by running subsequent shorter brainstorming sessions and collaborative discovery activities before each new sprint begins. This allows the team to use the latest insight to create the backlog for the next sprint.

Bring the output of your design sprint to the iteration planning meeting (IPM).