Applying Lean UX

We recently wrapped up a project for a startup in the digital photography space, and aside from being great design partners, one of the fun things about them was their excitement to utilize some of the Lean UX strategies and techniques that former Cooperista Josh Seiden wrote about in his bookLean UX with Jeff Gothelf. We certainly learned a lot from going through the process with this client (learning as you go is, after all, a Lean UX principle). We had some best practices confirmed, and found some new ones and nuances too. Here are just a few that we came across in going through a real-life Lean UX project.

Know your user.

In all the sprinting towards a testable product, remember: you’re designing for real people. Those real people are often not like you. Design is about empathizing with people and their problems, then coming up with solutions to solve them. In theory this is a no-brainer, but in practice this is hard. It means being disciplined about designing for your users’ real challenges, not the ones you assume they have — or even worse, the ones you really, really want them to have because it would be perfect for your business model.

With our photo product partner, we collectively identified several potential user types–sharers, documenters, savers, organizers, and a few more. But designing a super-tool that’s all things to all people wasn’t what we were after. So we chose a specific user with specific attributes, and designed the best product for them. Part of our hypothesis involved seeing if the design worked for that group, and if it did, then we’d start designing improvements for the initial user or for additional user needs.

Start with a hypothesis.

In a Lean environment, every sprint should be working towards testing a hypothesis. So be sure you agree on one from the start and write it on the wall. You’re designing for real people, so a good hypothesis is user-oriented.

A lot of the Lean process is about cutting to get to the Minimum Viable Product (really, it’s Minimum Testable Product). In reality, it’s easy to get distracted by the list of too many amazing ideas that would be “easy to implement” and “easy to test.” A formally agreed-upon hypothesis helps prevent that overload. For every feature or design idea, point to the hypothesis on the wall and ask: “Does this help test the hypothesis?” If the answer is “no,” then it goes into the backlog.

For us, the hypothesis was “Presenting/sorting photos in a certain way will be more relevant to users.” During idea generation, we had some fun ideas related to sharing and remixing photos in new ways–but they weren’t relevant to the hypothesis. So those almost immediately wound up in our parking lot once we finished brainstorming. That allowed us to spend most of our time focusing on ideas around presenting and sorting the photos in a way that was most relevant to users for the current sprint. The other ideas can be resurfaced during later sprints when we wanted to tackle sharing or remixing.

It’s fine to change a hypothesis mid-stream. The team may discover something during the design process that’s an even better opportunity than the one that was originally conceived. But don’t undertake that decision to switch lightly. If you’ve got a new hypothesis, do what you did with the original: Agree on it. Write it on the wall.


Document as you go.

Working in a sprint timeframe, there’s not time to detail out every meeting. Instead, we wound up documenting as we went. We started out with just a basic outline for what needed to be covered, then filled sections in and revised as decisions were made. As the design was more-and-more developed, the documentation got more-and-more detailed. And once or twice a week, we’d do a pass to ensure that there weren’t any inconsistencies. This approach reinforces what Jeff Gothelf and Josh Seiden mentioned in their Cooper Journal interview with Doug LeMoine:

“The deliverable is not the thinking. It’s a record of the thinking and an attempt to share that thinking.”

The focus is on capturing the team’s thinking and helping move it forward, not on creating a perfected requirements document for handoff.

This overall structure allowed us to focus most of our attention on how the MVP would work, and it also included ways to capture great features that didn’t address the hypothesis, as well as pie- in-the-sky ideas. As we talked through designs, we could quickly decide which bucket each idea fell into and treat it appropriately. Is it required to test our hypothesis? Yes? Then let’s talk about it at length to be sure we get it as “right” as we can for the test. Not relevant to our hypothesis, but something that seems viable? Drop it in the backlog bucket and get to it if we have time before the end of the sprint, but keep it in mind when designing for MVP.

Start with a wiki from Day 1.

