Lean UX: How to Accelerate Your Software Design Process

Long gone are the days when you go and purchase the latest software at the Microsoft store. Now, with SaaS dominating the market, software companies need to release updates quickly and regularly to keep up in the market.

This rapid release cycle puts the heat on designers, who must craft experiences that users actually want. In the past, the UX design process has been gradual and meticulous. But with development frameworks like agile, there’s much less time for drawn-out processes. This is where Lean UX comes in.

In this post, we’ll introduce you to the Lean UX methodology. You’ll learn what it is, why companies are adopting it, its core concepts, and finally the process itself and how you can adopt it within your design team. There’s no time to waste, so let’s dive in.

What is Lean UX?

Lean UX is an approach to user experience design that emphasizes rapid iterations of ideation, testing, and analysis to create user-centric products and experiences. The goal of Lean UX is to reduce development time, effort, and cost with frequent low-risk experiments and user testing before changes to the product are implemented.

Lean UX was introduced by Jeff Gothelf in his 2013 book Lean UX: Designing Great Products with Agile Teams. As the title suggests, Lean UX draws heavily from the practices of agile software development, in which tasks are carried out simultaneously instead of linearly, product improvements are made in short iterations, and plans are consistently evaluated and adapted to business and customer needs.

The Lean UX methodology is also an evolution of the more broad “lean thinking,” which was coined by Toyota in the 1990s to describe its manufacturing process. Lean principles aim to reduce wasted time, effort, and materials in the manufacturing of physical products. Lean UX applies these same concepts to software design.

In broad terms, Lean UX differs from more traditional UX approaches in its process: Rather than devoting long stretches of time to pursuing one idea, Lean UX teams quickly iterate through experiment cycles guided by hypotheses and feedback from both users and stakeholders, in order to filter down to the best designs for the product.

Why use Lean UX?

Time for an analogy: My friend is throwing a party and I’ve decided I’m going to bake her the perfect cake for it. She’s very particular about her cakes, so it needs to have everything she wants: the right flavor, texture, frosting, and, of course, the right number of candles. So, for the next three months, I lock myself alone in my apartment developing a recipe. My family is getting worried.

The date of the party eventually arrives, and I unveil what I believe to be the perfect cake: a three-tiered chocolate-raspberry buttercream concoction with “Happy Birthday” scrawled on top. Unfortunately, my friend tells me in the nicest way possible that she hates chocolate, is lactose intolerant, thinks anything more than two tiers is gauche, and it’s not her birthday party — it’s her graduation.

A better approach might have been to pull in some other friends who are better bakers, ask my friend what she’s looking for in her perfect cake, and develop some cupcake prototypes for her to try. This way, I’ll know what I need to eventually bake much earlier in the process, and don’t have to bake an entire cake only to find out that I shouldn’t have followed my instincts.

Swap the cake for software, and we can see the benefits of lean UX. When you invest months into a product or product feature, only to find out that (1) some business need means you need to pivot your design or (2) your users don’t like your product, this wastes a tremendous amount of time and resources. And, unlike cake, you can’t take the leftovers home to enjoy later.

Lean UX assumes that you and your team’s intuitions are going to be wrong and, in order to create the best possible product for users, you need to experiment until you get it right. Rather than putting your resources into an idea that might fail, Lean UX facilitates low-risk experiments until you discover something that sticks.

Key Concepts in Lean UX

Before unpacking the process of Lean UX, let’s first cover some fundamental concepts and terms in the Lean framework that, once we know them, will help the steps make more sense.

User Research and Testing

Of course, user research and testing are not unique to Lean UX. Your users give you some of the most valuable insights possible about the product — they can tell you how your product makes them feel and show you how they naturally use your product. This is true for any type of UX — the U stands for “user” after all.

However, in Lean UX, this process is not isolated to one phase in a project. Lean UX emphasizes very frequent learning from your current (or intended) users, and makes room for them in each step to guide your design choices, not just in the early stages.

This is essential to ensure you’re building something that users want without wasting long periods of time if an idea doesn’t work out. Continuous research makes it much easier to pivot ideas since you’re not investing excessive time in a single, ill-fated idea.

Additionally, Lean UX delegates research duties across a design team instead of only UX researchers, which allows for faster data collection, interpretation, and decisions.

Collaboration

A successful Lean UX strategy also requires much more overall collaboration than traditional UX methods. Instead of separate tasks being handled by separate teams, Lean UX teams are cross-functional — they have contributors from different parts of the company. For instance, a team might contain a product manager, engineers, designers, marketers, research specialists, and data analysts.

The idea behind cross-functional teams is that they bring more diversity into the UX process, which leads to different perspectives on problems and smarter solutions to design challenges. They also give UX experience to people who otherwise wouldn’t interact with users at all.

It’s one thing to create a diverse team, but that doesn’t mean much if teams aren’t talking to each other. Lean UX requires stakeholders to be on the same page throughout the project, so frequent communication is a must to prevent information silos. With proper communication, teams can work in parallel to complete design cycles quickly and efficiently.

Flexibility

To a Lean UX team, the only certainty is that nothing is certain. Lean UX designers go into projects not just prepared for plans to change, but expecting them to.

Instead of a single roadmap dictating how a project will go for the next several months, teams change their approach during the process to adapt to user feedback. No one idea is sacred in Lean UX — the process is set up to rapidly generate new ideas, test them, and toss them out if they’re ineffective.

While straightforward in concept, this mentality is difficult to adopt for some. If you come up with an idea that has promise, it’s tough to avoid growing attached. The truth is that Lean UX requires teams to abandon this mindset and pursue the best products for their users, not their egos.

(Lack of) Deliverables

For design teams to stay as agile as possible, lean UX de-emphasizes the role of deliverables like documentation and reports, for the simple reason that there just isn’t enough time to create and maintain them. Cycles move quickly, and this requires trimming off all the excess — that’s what makes the method “lean.”

This is a big shift away from traditional UX, in which deliverables and requirements guide a project. These are created at the start of the process and dictate the general direction of the project. As we now know, these kinds of deliverables don’t give us the flexibility to execute with Lean UX.

In Lean UX, deliverables that are common in more traditional UX methods are stripped to their simplest form, if not excluded altogether. Instead, the product itself is the primary deliverable. You don’t need pages and pages explaining your designs when you have the product right there. Plus, when the product changes in future cycles, this documentation becomes outdated.

Lean UX Process

We’ve spoken enough about what Lean UX is and why it’s used. Now, let’s dive into the process itself.

Lean UX teams develop products in cycles, each cycle made to improve the product. A cycle consists of three phases: Think, Make, and Check.

Think

“Think” is the first phase in a Lean UX design cycle, in which teams propose improvements for the product based on users’ problems. Rather than making a set list of features to implement, the team starts with an initial problem statement, which is then turned into an assumption and finally an actionable hypothesis that is believed will improve the user experience.

Problem Statement

A Think phase begins by coming up with a problem statement. A problem statement is a short description of an issue you’ve observed in your product. Problems can be sourced from user research and feedback, competing products, and brainstorming sessions.

For example, a problem statement for a cake recipe app might be: “Users want to be able to post and share their cake recipes with other users so they can grow followers and learn recipes from fellow bakers. There is currently no way to do this in our application, and users are spending less time on the app than if social features were available.”

From your ideation sessions, you might produce more than one problem statement. That’s normal, but you should focus on just one problem per cycle. Your team decides which problems are the most pressing and are most likely to help you meet business goals when addressed.

Assumption

With your problem statement ready, you’ll turn it into an assumption next. An assumption is a statement you believe to be true about your users. The goal of an assumption is to align the team on what users need, based on what you’ve uncovered from research and feedback.

