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 book Lean 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.

I originally wrote this post for the Cooper Journal. You can see it here.