This is a corollary to “document as you go.” It’s pretty trivial in most environments to set up a wiki, so do it on Day 1 of the project. If you’re working in a Lean environment, the style guide is going to wind up there anyway. Rather than taking notes and creating artifacts in one system and then having to burn time migrating them over to the wiki down the road, just create your documentation as you go directly in the wiki. That way there’s never any confusion about the latest version, even in the early stages.

Lean is like improv.


Design in a Lean environment is similar to improv. When it works well, it’s a series of “Yes, and…” statements. One of the worst things is a “No” answer without a followup. It immediately stops the momentum.

Don’t put the conversation into a dead end. And don’t let others dead-end the conversation either. If someone says “That can’t be done,” don’t just ask them “Why not?”–although that’s important so the team doesn’t continue down roads that aren’t fruitful. Also ask “What’s an alternative solution that’s better or would work?” It keeps the momentum going.

Work with people who are smarter than you.

This is the hardest of all the “best practices” to follow–and it applies to hiring employees, hiring consultants, and picking partners. But if you can do it, the process will be smoother, the design will be better and the project will be more fun. Smart people make everyone around them better.

Be flexible. Every project (and sprint) is unique.

Don’t be a slave to “The Process.” You’re not trying to be the best at Lean UX, you’re trying to build the best product. There are two rules when it comes to working within Lean, Agile, Waterfall or any process framework:

Rule #1: Know the rules.
Rule #2: Know when to break the rules.

Lean does not work for every company or every product or every situation. It’s not a magic bullet for success. Lean UX principles are tools. They’re good tools. But they shouldn’t be the only tools in your toolbox. Choose the best one for the job at hand.


Bob MacNeal
While I cringe at the term Lean because I associate it with manufacturing efficiency, I dig the whole concept of busting out a product via iterative learning about your customers. I find many software developers have difficulty focusing on driving out a viable product (or a hypothesis test) and would rather geem-out on ginning up gratuitous complexity and then "solving" some difficult technical problem. The iterative learning approach seems like a way to focus the team on The What and The Why, rather than The How. As a developer, I'm curious how iterative learning changes the traditional UX cycle. I suppose you still do some up-front research, but then I'd imagine most of the UX is driven out by hypothesis testing, A/B testing, or some such. Thanks for the article!
I greatly appreciate the thought about documenting the thinking around the design. This has been something that the teams that I work with have found to be very helpful in keeping focused on what they know and what they don't know, and actively working to resolve open questions and issues. Deliverables, while helpful in illustrating shared thinking at a certain point, are not nearly as flexible as the use of a shared wiki :) I sometimes cringe at the term Lean. In my company, we use the Kanban methodology of Agile (again, borrowing from manufacturing) and I've found that with development teams that focus on the efficiency (in our case, speed of development or "velocity"), quality and holistic thinking about a product suffers. Another concern we've faced is that sometimes minimally viable product equates to a single feature or functionality, which makes it difficult to think about the whole product or long-term implications of a product (scalability, extensibility, interoperability, robustness, etc). However, iterative is fantastic for helping teams and users to have conversations sooner and more productively about the product and direction. The key is to use each iteration as a learning experience and to document takeaways to apply to the next iteration to keep the team moving forward or to pivot towards the right direction.
Dave Charlton
Because I think the user research tasks take at least two weeks by skilled designers(planning-recruiting-interviewing-modeling), it doesn't seem to fit into Lean UX process. So I wonder how your team dealt with the user research in this lean project. I read the article More, better, faster, though, I still don't understand how your team accomplish Learn phase in just one day. It seems so amazing to me :)
Dan Winterberg
Great thoughts & questions! Josh & Jeff's Lean UX book have some good examples of how to work research into a more iterative product development process. Basically, get into a rhythm where you talk to 2-3 users every week--spend a morning session talking to the users, then regroup with the team in the afternoon to review and synthesize the results. Applied to a web-based product, you'd also have quantitative data to look at simultaneously. That said, the key is to be flexible and fit the process to the goal at hand. In a situation where you're building a complex product from scratch, a more traditional up-front research methodology still works best. (We're working with a current client where we're planning on doing more extensive research for major product releases, and supplementing that with bite-sized weekly research for the more iterative improvements.)

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment