I gave a short talk on what makes Lean UX Lean. Since I’m a blogger at heart, I wrote down pretty much everything I was going to say first, which means I can now publish a draft of the talk here! If you didn’t get to hear the panel, or if you did and want a quick refresher, please enjoy!
I’ve been a user experience designer for a lot of years, and I’ve worked with a lot of lean startups, which is part of the reason why I got a call last year from Manuel Rosso, the CEO of Food on the Table.
Now, Food on the Table is a very lean startup here in Austin. Because they’re a lean startup, they measure absolutely everything. And because they measure everything, Manuel knew immediately when the product developed an activation problem.
The whole project has been written up in a post for Eric’s Startup Lessons Learned blog, and I strongly recommend that you go read it if you haven’t already. It has a lot of tips about how to incorporate design into your startup that you’ll hopefully find helpful.
But today, I want to go a little deeper into what made that project a good example of Lean UX. Because, during that project, we did a lot of things that you might do in any sort of a UX project for any sort of a company.
For example, we did qualitative user research to understand why users were having a problem. We made sketches and built interactive prototypes, and we tested and iterated on them.
These are wonderful, helpful things to do, but they’re not unique to Lean User Experience Design. They’re part of User Centered Design, which I’m a huge fan of, and I’ve done all of those things in waterfall projects at giant companies that were anything but lean.
So, what are a few things that made this a lean ux project and not just a regular old redesign?
Integrating Quantitative Research
I think the first hallmark of Lean UX is using quantitative metrics to both drive and validate design changes. What does that mean? Well, it means that the reason we were working on the first time user experience was because a specific metric, activation, wasn’t as high as the team wanted it to be.Quantitative metrics didn’t tell us exactly why we had a problem - we needed to do our qualitative research to understand that - but it did tell us what our most immediate problem was, which helped us to understand where we should start improving our user experience.
In that way, the metric drove the product decision.
Quantitative metrics also meant that we knew, at the end of the project, we’d be validating our work with an a/b test against the original design. That quantitative validation of design really helps improve the design process over the long run, because we can see what sorts of changes have the biggest positive impact on our end user experience. That lets us improve the ROI on future design projects.
Overlapping Design and Development
Another thing that makes lean UX different is a serious commitment to designing in parallel with engineering. In waterfall design, of course, all the design and research are done up front and then thrown over the wall to engineering.But Lean UX is different. In Lean UX, design and development are working at the same time. This can be tricky, of course, since a lot of people don’t understand how you can start to build something until you know exactly what you’re building.
Well, here’s how we did it at Food on the Table. Once we had done our very fast, initial user research to understand the reasons for our activation problem, we came up with a lot of different fixes we knew we wanted to make. We then split those fixes into three different types: Fix Now, Redesign, and Iterate later.
The fix now problems were low hanging fruit. Those were usability bugs (or plain old BUG bugs) that could be addressed immediately by the engineering team without waiting for design. That meant that the users (and the company!) started seeing improvements immediately, rather than having to wait for a single, massive rollout of all the changes. Why make small changes wait on big changes?
Also, when it came to the stuff we were going to redesign completely, we didn’t wait for everything to be perfect before sharing the new design with engineering. While we were working on things like button placement, page layout, copy writing, or visual design, they could get started with the major structural changes and backend improvements that would be needed.
By overlapping design and development in this way, the whole project moved much faster.
Planning for Iteration
Perhaps the biggest difference with Lean UX vs User Centered Design, is planning for iteration rather than trying to include all the new features at once.As I mentioned before, we separated our changes into three buckets: Fix Now, Redesign, and Iterate Later. That last one’s important, since it means that you are getting a good version of your design in front of users quickly in order to learn from it and optimize it rather than trying to come up with a perfect version of the design before building anything. This should sound pretty familiar to all of you.
Here’s an example. Food on the Table lets people choose recipes and add them to a meal plan. We found, during testing, that users enjoyed choosing from a selection of recommended recipes.
But that led to questions. How many recipes would users want recommended? Would they like to see recipes that their friends were recommending? Did they want to see recipes they’d recommended to others? Would they like to see them in a carousel or a list or a coverflow?
Luckily, these were all questions that could optimized later with a/b tests, once we’d implemented the major structural change, which involved letting people select recommended recipes at all.
Why was this important? Well, it meant we didn’t have to guess or debate or spend a lot of time prototyping and testing the exact right number and content of the recipes page before launch. We could concentrate on getting the user flow and the main interactions right and improve the rest later, once we’d validated that our larger design assumptions were correct.
So What Is It?
So, what makes Lean UX lean? Essentially, it’s about more than just applying good design principles to a Lean Startup, although, that is obviously important. It’s also about applying Lean principles to the design process.Lean UX incorporates quantitative & qualitative research, it overlaps the design and development phases of the project, and it starts small and plans for iteration. And, I think, that all those things together with a great, user centered design process allow Lean UX to deliver huge value to both users and startups very quickly.
Like the post? Follow me on Twitter!
Wish you'd heard the talk? Don't miss the next one! I'll be speaking and running a workshop at Web 2.0 Expo in San Francisco on March 29th.