To create assumptions, gather your team and conduct a brainstorming session. Have everyone generate multiple assumptions based on your problem statement. Think about assumptions that answer the following questions:

• Who are your users? An assumption that answers this question might be, “Our users are home cooks and bakers, most aged 25-40, who are avid social media users.”
• What do our users want? An assumption for this question might be, “Our users want a way to interact with other users of the app and share their recipes.”
• What are your users’ pain points? An assumption for this may be, “Our users are frustrated that they can’t locate recipes easily on the app.”
• When is the product used and in what context? An assumption for this could be, “Our users typically use the app while baking in their homes.”

Even though your assumptions are based at least partially on research and feedback, they may be wrong — that’s why they’re called assumptions! But, remember, a core concept of Lean UX is flexibility. As the project advances, you’ll likely have to reshape your assumptions as you iterate ideas. That’s expected.

Narrow down your pool of assumptions to a handful of the most important ones — the assumptions that address the most pressing issues to the business. Then, form your hypothesis based on those assumptions.

Hypothesis

The hypothesis is the final takeaway from the Think phase. It’s a proposed theory that answers your assumptions. It’s very important that your hypothesis is something that your team can test, as it will shape your approach for the Make and Check phases.

To create a hypothesis, phrase it in terms of what your team believes, and touch on what feature you’re implementing, what user group you’re targeting (it could be all users if you only have one persona), how the feature helps the user group, and the business result that will prove your hypothesis to be true.

Back to our cake app, our hypothesis for a Lean UX cycle could be: “We believe that our users, especially those aged 25-40, want a way to share their recipes and find new ones from other bakers. By allowing users to post and share their recipes publicly, we expect daily downloads to increase by 10%.”

Make

In the “Make” phase, we move from thinking and planning to designing. More specifically, your team will create a low-fidelity version of your product that will be used to test your hypothesis.

The centerpiece of the Make phase is the minimum viable product (MVP). An MVP is the simplest version of your product that you can use to test your hypothesis. The purpose of an MVP is to test and receive feedback on your product as soon as possible.

When designing your MVP, only include what is necessary to test your hypothesis, and strip away anything irrelevant. For instance, when testing a new feature on a website, a single web page with the core feature you’re testing might work. Or, it might not even have to be a fully coded prototype — it could instead be a slide deck, wireframe, or mockup that mimics your application.

The simpler your MVP, the more quickly you can proceed to the next phase. Keeping things simple also keeps you from becoming too attached to your designs, which is important given the current feature may not be successful in addressing the users’ problem.

MVPs aren’t just the job of designers, either. Get the entire team involved when creating the product, and be sure all members can offer feedback and suggestions.

Check

In “Check,” the last phase of the cycle, you’ll test your MVP with your users and stakeholders to confirm or reject the hypothesis you created in the Think phase. Based on the outcome of this phase, the new feature you’ve developed will either be further incorporated into the product design or scrapped before a new cycle begins.

It’s most important that you test your MVP with real people and ask for their feedback. Opt for quick and easy testing methods like A/B testing, surveys, and unmonitored usability testing as these will save time and cost.

However, you can also employ interviews, focus groups, and other moderated approaches if you’d prefer. With these methods, you only need to test with five or so users to find most of the usability issues with the feature — after that, you’ll most likely get the same feedback.

At the end of this phase, you should determine whether the improvement you introduced at the beginning of the cycle was, well, actually an improvement. Did it actually make the product better for users? If so, keep it. If not, suggest improvements or move on to another idea. The point of lean UX is to make design cycles fast and cheap so that an unsuccessful cycle has minimal negative impact on the business.

Lean UX: Accelerate your UX process.

Lean UX is all about reducing friction and getting designs out the door quickly and cheaply, while garnering input from different stakeholders to meet both users’ needs and business goals.

For organizations that are accustomed to more traditional processes, the shift to Lean UX may be met with hesitancy. However, Lean UX has been proven as the next iteration of design — we would say it’s worth a shot.