Lean UX: Designing Great Products with Agile Teams

by Jeff Gothelf

Take Amazon as an example. The ecommerce giant pushes new code live to their customers every 11.6 seconds.1 And they are using these short cycles as a competitive advantage — releasing early and often, gaining market feedback, and iterating based on what they learn to create a continuous conversation with customers. In essence, they are discovering their product at the same time they are delivering it. This has many benefits but perhaps the two most important ones are: The ability to learn, continuously and quickly, how well their products are meeting customer needs Raising customer expectations in terms of product quality and company response times to their concerns and feedback

Individuals and interactions over processes and tools. Lean UX favors collaboration and conversation over deliverables and rigid process. It engages the entire team to generate ideas from diverse points of view. It encourages the free and frequent exchange of ideas to allow the team to debate, decide, and move forward quickly. Working software over comprehensive documentation. Every business problem has endless solutions, and each member of a team will have an opinion on which is best. The challenge is figuring out which solution is most viable. Sometimes, it’s difficult or impossible to predict in advance which solution will work. By getting our ideas into the hands of customers (often through working software) sooner, the team can quickly assess solutions for market fit and viability. Customer collaboration over contract negotiation. Collaborating with your teammates and customers builds a shared understanding of the problem space and the proposed solutions. It creates consensus behind decisions. The result? Faster iterations, real involvement in product-making, and team investment in validated learning. It also lessens dependency on heavy documentation because everyone on the team has already participated in making the decisions. Collaboration creates alignment more effectively than written communication, argument, and elaborate defense. Responding to change over following a plan. The assumption in Lean UX is that the initial product designs will be wrong, so the team’s...

A problem-focused team is one that has been given a business problem to solve, as opposed to a set of features to implement. In other words, this is a team that has been organized around an outcome.

In Lean UX, teams are trying above all to create a meaningful and measureable change in customer behavior: an outcome.

When you’re creating hypotheses to test, you want to try to be very specific regarding the outcomes you are trying to create. We discussed earlier how Lean UX teams focus less on output (the documents, sketches, products, and features that we create) and more on the outcomes that these outputs create. Can we make it easier for people to log in to our site? Can we encourage more people to sign up? Can we encourage greater collaboration among system users?

Whereas earlier the goal had been to provide broad coverage and broad adoption, the new design system would be driven by new needs: it needed to enable great Predix applications, which was a more focused problem than before. It needed to limit the number of UI choices rather than supporting every possible UI widget. It still needed to be easy to adopt and use — it was now intended for use by GE customers — but now it was imperative that it be easy to maintain, as well.

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. The system is actionable Your design system is not just a library or museum for user interface elements. It should be a “widget factory” that can produce any interface element on demand. As each new element is added to the system, make it available for download in whatever formats your team will need. Ensure that not only the code is available but the graphical and wireframe assets, as well. This allows every designer to have a full palette of interface elements with which to create prototypes at any given time. The system is accessible Accessibility means that the design system is available to everyone in your organization. Accessible design systems are: Easily found Use a memorable URL and ensure that everyone is aware of it. Easily distributed Ensure that your teams can access it at their convenience (in the office, out of the office, on mobile devices, etc.). Easy to search A comprehensive and accurate search of the design system greatly increases its usage. Easy to use Treat this as you would any other design project. If it’s not usable, it will go unused very quickly.

If your team has a demo day (and if they don’t, they should) bring the prototype there to show progress on the project. The more exposure the MVP receives, the more insight you’ll have as to its validity. Next, take your prototype to customers and potential customers. Let them click through the experience and collect their feedback.

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. Instead, you’ll find yourself taking advantage of your weekly test sessions to get insight on whatever is ready, and this will create insight for you at every stage of design and development.

In the preceding discussions, we looked at ways to use qualitative research on a regular basis to evaluate your hypotheses. However, as soon as you launch your product or feature, your customers will begin giving you constant feedback — and not only on your product. They will tell you about themselves, about the market, about the competition. This insight is invaluable — and it comes in to your organization from every corner. Seek out these treasure troves of customer intelligence within your organization and harness them to drive your ongoing product design and research, as depicted in Figure 6-7.

In short, Sy and Miller described a process in which design activity takes place one sprint ahead of development. Work is designed and validated during the “design sprint” and then passed off into the development stream to be implemented during the development sprint, as is illustrated in Figure 7-1. Figure 7-1. Sy and Miller’s “Staggered Sprints” model

Teams using Lean UX must be empowered to decide for themselves which features will create the outcomes their organizations require. To do this, teams must shift their conversation with leadership from one based on features to one centered on outcomes. This conversational shift is a radical one. Product managers must determine which business metrics require the most attention. What effect are they trying to create? Are they trying to influence customer behavior? If so, how? Are they trying to increase performance? If so, by what measure? These metrics must be linked to a larger business impact. Leadership must set this direction. If not, teams must demand this shift of them. Teams must ask, “why are we working on this project?” And, “how will we know we’ve done a good job?” Managers need to be retrained to give their teams the answers to these questions. They must be given the freedom to work with their teams to determine which features best achieve these goals. Teams must move from feature roadmaps to backlogs of hypotheses to test. Work should be prioritized based on risk, feasibility, and potential success.