Josh Seiden and I just finished the manuscript for the 3rd edition of the Lean UX book. It’s hard to believe it’s been 8 years since the first edition was published and nearly 10 years since we started writing it. The new edition of the book uses the Lean UX Canvas as the backbone of the book so I thought it would make sense to do a quick video that goes through what we expect to see in each box on the canvas.
In addition, Josh and I have been working on self-paced Lean UX video course. That should be out shortly as well and also uses the canvas as it’s table of contents. Take a look and let me know what you think.
Have you tried using the canvas? What’s worked well for you? Did you learn anything in the video that conflicts with how you’ve been using it? Drop a note in the comments
Transcript
Hey folks. Lean UX Canvas has been out for a few years now but Josh Seiden and I just finished rewriting the Lean UX book. In fact, for the third time. The third edition of the Lean UX book is coming out soon and it’s organized around the Lean UX Canvas. The backbone of the book is the Lean UX Canvas. On top of that, we’re working on a self-paced video Lean UX class. Again, that’s structured around the Lean UX Canvas. I thought I’d take just a couple of minutes and walk through what we expect to see in each one of these boxes because this is a question that comes up over and over again even after people have taken classes with us. Let’s take a look at each box very quickly and then let’s get a sense of what we expect to see in each box.
We’ll start off with the business problem statement. That’s box number 1. What we’re expecting to see is a statement that really frames the work for the team. It frames the work so that it encourages discovery. Things we’re looking for here include what is the current state of the system, the product that we’re working on? Why did we design it in the first place? Why isn’t it meeting expectations at the moment? That’s the problem that we’re trying to solve. Then the final piece in here is if we solve it, how we will we know? In other words, what customer behavior or metric shift will we see? Those are the kinds of things that expect to see here in the business problem statement area of the canvas. If you framework this way, you don’t tell the team what to do, they have to go figure out. They have to do product discovery. They have to do Lean UX. There’s no solutions in here.
Once we’ve got the statement in there, we can move over to box number 2. Box number 2, what we’re really focusing on are customer behaviors. Business outcomes are just regular old outcomes. You could call them key results. Most importantly, you should call them measurable changes in human behavior. These are the measures of success. If you think about it, they’re leading indicators of the metrics that we put in the business problems statements. These could be things like retention, usage, kind of all the pirate metrics, if you will. Acquisition, activation, retention, revenue, referral. These are all the kinds of expressions that we’d see here. There have to be numbers here. They should be ratios or rates assuming you have a baseline. If you don’t have a baseline, then an absolute number works but ultimately you want to ratio or rates because they tell you how you’re trending. This could be things like 50% increase in return visits. That’s the kind of stuff that we’re looking for here. Once we’ve decided what the behavior changes are that we want to see, the next conversation we want to have is about which users. Whose behavior we actually want to change.
There’s a couple of different ways to start this exercise. Most importantly, the first thing that you need to do is make a list of all the different persona types. Often when we teach this, we teach the proto persona exercise which is just an exercise in shared understanding. The first thing you want to do is make a list of all the different persona types. Who are all the different people who might be users in your system? Just make a list of it. It could be customers, perspective customers, vendors or clients. If you’re building internally facing products, it could be engineers, product managers, or designers. Then we want to identify one of them. Pick one from that list and really think about three things. You want to give it a name and a sketch. Just something that gives you something to wrap around it. We want to look at the behavioral, demographic, psychographic characteristics that would impact usage of your product. Things that would go in the top right of your proto persona would be things like level of education, disposable income, age if it makes a difference in how they use your product, gender, only if it makes a difference in how they use your product, do they have a family or not have a family, if it makes a difference. You really have to think about the things that would impact their use of your product. Tech savviness is another big one.
Then in the bottom third of the proto persona, this is where the meat is, is needs and obstacles. We’re looking to define this particular user with the needs and obstacles. What do they need? What’s getting in their way? If you’re familiar with the Value Proposition Canvas, this is like pains and gains. Remember, your users don’t need features. They need to achieve some kind of a goal. I need to never miss a meeting. I don’t need calendar integration. That’s what we’re talking about here.
We’ve defined our problem. We’ve defined our success criteria. We’ve got a sense of whose behavior we actually want to change. Now let’s talk about user outcomes and benefits. This is always a squishy one but this is really the reasons why your target audience would go looking for your product or service. What benefit do they get? What goal do they achieve? Is there a status they reach because of this? This is things like I get to spend more time with my family. I get to look good to my boss. I get to get home for my kids’ soccer game. I make fewer mistakes at work. I’m more efficient. I save money. These are the kinds of benefits that you want to talk about because when you write your hypothesis statements, this is really the piece that appeals to your target audience. This is where you go and mine for calls to action on your landing page. “Get home every day for your kids’ soccer game by downloading this product which will help you achieve some kind of efficiency.” That’s the kind of stuff that goes in here. It’s emotional end states or goals for your target audience. That’s what goes in box 4.
In box 5, we’re talking about solutions. This is the stuff that we make. We’re talking about output here, features, solutions. This could be initiatives if you’re launching a new program. Program is a good one. Policy. Anything that you make for the people that you serve, we want to brainstorm as many of these ideas as we can. Get creative here. This is your opportunity to really get some of these ideas out that you’ve been sitting on for a while.
It’s amazing that at this point, we’re declaring assumptions as we work through the canvas. We’ve got all the pieces now that we need to write our hypothesis statement. The hypothesis statement is written right here in box number 6 in the canvas. It says, “We believe that this business outcome will be achieved if this user attains this benefit with this feature.” Not coincidentally, every one of those variables, in brackets, lines up to box 2, box 3, box 4, and box 5. What we’ve seen teams do, that works particularly well, is we’ve actually seen them move items from those boxes. You have box 2, the business outcomes. Box 3 is the users box. Box 4 is the user outcome or benefit. Box 5 is the solution. What we’re trying to do here is write a story. You’re telling a story when you’re aligning these things up. You often see teams do stuff like this to find combinations of the assumptions from these other boxes that make a hypothesis that actually makes sense. That’s ultimately the goal. What you’re doing here, with hypothesis writing, is you’re telling a story. Completing a hypothesis statement is your first attempt at telling a compelling story. You must believe your hypothesis. If you don’t, you’re never going to convince anybody else that this is something that you should be working on. As you’re aligning your assumptions throughout the canvas, you’re putting together these statements that say, “We believe that we will achieve this outcome for this user because it will help them achieve this benefit with this solution.” You have to believe that statement. If you don’t believe that statement, you’re never going to convince anybody else. That’s what goes in box number 6.
Before we go to box number 7, we have to choose which hypothesis we’re going to proceed with first. You’re going to write multiple hypotheses based on all of the assumptions you’ve declared in the canvas. One thing you want to do is prioritize your hypotheses. We put together this canvas called Hypothesis Prioritization Canvas. The idea here is that you want to map all of your hypotheses on this 2×2 matrix. If you think about all the hypotheses that you’ve written, as you write them, you want to figure out where they go on this 2×2 map. This 2×2 map is made up of a risk axis and a perceived value axis. The x-axis is risk. Risk is going to be contextual to your hypothesis. It could be design risk or marketing risk or brand risk. Then the y-axis is perceived value. This is about how much of an impact you think you’re going to have on the customer and ultimately, on the business itself with each hypothesis. You map these on this matrix and the hypotheses that end up in box number 1 are the ones that we actually test because these are high risk and they’re high value. If you get these right, you’re going to have a big impact on the company. If something ends up box number 2, it’s low risk and high value. This is something we should just build, ship, and measure and make sure it lives up to our expectations. Anything that falls below the risk line, we definitely don’t test. In most cases, we just throw it away especially if it lands in box number 4 where it’s high risk and low value. We’re just going to toss that away. If it lands in box number 3, we’re definitely not testing it. We’re probably not building it unless it’s something that we need to participate in our marketplace like taking payments, for example.
Finally, once you prioritized your hypotheses, your goal is not to let them linger over here. Anything that lands in box number 1 should be tested and then either moved to box number 2 because we’ve increased our confidence in it or moved onto box 4 and we’re going to end up throwing it away. That’s ultimately our goal there.
We’ve written our hypotheses. We go to box number 7. We’ve identified the hypothesis that we want to test. The question here is, “What’s the most important thing we need to learn first about that hypothesis?” And really what we’re talking about here – this is a conversation around risk. The interesting thing here is that when you ask this question about your hypotheses, you’ll get as many answers at least as there are disciplines in the room. You’re going to get technical risks, marketing risks, design risks, business risks, brand risks, etc. That’s great but your job is to identify the thing that’s most important right now. The thing that if you get it wrong, it breaks the hypothesis and you can move onto something else.
Finally, once you’ve identified the most important thing you need to learn first about your hypothesis, we move to box number 8. Box number 8 asks the question, “What’s the least amount of work we need to do to learn the next most important thing?” That’s the thing we decided on in box number 7. The answer to these questions, these are your experiments. These are your landing page tests, your customer interviews, your paper prototypes, A/B tests, etc. These are your experiments to help you learn whether or not you’ve achieved whether or not the risk that you’re testing is real and whether or not you should keep working on this hypothesis and how best to solve these challenges in this hypothesis so that you solve your problem. Really the goal of this is to run this experiment. Once you’ve run this experiment, you collect that data and you try to get a sense of where you stand on your hypothesis. Does the hypothesis still make sense? Should we keep going with it? If we should, then we ask the questions again in box number 7. What’s the next most important thing we need to learn? What’s the next biggest risk? Then we ask the question box number 8, “What’s the least amount of work we need to do to learn that?” The experiments get a bit more high fidelity. We invest a bit more. We learn a bit more and we continue to invest more as long as we get good feedback from or experiments. If at any point, we get bad feedback, feedback that says, “This isn’t going to work,” then we either pivot or we kill that hypothesis and then we either go back to our list of hypotheses to see where we ended up, what’s left, what we can test or we take what we learn and we consider the canvas as a whole. What assumptions still make sense? What doesn’t make sense? What should we rewrite? Then we start the process again.
That was a very brief run through of the Lean UX Canvas. I hope you learned something. If you have any questions, please leave the questions in the comments. Please do look forward to the third edition of the Lean UX book. It will be out in the Fall of 2021 as well as the self-paced video course of Lean UX which will be out in just about a month or so on my website, on Josh Seiden’s website. You’ll see it on our Thinkific page as well.
It’s hard to believe it’s been 8 years since the first edition was published and nearly 10 years since we started writing it.