tag:blogger.com,1999:blog-21999927898621290572024-03-05T11:07:43.874-08:00Users KnowLaura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comBlogger99125tag:blogger.com,1999:blog-2199992789862129057.post-37706055815819281192015-03-05T16:07:00.002-08:002015-03-05T16:07:31.088-08:007 User Research Myths and Mistakes<div>
I wrote a post over at O'Reilly's Radar blog about a few of the myths and mistakes surrounding quantitative and qualitative research.<br />
<i><br /></i>
<i>I can’t tell you how often I hear things from engineers like, “Oh, we don’t have to do user testing. We’ve got metrics.” Of course, you can almost forgive them when the designers are busy saying things like, “Why would we A/B test this new design? We know it’s better!”</i><br />
<i><br /></i></div>
<div>
</div>
<div>
<i>In the debate over whether to use qualitative or quantitative research methods, there is plenty of wrong to go around. So, let’s look at some of the myths surrounding qualitative and quantitative research, and the most common mistakes people make when trying to use them.</i><br />
<i><br /></i>
<i><a href="http://radar.oreilly.com/2015/03/7-user-research-myths-and-mistakes.html">Read More at O'Reilly ></a></i><br />
<br />
<a href="http://www.oreilly.com/pub/e/3355?intcmp=il-webops-webcast-article-webcast_lk_qualitative_quantitative">Or sign up for the Webcast on March 11th, 2015 to learn about combining qualitative and quantitative research more effectively. </a></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-56149207611557614192015-02-11T15:10:00.000-08:002015-02-11T15:10:00.489-08:00Stop Accosting People in Coffee Shops - Use Guerrilla Research Wisely<div class="graf--p" id="0960" name="0960" style="background-color: white; margin-bottom: 30px;">
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Entrepreneurs, please stop accosting people in coffee shops.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">I know that idiots like me have been telling you about the wonders of guerrilla user research. Some of us may even have included it in our books. Apparently, we were not clear enough about when testing something in a coffee shop is a reasonable option, since many of you have decided to do this to the exclusion of absolutely everything else.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<h4 style="margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial; font-size: large;"><span style="font-weight: normal; line-height: 20.7000007629395px; white-space: pre-wrap;"><i>Stop accosting people in coffee shops. Guerrilla research can hurt your product. —<a href="http://ctt.ec/HeffG"> Tweet This</a></i></span></span></h4>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<h3 style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">What Is Guerrilla Usability Testing?</span></span></h3>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Let’s do a very quick recap. Guerrilla Research is what we call a very specific form of usability testing. It involves, at a high level, hanging out in public places and asking people to use your product in exchange for coffee.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<h4 style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">What’s It Good For?</span></span></h4>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Guerrilla Usability is a fast and cheap way of getting a certain type of feedback on one type of product.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">It can be very effective if all of the following criteria are met:</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
</div>
<ul>
<li><span style="font-family: Arial; font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">you have a consumer-oriented product that does not require any specialized knowledge to use</span></li>
<li><span style="font-family: Arial; font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">you want to know if people who have never seen your product before can understand your value proposition immediately</span></li>
<li><span style="font-family: Arial; font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">you want to know if brand new users can perform a single, very specific task using your product</span></li>
</ul>
<br />
<h4 style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">What Does It Suck At?</span></span></h4>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Everything else.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<h3 style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">But Why Can’t You Use It for…?</span></span></h3>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">The worst abuse of this research methodology is when entrepreneurs use it to determine whether people WANT to use their product. This is horrific on so many levels.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Getting 20 people at a random Starbucks to smile politely at you while you pitch them your idea does not constitute validation. People are generally polite, and most of them will nod encouragingly and agree that your product is probably fantastic in exchange for a $5 Frappuccino. Even if they didn’t lie just to get you to go away, they’d still be incapable of telling you whether or not they would use your product, since people are really bad at telling the future.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">A major problem with trying to figure out if people will love your product based on this sort of testing is that, even if your product is aimed at “everyone” (and that’s own problem, really), it’s not necessarily aimed at the people you’ll find in any given coffee shop. And even if it’s specifically for people in coffee shops, there’s no saying whether or not those people would have found or understood or used your product on their own, if you hadn’t been standing there offering it to them.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Just trust me on this. You will never find out if people like your product by talking to strangers in coffee shops. Stop it. You’re wasting your time.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial; font-size: large;"><span style="line-height: 20.7000007629395px; white-space: pre-wrap;"><i>You will never find out if people like your product by talking to strangers in coffee shops. — <a href="http://ctt.ec/e2Fvp">Tweet This</a></i></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt; text-align: center;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Also, you won’t find out if it’s usable or useful to anybody beyond the first five minutes of usage, since that’s all the time you’re likely to have. If you have a product that is only useful with repeated usage, coffee shop testing isn’t going to help you. All you get to see is the onboarding process, so if you’re ignoring other types of longer form research (diary studies, current user observations, etc.), you’re probably going to end up with a really well tested onboarding process and a really confusing product.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Finally, if your product is designed to be used by a specific type of user, or even a general consumer in a specific type of context, you’re screwed if you’re only doing guerrilla research. For example, if your product is for accountants, it’s very likely to have loads of content that wouldn’t be at all understandable to an average person on the street. That’s ok!</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Not every product needs to be perfectly understandable to every person. We don’t design airplane cockpits so that just anybody can walk in and fly a plane. It’s not a reasonable expectation. But if you’re getting feedback from non-accountants or non-pilots on your accounting software or your cockpit design, you’re going to get suggestions that will probably make the product worse for your actual users.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">The same goes for context of use. Something that might seem perfectly usable in a Starbucks with decent lighting, a good wifi connection, and a flat surface might not be that great if the product is meant to be used one-handed on a crowded bus or when sprinting through an airport or while driving a car. Context can have an enormous impact on the usability of a product.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<h3 style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">What Can You Do Instead?</span></span></h3>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">I’m not actually saying you can never use coffee shop testing. It’s a reasonable tool for a very limited set of research objectives.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">But branch out a bit. Figure out what you want to learn, and then do the work to understand the best method for learning that. As an added bonus, you’ll stop getting kicked out of all those coffee shops.</span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;"><br /></span></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial;"><span style="font-size: 15px; line-height: 20.7000007629395px; white-space: pre-wrap;">Like the post? Read the book. <a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">UX for Lean Startups</a>.</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<br /></div>
</div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-49649159546385584192015-02-11T14:54:00.002-08:002015-02-11T14:54:48.919-08:00Your Job Is Not to Write Code<br />
<div>
Dear Engineers,</div>
<div>
<br /></div>
<div>
Your job is not to write code.</div>
<div>
<br /></div>
<div>
I know. You think you were hired to write code. In fact, your entire interview process centered around how well you could write code. And I’m sure you do it really well.</div>
<div>
<br /></div>
<div>
But it’s not your job.</div>
<div>
<br /></div>
<div>
Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves the key metrics of the company. But honestly, you don’t always have a lot of control over that second bit. You do, however, have an enormous amount of control over the first bit!</div>
<div>
<br /></div>
<div>
Of course, if you want to do your job well, it does mean that you may have to change some of your current behaviors.</div>
<div>
<br /></div>
<div>
For one thing, you need to make sure that the code you write (writing code is still one of the main things you will do when doing your job, by the way) runs the way it should, even on users’ machines.</div>
<div>
<br /></div>
<div>
Did you know that our users probably don’t have brand new MacBook Airs with giant Thunderbolt monitors set at the highest resolution possible and running the latest version of Chrome? I checked. A lot of them have Internet Explorer on 4 year old laptops, so sometimes things you build don’t work right on their machines. They’re still our users, and it’s still your job to improve the product for them, so please make sure that the code you wrote works in a reasonable number of environments.</div>
<div>
<br /></div>
<div>
In fact, you’re going to need to make sure that the code you wrote runs in production, in general. I don’t really care if your code runs locally. If your code just runs locally, then my only option is to sell your computer so that our users can use our software, and that really doesn’t scale.</div>
<div>
<br /></div>
<div>
So, to avoid that, you need to check your changes in production. Every time. Remember, your job is not just to ship something. It’s to ship something that improves our product for our customers. You can’t know it will do that unless you check that it runs in the way it’s supposed to.</div>
<div>
<br /></div>
<div>
Of course, in order to check your changes in production, you’re going to need to make sure that your code actually gets merged and pushed into production. I mean, you can’t really check your changes in production if you just let them sit unpushed for hours or days. Push your code. Get it into production. Then run it and check it.</div>
<div>
<br /></div>
<div>
This is obviously harder to do if you’re in an environment where you can’t do continuous deployment, but the theory still holds. When your code gets into production, whenever that is, you’re still responsible for it. Make sure that it’s doing what it ought to be doing - which is make the product better for users.</div>
<div>
<br /></div>
<div>
Another thing to remember is that sometimes users do surprising things, which means that it’s not enough just to test that your code works under perfect conditions. You need to make sure that it does something reasonable even in error cases and zero data states and when the user does something you might not expect, like use the back button or make two accounts by mistake.</div>
<div>
<br /></div>
<div>
This is hard. It means you’ll have to spend time thinking about the different things our users might do. But it’s an important part of your job, because it will vastly improve the product for our users if they aren’t constantly finding bugs or edge cases or dead ends.</div>
<div>
<br /></div>
<div>
There’s one more important part to your job. You need to make sure that we can measure whether we’re all doing our jobs well. That means adding metrics and analytics so that we can test the effects of our changes. If you expect the code you are writing to improve user engagement (by improving the user experience in some key way), then you need to have a way to learn whether or not you succeeded. How else will you know if your job is done? Because, as I’ve mentioned, your job isn’t done until you’ve improved the product for our users.</div>
<div>
<br /></div>
<div>
I know what you’re thinking. This will all take so long! I’ll be so much less effective!</div>
<div>
<br /></div>
<div>
This isn’t true. You’ll be far more effective because you will actually be doing your job. If you get hassled for writing less code, that’s a failure of management, and I apologize for it. We need to spend less time demanding that you write features and more time asking you to improve our product for our users. If we’re not doing that, I strongly suggest you ask us to. If we still refuse, you should leave and find an environment that lets you do your job. Which, not to beat a dead horse, is to make the product better for our users.</div>
<div>
<br /></div>
<div>
Please don’t feel like I’m picking on you. You’re not the only one who should be doing this job. It is all of our jobs to make the product better for our users. It is my job as a PM and UX Designer and Manager to understand our users well enough that I can help you know how to improve the product for them. It is the CEO’s job to find a strategy that allows us to make money by improving the product for our users.</div>
<div>
<br /></div>
<div>
No matter what our job titles, our jobs are all the same — to make the product better for our users. Every day. So let’s do that.</div>
<div>
<br /></div>
<div>
Thank you,</div>
<div>
<br /></div>
<div>
Your Product Manager</div>
<div>
<br /></div>
<h3 style="text-align: center;">
<b>Dear Engineers, your job is not to write code! - <a href="http://ctt.ec/hKaMe">Tweet This</a></b></h3>
<div>
<br /></div>
<div>
*This post originally appeared on Medium*</div>
<div>
<br /></div>
<div>
<br /></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-66919313115282462502014-08-04T15:25:00.000-07:002014-08-04T15:25:41.888-07:00What Happens Next?<div>
Today I’d like to talk about why that feature you’re building has taken twice as long to build as you thought it would and why it will be hard to use once you’ve shipped it. The problem is that you didn’t really think it through before you started coding.<br />
<br /></div>
<div>
Before I jump in, I want to point out that this is not, in fact, an argument in favor of big, up front design, or an argument against Agile or Lean. Please believe that the technique I’m sharing here can very easily be used in any sort of environment.</div>
<div>
<br />
When you create an interaction for a product, you have to design more than what it looks like. You even have to design more than what happens during the interaction. You have to design what happens after the initial user interaction. And then you have to keep going.</div>
<blockquote>
<b>Design what happens after the initial interaction. Then keep going. — <a href="http://ctt.ec/rCt78">Tweet This</a></b></blockquote>
<div>
Let’s take a look at an example. Let’s imagine that you have an e-commerce product that sells children’s books. You encourage readers to post comments and ratings. It’s a new product, so everything is very bare bones. You didn’t spend a lot of time building a huge commenting system before you knew if anybody would leave comments. Instead, you just made something very simple where people can leave a comment or read a comment. Well done! That’s very Lean of you.</div>
<div>
<br />
Then one day, you have to have this conversation with your designer:<br />
<br /></div>
<div>
You: Oh my God. People are awful!</div>
<div>
<br />
Designer: Right?</div>
<div>
<br />
You: Someone posted an ad for penis enhancement on the Where the Wild Things Are page, and I didn’t see it until someone sent a customer support email. It could have been there for days.</div>
<div>
<br />
Designer: We should probably have an easier way for users to flag inappropriate content than sending us an email.</div>
<div>
<br />
You: I guess we should. Can you add flagging to the comments?</div>
<div>
<br />
Designer: Sure!</div>
<div>
<br />
A little while later, the designer claims he’s added flagging to the design and is ready for engineering to implement it. The design looks like this.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfEBL8Y3ukH_TwFREmy8tyk91SCY1Ji7RuNG58oRjlRRCwKs2Jo0fcwMetq18HKrqpG-cz1D98XT8nwkMzjooLyJNpvHBd1Cd9e2NdudmEYvlO7aEUJ-e4Z0dDoRl4PuzfJYFs5e26_FA/s1600/comments_flag.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfEBL8Y3ukH_TwFREmy8tyk91SCY1Ji7RuNG58oRjlRRCwKs2Jo0fcwMetq18HKrqpG-cz1D98XT8nwkMzjooLyJNpvHBd1Cd9e2NdudmEYvlO7aEUJ-e4Z0dDoRl4PuzfJYFs5e26_FA/s1600/comments_flag.png" height="214" title="Look! A flag!" width="320" /></a></div>
<br /></div>
<div>
“Well, that’s easy,” you think. “I’m just a few minutes away from users being able to tell me when a comment is inappropriate.”<br />
<br /></div>
<div>
Then, of course, the design goes to the engineer. And the conversation goes like this.<br />
<br /></div>
<div>
Engineer: What happens when a user clicks the flag link?<br />
<br /></div>
<div>
You: Well, the comment gets flagged.</div>
<div>
<br />
Engineer: Ok, I’ll set a flag in the database whenever a user flags a comment.</div>
<div>
<br />
Hopefully you can see where this is going. The upshot is that, when a user clicks the flag link, the database will record that fact and…well…nothing else. The user who clicked the flag link won’t get any feedback. Nobody will be notified that something was flagged. You can’t do anything with the user report about the comment.<br />
<br /></div>
<div>
In other words, nothing has been planned beyond the visual implementation and the initial user interaction. And this is all happening because you only designed the initial user interaction.<br />
<br /></div>
<div>
So, what really needs to happen for this feature to be considered usable and useful? What is the minimum set of subsequent interactions that need to be designed after the user clicks on the flag link?</div>
<div>
<br />
Probably something like this:</div>
<ul>
<li>The user who flags a comment should get a confirmation that the comment was successfully flagged and be given some sort of information about what will happen next. </li>
<li>Someone at the company should be notified in some way that a comment has been flagged. </li>
<li>Someone at the company should be able to view the flagged comment and probably the identity of the person who flagged the comment. </li>
<li>Someone at the company should be able to remove the flagged comment. </li>
<li>The person who left the flagged comment should be notified that their comment was removed.</li>
</ul>
<div>
“My God!” you say. “My little, tiny feature has ballooned into an enormous undertaking! This is feature creep!”</div>
<blockquote>
<b>What really needs to happen for a feature to be both usable and useful? — <a href="http://ctt.ec/Ad1lb">Tweet This</a></b></blockquote>
Well, no. It isn’t. You see, these are all things that would have to happen just to make the feature work at all. If you allow people to flag comments but don’t have any way for someone at your company to deal with the flagged comments, you’ve designed half a feature. Or, more to the point, you’ve designed a broken, unusable feature with a dead end.<br />
<br />
Of course, that’s just the minimum set of things that need to be designed. There are all sorts of optional pieces like letting the flagger know when the issue is resolved or letting the flagger indicate why she’s flagging the comment or letting a customer service rep know how often people have been flagged so they can decide whether to ban the person. That last one would mean that you’d need some affordance for banning users and preventing them from returning.<br />
<br />
Now, if you’re being very Lean Startup, you can always build the customer facing side first and decide not to build the admin side until people start flagging comments. In that case, when someone flagged a comment, you could simply have an engineer go into the database and remove the comment if you deemed it offensive.<br />
<br />
That absolutely counts as designing a solution to the problem, by the way. It’s just a very manual design, and it’s probably one that won’t scale very well.<br />
<br />
<h3>
Why Should You Bother? </h3>
<div>
<div>
Now you’re probably thinking that this all sounds exhausting and wondering why you would bother thinking through all of this stuff. That’s understandable. It can be exhausting. Do it anyway.</div>
<div>
<br /></div>
<div>
You see, thinking through the entire flow of interactions after the first one has a huge benefit to both your product and your product development process.</div>
<div>
<br /></div>
<div>
It helps your product by making sure you don’t have a lot of dead ends and awkward experiences. You don’t, for example, have a flagging feature that doesn’t result in flagged comments being pulled from your pages. This goes a long way toward making your overall user experience about a thousand percent better than the majority of products I use on a daily basis.</div>
<div>
<br /></div>
<div>
This process also improves your product development by helping you to understand the true complexity of a feature before you build it. You will never know exactly how long something will take to build, but you can certainly tell that building a flagging feature that works will take a lot longer than just putting a flag icon on each comment.</div>
<div>
<br /></div>
<div>
By fully exploring the complexity of features, you are better prepared to prioritize your backlog.</div>
</div>
<div>
<br /></div>
<h3>
So, How Do You Do It? </h3>
<div>
<div>
It’s pretty simple. Instead of thinking of your feature, think of the end user’s intent. Then, every time there’s some sort of interaction, you need to ask yourself, “has the user’s intent been satisfied?” If not, you’re not done, so you need to ask yourself, “What next?”</div>
<div>
<br /></div>
<div>
For example, your user isn’t going to flag something because she just loves flags. She’s going to flag something because she wants an offensive comment removed from a product page. Let’s go through the interaction sequence until that intent has been satisfied.</div>
<div>
<br /></div>
<div>
<ol>
<li>A user can click the flag icon. Does this result in the comment being removed? No? Ok, what next?</li>
<li>An email gets sent to someone at the company. Does this result in the comment being removed? No? Ok, what next?</li>
<li>The person at the company asks an engineer to remove the comment from the database (which the engineer has agreed to do). Does this result in the comment being removed? Yes? Great! You’re done (for now).</li>
</ol>
Just keep asking yourself what’s next until the user’s intent has been met. It’s the best way to guarantee that your features do what you think they do and what your users expect them to do.</div>
<div>
<br /></div>
<div>
Like the post? <a href="http://twitter.com/lauraklein">Follow me on Twitter. </a></div>
<div>
<br /></div>
<div>
Also, check out the book for more product and UX tips — <a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">UX for Lean Startups</a>.</div>
</div>
<div>
<br /></div>
<br />Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-10701116104705412212014-04-09T13:25:00.000-07:002014-04-09T13:25:14.564-07:00Want Better UX? Change the Conversation.If you’ve ever been a user experience designer, you’ve probably heard people say something like this when starting a new project:<br />
<ul>
<li>We want to make it delightful and easy to use.</li>
<li>We need to do some user research.</li>
<li>We want to improve our onboarding process.</li>
<li>We think it needs a walkthrough for new users.</li>
<li>We want a persona/photoshop mockup/wireframe/landing page/insert deliverable here.</li>
</ul>
All of these statements are absolutely useless. Why? Because none of them help you decide what to work on or how to improve a product.<br />
<br />
So, the next time somebody introduces a UX project by asking for a specific deliverable or by giving vague instructions to “make it better,” you need to change the conversation.<br />
<br />
You can do that by asking the following questions:<br />
<ul>
<li>Who is the target user for this product or feature?</li>
<li>What problem are you trying to solve for those users?</li>
<li>What business need are you trying to fulfill with this project?</li>
<li>What metric are you trying to move?</li>
<li>Why do you think that solving this particular user problem will move that metric?</li>
</ul>
<blockquote class="tr_bq">
<i>I know you want it to be delightful. But what metric does it move? — <a href="http://ctt.ec/LfOMe"><b>Tweet This</b></a></i></blockquote>
<h2>
How Do These Questions Help Users?</h2>
The most important thing about these questions is that they help you define three things that are critical to a successful design project:<br />
<ol>
<li>The problem you are trying to solve</li>
<li>The reason you are trying to solve it</li>
<li>The way you will know if you’ve succeeded</li>
</ol>
<blockquote class="tr_bq">
<i>Of course you want a better design. How will you know if you’ve succeeded? — <b><a href="http://ctt.ec/cct9Y">Tweet This</a></b></i></blockquote>
Design without these elements isn’t really user experience design. It’s just drawing pictures. Design is about solving real problems, both for users and for the business. In fact, at its best, design is about solving problems for the business (for example, generating revenue or improving retention) by solving problems for the user (for example, offering something somebody wants to buy or helping make their lives better).<br />
<blockquote class="tr_bq">
<i>Design should solve problems for your business by solving problems for your user. — <b><a href="http://ctt.ec/C90U6">Tweet This</a> </b></i></blockquote>
By knowing the answer to these questions, you are far more likely to build a product that users want to use and that improves key metrics for your company.
<br />
<h2>
How Do These Questions Help Designers?</h2>
Answering these questions can be incredibly helpful for individual designers. When we ask these questions, we reframe the project to give the designer far more freedom to solve problems, which is, after all, the fun part of the job.
<br />
<br />
Instead of being told “change the onboarding flow” or “create a tutorial walkthrough,” we get asked to “improve the 10 day activation metric for new users.”
<br />
<br />
As designers, we get to create our own hypotheses about how we will improve that metric rather than simply implementing someone else’s vision.<br />
<br />
More importantly, we can understand when our designs were successful, because we have a specific metric against which we can measure our results. This kind of direct feedback can make us better designers.<br />
<h2>
How Do These Questions Help Engineers?</h2>
These questions can be incredibly useful for defining the scope of a project, which has a very real impact on engineering. For example, poorly defined projects are particularly susceptible to scope creep.<br />
<br />
After all, if you don’t have a very solid idea of the problem you’re trying to solve or the metric you’re trying to move, it’s very easy to justify adding “just one more thing.” But when you have a clearly defined problem, it’s easy to push back on new feature requests that don’t contribute directly to solving that problem.<br />
<h2>
What to Do If They Can’t Answer Those Questions</h2>
The first few times you try to change the conversation, you may get push back. You’ll get clients or product managers or engineers who simply can’t answer these questions. Keep asking them.<br />
<br />
If people can’t answer the questions, you need to help them get the answers before you start work on the project. Otherwise, you’re shortchanging your users, your company, your team, and yourself.<br />
<br />
Like the post? <a href="http://twitter.com/lauraklein">Follow me on Twitter! </a>Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-89696390143709286232014-03-18T13:46:00.000-07:002014-03-18T13:46:11.160-07:00The Most Important User You're Not Talking To<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Do you have a product? With users? </span><br />
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">If you answered “yes” to both of those questions, you have an amazing untapped source for product research. And I’m not talking about your users. </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">I mean, sure, you should be listening to users and observing them. A lot. But there’s another group of people who can provide you with incredible insights into your product. </span><br />
<i style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></i>
<i style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">You should be talking to people who used your product once and then abandoned it. </i><b style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><a href="http://ctt.ec/YJ02m">Tweet This!</a></b><br />
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">Specifically, you need to ask these people the following questions:</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
</div>
<ul>
<li><span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">What were you expecting when you tried this product?</span></li>
<li><span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">How did it not meet your expectations? </span></li>
</ul>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">This research will help you understand three things very clearly:</span><br /><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
</div>
<ul>
<li><span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">What your messaging and acquisition strategy is telling people to expect.</span></li>
<li><span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">What problem the people you are acquiring are trying to solve. </span></li>
<li><span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">Why your product doesn’t solve this problem for the people you are acquiring. </span></li>
</ul>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">You’ll notice that I mentioned “acquisition” in each of the above points. This is intentional. You see, one of the things you are very likely to find out from this sort of research is that you are getting entirely the wrong group of people to try out your product. </span><div>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span></div>
<div>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">If you’ve been spending a lot of time optimizing your ads and your messaging for sign up conversion rather than for actual product usage and retention, it may turn out that you are acquiring a whole lot of the wrong sort of user for your product, which can be a costly mistake. This kind of research is fabulous for understanding if that’s true. </span></div>
<div>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span></div>
<div>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">The other thing that this research helps with is understanding whether or not you’re adequately solving the problem you think you’re solving in a way that users can understand. If new users can’t figure it out what your product does and how to do it in a few seconds, they’ll leave without ever knowing that your product was the solution to their problem. </span></div>
<div>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span></div>
<div>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">Of course, this isn’t the easiest group of people to interview. These folks can be tricky to track down and tough to schedule. But finding a way to interview people who thought they wanted to use your product and then changed their minds is something that will pay off hugely in the long run. </span></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-70629597912680545332014-03-03T16:37:00.001-08:002014-03-03T16:40:12.484-08:00Making More UX Designers<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Over the last few years, I’ve had an increasing number of people ask the same two questions. Specifically I get asked: </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><b>Where can I find a good UX designer?</b></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><b>How can I get into UX?</b></span><br />
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">The best possible solution is, of course, to teach the people in the second group how to do the job and then introduce them to the people in the first group. The second best solution is to teach the people in the first group to do it for themselves. I’ve been experimenting lately with both of these approaches. </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">This need for creating more UX designers is one of the biggest reasons I joined </span><a href="http://tradecrafted.com/" style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">Tradecraft</a><span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"> as an instructor at the beginning of the year. My co-teacher, the amazing Kate Rutter, and I each spend 3 days a week working with smart, motivated, tech-savvy students, teaching them UX design fundamentals like user research, task flows, personas, wireframing, and prototyping. Most importantly, we teach them to think like UX designers. </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">Because it’s an intensive 12 week program, students have time to learn UX skills and apply them on real projects for real companies. They also learn from frequent guest mentors and speakers. </span><br />
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">It’s a competitive program. We don’t take many students. We’re not interested in churning out a lot of mediocre designers. We want to take a few people each quarter and turn them into great designers whom we’d be happy to recommend for jobs. We prefer people who have experience in some area of design, product management, user research, or engineering. </span><br />
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;"><br /></span>
<span style="font-family: Arial; font-size: 15px; line-height: 1.15; white-space: pre-wrap;">So, if you’re someone who desperately wants to become a UX designer, and you want hands-on coaching from a couple of people who’ve been doing this for quite a few years, you should apply to <a href="http://tradecrafted.com/">Tradecraft</a> for the next quarter. Or, if you’re a manager at a larger company, and you have a promising UX designer or Product Manager who needs some serious coaching to get to the next level, you should consider sponsoring that employee in the program. Lastly, if you’re looking for a newly minted UX designer, we’ve got a few of those graduating at the end of March. </span><br />
<span style="color: black; font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span>
<span style="color: black; font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">And if you want more information about any of it, you should email me at </span><a href="mailto:laura@usersknow.com" style="line-height: 1.15;"><span style="color: #1155cc; font-family: Arial; font-size: 15px; text-decoration: underline; vertical-align: baseline; white-space: pre-wrap;">laura@usersknow.com</span></a><span style="color: black; font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"> and ask.
</span><span style="font-family: Arial; font-size: 15px; white-space: pre-wrap;"><br /></span><br />
<span style="font-family: Arial; font-size: 15px; white-space: pre-wrap;">By the way, <a href="http://tradecrafted.com/">Tradecraft</a> also has programs for people who want to be Growth Hackers and Sales People. </span><br />
<span style="font-family: Arial; font-size: 15px; white-space: pre-wrap;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://tradecrafted.com/"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqEeuXOXv-15rjYcIFcusrW8Cqpe6NP_OpJp4L_viEt2OOemKKIdGAe6SmtO4BawxBSHqf4Cw5WmeG0_O_0ve-VPHX0veN9R36wqTdx2ZgYn1PIjnvr8GHA-ul2GH9o1EkU3H6-4wC6ww/s1600/logo.png" /></a></div>
<span style="font-family: Arial; font-size: 15px; white-space: pre-wrap;"><br /></span></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-73687279007385462722014-02-07T11:54:00.002-08:002014-02-07T11:54:40.262-08:00Building the Right Thing vs Building the Thing Right<i>This originally appeared as a guest post on the O'Reilly Programming Blog.</i><br />
<br />
I love it when companies test prototypes. Love love love it. But it makes me incredibly sad when they use prototype testing for the wrong thing.<br />
<br />
First, let me give you my definition of “prototype testing” here. I often build interactive, or semi-interactive, prototypes when designing a product. These prototypes are not actual products. They’re simulations of products. People who see the prototype can often click around them and perform some simple tasks, but they’re generally not hooked up to a real back end system.<br />
<br />
“Well, what good is that?” you might reasonably ask. Excellent question. Interactive prototypes are incredibly useful for finding problems in usability testing settings. In a checkout flow, you might create a simple interactive prototype and watch four or five people go through the process (with test accounts) in order to find out if there were any parts of the flow they found confusing or hard to use.<br />
<br />
It’s a great technique for any reasonably complicated interaction that you want to test before you spend a lot of time writing code. Interactive prototype testing can save you a ton of time because it helps you make sure that you’re building the product right before you spend a lot of time and money actually writing code. <br />
<br />
<a href="http://programming.oreilly.com/2014/02/building-the-right-thing-vs-building-the-thing-right.html">Read the rest of this post on the O'Reilly blog ></a><br />
<br />Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-52267789713181191482014-01-21T15:14:00.001-08:002014-01-21T15:14:16.661-08:00Lean UX VideosRecently, I've been experimenting with new ways of delivering information about UX for Lean Startups. Yes, this is a very poor excuse for not blogging as much. But it's also a genuine effort to get information about user experience design to new people.<br />
<br />
As part of this effort, I'm making a series of short (10 minutes or so) videos for UXD for Developers. This is a show on YouTube produced by the folks at the Android Developer Network at Google.<br />
<br />
Two of my videos are already posted, and at least one more is on the way. A list of all the videos (including some that I'm not in) is here: <a href="http://bit.ly/uxdplaylist">UXD for Developers</a>.<br />
<br />
In my episodes, I cover an <a href="http://www.youtube.com/watch?v=7NkMm5WefBA&list=PLWz5rJ2EKKc-riD21lnOjVYBqSkNII3_k&index=2">Intro to Lean UX</a> and <a href="http://www.youtube.com/watch?v=5SNSA6pmzjM&list=PLWz5rJ2EKKc-riD21lnOjVYBqSkNII3_k&index=4">Qualitative vs. Quantitative Research for UX</a>.<br />
<br />
New episodes are released every Tuesday, so make sure to subscribe to the channel to get all the updates!<br />
<br />
<br />Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-70185591321333430392013-10-25T13:03:00.003-07:002013-10-25T13:03:50.094-07:00How Bad Can I Make My Product?Imagine that I have a product that cures cancer. Sadly, the side effect is that you may lose a few toes. I’ll bet that I would still have a huge line of customers who want to use my product.<br />
<br />
Now, instead of curing cancer, imagine that the product tells you where you should eat lunch. Unfortunately, the toe-loss thing still applies. I’m going to go out on a limb and say that I’ll probably have far fewer customers.<br />
<br />
This seems obvious. Sacrificing a toe or three doesn’t seem like a big deal when weighed against your life, but it’s a different story when it’s just lunch. Even a really good lunch.<br />
<br />
If you are asking your users to put up with a lot of pain, you need to do so in the context of giving them something extraordinary. I get asked all the time how to tell when something is good enough. Does it have enough features? Is the visual design pretty? What if it has a couple of bugs? The answer to all of these questions is that it depends on whether the users are getting enough in return.<br />
<br />
Every startup has a slightly different calculus for deciding what product to put out into the world, but I’m going to give you a piece of advice that will make this all a little easier: if you’re solving a really big problem that nobody else is solving, your early adopters will be quite tolerant.<br />
<br />
This is one of the reasons why B2B applications often get away with being so awful and hard to use. If a product helps me do my job better and makes me more money, it’s solving a big problem for me. I’ll put up with a few missing features or a less than stellar experience. (There are lots of other reasons B2B applications are terrible, of course, but that’s not what this blog post is about.)<br />
<br />
Of course, there is a minimum standard for anything you put out in the world. People have to understand what it does, for example, and be able to use it to solve their really serious problem. In other words, it needs to be both usable and useful. But the more useful it is, the more of a pass you get on a lot of the nice-to-haves.<br />
<br />
To be clear, this is not a pass to make your product awful. Think of this as an encouragement to build something important that solves serious problems for people and to get it into their hands as quickly as possible.<br />
<br />
Like the post? <a href="http://twitter.com/lauraklein">Follow me on Twitter!</a><br />
<br />
Like the post but wish there were more of it? <a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Buy the book!</a>Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-15904949270056846172013-10-14T10:24:00.002-07:002014-03-24T20:38:45.662-07:00Stop Making Users ExploreOften, entrepreneurs ask me something to the effect of, “What’s the best way to let new users explore my product?”<br />
<br />
My answer is almost always a variation of, “Stop it.” In order to be slightly more helpful, let’s look at why this is a terrible question.<br />
<br />
<h3>
Users Don’t Care About Exploring Your Product</h3>
Nobody cares about your product. Fundamentally, what users care about is themselves. They are using your product as a means to an end. We knew this back in 1960 when Theodore Levitt explained that when customers buy quarter inch drills, they really are buying quarter inch holes.<br />
<br />
Think about the last time you bought a drill. Did you sit down with the drill in order to spend time exploring it? Not unless you’re some sort of drill fetishist. What you almost certainly did was try to figure out the fastest way that you could set about completing the project for which you had bought the drill.<br />
<br />
The same is true of whatever product you’re building. I know that you care deeply about the user interface of your product and all of the delightful features you have so lovingly handcrafted. Sadly, nobody else does. At least, not in the same way that you do.<br />
<br />
People want whatever your product promises to do for them, and they want it to happen as quickly and easily as possible. They don’t want to explore your tax preparation software. They want their taxes done. They don’t want to delve deeply into the mysteries of your To Do List software. They want to not miss deadlines.<br />
<br />
<h3>
But What About B2B Products?</h3>
I know, I know. B2B products are different! They’re more complex! They have so many features! They require training and exploration!<br />
<br />
Nonsense.<br />
<br />
All of those incredibly complicated, feature-dense pieces of B2B software that require weeks of training are getting disrupted by things that humans actually understand. I worked with a company that required all documents be shared by filing a ticket with IT to create a personal folder on a shared server which then required mounting a new drive onto the desktop and...blah blah blah. Everybody just used Dropbox, even though it was officially forbidden by the company.<br />
<br />
The fact is, people in big companies are forced to work with dozens of complicated products every single day. The introduction of a new, complicated product does not instill in them the desire to spend a lot of their day exploring it. It tends to make them sigh resignedly and figure out if there is some way to avoid learning the new system until it goes away and is replaced by something else.<br />
<br />
The only way to make a product that people at work want to use is to make a product that is so obvious and easy to operate that they don’t feel like they have to explore it. They can just jump in, share a document, send an email, or do whatever task it is that they wanted to do originally. They shouldn’t have to explore anything to do their jobs.<br />
<br />
<h3>
But...but...but...Games!</h3>
Nope. Sorry. Still very little open exploration for new users.<br />
<br />
I mean, sure, you can wander all over GTAV and steal as many cars as you want. But have you ever noticed how many quests and tasks and hints you’re given along the way as a new player? Actually, you probably haven’t. Really successful games are fabulous at getting you onboarded without making you feel like you’re going through a tedious training session but also without just dumping you directly into the deep end.<br />
<br />
In fact, in good games, the real exploration doesn’t come until users are pretty comfortable with all the basic actions they need to be successful. Often, advanced features are hidden from users until they are unlocked. This not only provides the user with an incentive to keep playing, but it effectively hides complexity until the user is ready for it.<br />
<br />
Think about hiding a rocket launcher from a new FPS player. Now think about hiding quarterly estimates from a tax preparer until you know that she needs to file quarterly estimates. There’s a surprising similarity. Note: hiding rocket launchers from people doing their taxes is also not a terrible idea.<br />
<br />
<h3>
E-Commerce?</h3>
Again, not really. While online stores do encourage you to explore and browse, you’ll notice that they don’t have you exploring and browsing the store itself. They have you exploring and browsing the products they want you to buy.<br />
<br />
When you’re selling widgets, it’s all about showing off the widgets as quickly as possible. Even while you’re looking at a widget, the site or app is immediately offering you more widgets that you might be interested in.<br />
<br />
It’s not about exploration of the product itself. It’s about getting you involved with the things the product is selling.<br />
<br />
<h3>
What Should You Do Instead?</h3>
Stop thinking about letting users explore your product. In fact, stop thinking about letting them do anything at all.<br />
<br />
When a new user comes to your product, give them a task. Have them do the most obvious, low-friction thing that they will need to do in order to become a slightly more experienced user of the product.<br />
<br />
Twitter is an excellent example. When you first join, they don’t just tell you to explore Twitter. They have you immediately start following people. This not only introduces you to the concept of following people, but it gives you a nice, low-friction way to start using the product in the manner it’s meant to be used.<br />
<br />
Of course, figuring out what that most obvious first task is can be tricky. In order to do it well, you need to truly understand why your user might want to use your product. What problem are they trying to solve? What task do they want to accomplish? How do they want to change their lives? What sort of hole are they trying to drill?<br />
<br />
Once you understand that, you’ll know how to create an onboarding experience that won’t force people to explore your product before using it. In fact, they’ll never have to explore it. They’ll just be able to accomplish their task and get on with their now-improved lives. And that, after all, is exactly why they wanted to use your product in the first place.<br />
<br />
Like the post? <a href="http://twitter.com/lauraklein" target="_blank">Follow me on Twitter!</a><br />
<div>
<br /></div>
<div>
Want more advice like this? </div>
<div>
<br /></div>
<div class="separator" style="clear: both; float: left; padding-right: 10px;">
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYhEpDD_fa-yHPgDa3SdQLqIuwkxem7L4A2vpJkNOv-YW_lvDwLuZ3vGMozbTfmKKvEI6wX5PbngE0Vgs4V22dpQl9vVBE2V9lrMw-q8SmBh85jyFiv4DEzEFupm5GgmVDetHY1uLmnV8/s1600/book.jpg" /></a><span id="goog_1459121833"></span><span id="goog_1459121834"></span><a href="http://www.blogger.com/"></a></div>
<div>
<br /></div>
<div>
How about buying the book? It will help you learn how to build great products. I promise. </div>
<div>
<br /></div>
<div>
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Buy It Now</a></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-90250534608504762102013-09-04T10:19:00.001-07:002013-09-04T10:19:39.066-07:00The Best Way(s) to Learn Lean User ResearchI've been excited to see more and more people getting interested in user research and customer development over the past few years. It's not a new field by any means, but it's new to a lot of entrepreneurs and founders.<br />
<br />
Of course, what that means is that when I talk about research, I hear a lot of the same questions over and over again. I hear questions about recruiting the right users, the right number of people to talk to, and what questions to ask. I also hear a lot of confusion about how to choose the right type of research and when to use qualitative versus quantitative methods.<br />
<br />
Now, there is a lot of great information out there about how to do research. There are blogs and books and classes. But often these are more than entrepreneurs really need. They don't want to become user researchers. They want to learn exactly the techniques that they need to do whatever they need to do right now.<br />
<br />
The first third of my book, <a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">UX for Lean Startups</a>, is aimed at getting people comfortable with the idea of validating hypotheses and figuring out what sort of research to do. But I've found that often people need a little more help. They need specific guides for running each different type of study. <br />
<br />
So, that's what I'm working on now, and I hope to have some guides available in the next couple of months. These guides will be fairly detailed how-tos for things like running a usability test, recruiting users, conducting observational testing, and other topics that I get asked about constantly.<br />
<br />
If you would like to sign up to be the first to hear when these guides are available for purchase, <a href="http://usersknow.blogspot.com/p/blog-page.html" target="_blank">go here and sign up</a>.<br />
<br />
If you would like to tell me what guide you'd most like to see or what question you'd most like answered, send me email at <a href="mailto:laura@usersknow.com">laura@usersknow.com</a>.<br />
<br />
If you'd like something to read in the meantime, did I mention I'd written a <a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911" target="_blank">book</a>?<br />
<br />
If you don't like all this reading and would prefer to learn in workshop format, I will be doing some video workshops for LUXr. You should <a href="http://luxr.co/" target="_blank">sign up here</a>.<br />
<br />
And if you still have questions, you can <a href="https://clarity.fm/lauraklein" target="_blank">reach me on Clarity</a> for a quick call or sometimes hire me to consult, depending on my availability.<br />
<br />
You know what this means, right? It means that pretty soon you will have absolutely no excuse for not learning from your users.Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-7429815608339434252013-09-03T13:46:00.002-07:002013-09-03T13:47:50.378-07:00Don't Allow Behaviors. Encourage Them!<div>
I wrote this post for the O'Reilly Programming Blog. Here's an excerpt:<br />
<br />
<i>As a consultant, I’ve talked to a lot of startups who have “social” products. You could tell that the products were “social” because they had comment sections and sharing icons that let people post to Pinterest or Facebook.</i><br />
<i><br /></i></div>
<div>
<i>Of course, one of the things that the founders complain about is that too few users are actually making comments or sharing or doing anything remotely social with the product.
</i><br />
<i><br /></i></div>
<div>
<i>There’s a very simple reason for this: the founders have added features to their product that allow users to be social rather than encouraging them to be social.</i><br />
<br />
<a href="http://programming.oreilly.com/2013/09/dont-allow-behaviors-encourage-them.html" target="_blank">Read More at O'Reilly > </a></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-20732060429697311842013-08-05T06:00:00.000-07:002013-08-05T14:42:27.418-07:00Maybe You're Just Delusional<div>
I tell people to listen to their customers a lot. It’s kind of my thing. Every so often when I’m explaining how to learn about customer problems and incorporate that feedback into a product, I run into a founder who is truly resistant. <br />
<br /></div>
<div>
“But...my VISION!” they cry. Then they go on to build exactly the product that they want to build without getting feedback from users. And once in awhile this works out, I’m told. But typically I never hear about them, or their products, again. <br />
<br /></div>
<div>
The sad thing is that vision and customer feedback don’t have to be at odds. <br />
<br /></div>
<div>
I’m going to give you two different visions that a startup founder might have, and I’d like you to try to spot the differences between the two.<br />
<br /></div>
<h3>
Vision #1</h3>
<div>
“Pet owners are upset about how much their pets cost. This product is going to make it more affordable to have a pet by getting jobs for the pets so that the pets are bringing in money! It’s called Jobs4Pets, and people will be able to post jobs for dogs, cats, rabbits, whatever. And other people will find jobs for their pets and apply right on the site. We’ll make money by charging a service fee on each of the transactions! Obviously, we’re mobile first, and the jobs will be shown in a Pinterest style layout because that’s the best possible layout for things.”<br />
<br /></div>
<h3>
Vision #2</h3>
<div>
“Some pet owners are upset about how much their pets cost. This product is going to make it more affordable to have a pet.”<br />
<br /></div>
<div>
See the difference? I mean, besides the fact that the first one is completely delusional? <br />
<br /></div>
<div>
In the first one, the deranged...I mean visionary...founder has a vision not just for the goal of the company, but for every detail of the actual product. She’s not just envisioning what the product will help people do. She’s envisioning exactly how the product will help people do that, right down to the layout on the home page. <br />
<br /></div>
<div>
She hasn’t left room to validate the many assumptions she’s making - that pet owners have a problem with costs, that pets can do jobs, that people will post jobs for pets, that people want their pets to have jobs, etc. If any of those assumptions are invalid, by the way, the entire product will fail, and even her lovely, Pinterest-style layout can’t help her. <br />
<br /></div>
<div>
But the most important thing to note is that the second vision is entirely compatible with user research. </div>
<div>
<br />
The founder with the second vision might want to go out and meet lots of pet owners in order to find out how big of a problem cost is for them. She might learn the ways that people are already saving money. She might ask which parts of pet ownership cost the most or are the most burdensome. She might test several different solutions for saving pet owners money and see which one gets the most interest or traction. She might even end up with an entirely different product than she originally imagined, all without sacrificing her vision!<br />
<br /></div>
<div>
So, how can you balance customer feedback with vision? Try to envision how your product is going to change somebody’s life, not how they’re going to perform specific tasks. Envision the problem that you’re solving, not the specific solution. <br />
<br /></div>
<div>
Then listen to your users. Observe them. Learn from them exactly how you can solve their problem. <br />
<br /></div>
<div>
That’s the best way to make sure that your vision becomes a reality. <br />
<br />
<b>This was written for <a href="http://bit.ly/13Zuuos" target="_blank">Startup Edition</a>. The question was, "How do you balance user feedback with your long term vision?"</b><br />
<br /></div>
<h4>
<b>Want more information like this? </b></h4>
<div class="separator" style="clear: both; float: left; padding-right: 10px;">
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYhEpDD_fa-yHPgDa3SdQLqIuwkxem7L4A2vpJkNOv-YW_lvDwLuZ3vGMozbTfmKKvEI6wX5PbngE0Vgs4V22dpQl9vVBE2V9lrMw-q8SmBh85jyFiv4DEzEFupm5GgmVDetHY1uLmnV8/s1600/book.jpg" /></a><span id="goog_1459121833"></span><span id="goog_1459121834"></span><a href="http://www.blogger.com/"></a></div>
<div>
<br /></div>
<div>
My new book, UX for Lean Startups, will help you learn how to do better qualitative and quantitative research. It also includes tons of tips and tricks for better, faster design. </div>
<div>
<br /></div>
<div>
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Buy It Now</a></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-47353879212876027122013-06-19T17:33:00.003-07:002013-06-19T17:33:45.635-07:00Mobile First? Not So Fast! The Importance of Flow and Context. I recently wrote a post for the O'Reilly Programming Blog called "Mobile First? Not So Fast!<br />
Why "flow" and "context" are more important than screen size."<br />
<br />
Here's an excerpt:<br />
<br />
<i>Are we done with the Mobile First meme, yet? Can we be? Please?</i><br />
<i><br />Look, don’t get me wrong. I fundamentally agree with a lot of the thoughts behind the annoying catchphrase “mobile first.” For example, I agree that mobile devices are now the primary (if not only) mode of connecting for many markets. I also think that having some sort of mobile strategy is absolutely required for almost every product.</i><br />
<i><br />The problem is that “mobile first” often equates “mobile” with “small screen” or “responsive layout” or “native vs. mobile web.” Now, those are all incredibly important decisions. But if you’re thinking about the size of your screen or the technology you’re going to use first, you are designing wrong.</i><br />
<i><br />Of course, if you’ve read anything else I’ve ever written, you know that the first thing you must figure out is an important customer problem or need that your product is aimed at solving for real people. We’re going to just skip over that whole part where you get to know your most important users. But that’s always first. Promise.</i><br />
<i><br />Once you’ve done all that though, you need to start designing. And there are two things that you should always know before you even start considering things like screen size or technology.</i><br />
<i><br />Those two things are: <span style="background-color: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">Flow</span> and <span style="background-color: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">Context</span>.</i><br />
<br />
<a href="http://programming.oreilly.com/2013/06/mobile-first-not-so-fast.html" target="_blank">Read the rest at the O'Reilly Programming Blog ></a><br />
<br />
<h4>
<b>Want more information like this? </b></h4>
<div class="separator" style="clear: both; float: left; padding-right: 10px;">
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYhEpDD_fa-yHPgDa3SdQLqIuwkxem7L4A2vpJkNOv-YW_lvDwLuZ3vGMozbTfmKKvEI6wX5PbngE0Vgs4V22dpQl9vVBE2V9lrMw-q8SmBh85jyFiv4DEzEFupm5GgmVDetHY1uLmnV8/s1600/book.jpg" /></a><span id="goog_1459121833"></span><span id="goog_1459121834"></span><a href="http://www.blogger.com/"></a></div>
<div>
<br /></div>
<div>
My new book, UX for Lean Startups, will help you learn how to do better qualitative and quantitative research. It also includes tons of tips and tricks for better, faster design. </div>
<div>
<br /></div>
<div>
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Buy It Now</a></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-10032061600214767542013-04-24T11:51:00.000-07:002013-04-24T11:56:58.073-07:00You Can't Make Good Decisions with Bad DataI think a critical lesson of the Lean Startup movement is that you have to learn quickly. <br />
<br />
The “quickly” part of that lesson can lead to a culture of “good enough.” Your features should be good enough to attract some early adopters. Your design should be good enough to be usable. Your code should be good enough to make your product functional. <br />
<br />
While this might drive a lot of perfectionists nuts, I’m all for it. Good enough means that you can spend your time perfecting and polishing only the parts of your product that people care about, and that means a much better eventual experience for your users. It may also mean that you stay in business long enough to deliver that experience. <br />
<br />
I think though that there’s one part of your product where the standard for “good enough” is a whole lot higher: Data. Data are different.<br />
<br />
<h3>
You Can’t Make Good Decisions With Bad Data</h3>
The most important reason to do good research is that it can keep you from destroying your startup. I’m not being hyperbolic here. Bad data can ruin your product.<br />
<br />
Imagine for a moment an a/b testing system that randomly returned the wrong test winner 30% of the time. It would be tough to make decisions based on that information, wouldn’t it? How would you know if you were choosing the right experiment branch?<br />
<br />
Qualitative research can be just as bad. I can’t tell you how many founders have spent time and money talking to potential customers and then wondered why nobody used their product. Nine times out of ten, they were talking to the wrong people, asking the wrong questions, or using terrible interview techniques. <br />
<br />
I had one person tell me, “bad data are better than no data,” but I strongly disagree here. After all, if I know I don’t have any data, I can go do some research and learn something. <br />
<br />
But if I have some bad data, I think I already know the answers. Confirmation bias will make it even harder for me to unlearn that bad information. I’m going to stop looking and start acting on that information, and that may influence all of my product decisions. <br />
<br />
If I “know” that all of my users are left handed, I can spend an awful lot of time building and throwing out features for left handed people before realizing that what I got wrong was the original premise. And, of course, that problem is made even worse if I’m not getting good information about how the features are actually performing.<br />
<br />
<h3>
You Have To Keep Doing It</h3>
Unlike any given feature or piece of code, collecting data is guaranteed to be part of your process for the life of your startup. <br />
<br />
One of the best arguments for building minimum viable products and features is that you might just throw them out once you’ve learned something from them (like that nobody wants what you built). <br />
<br />
This isn’t true of collecting data. Obviously you may change the way you collect data or the types of data you collect, but you’re going to keep doing it, because there’s simply no other way to make informed decisions. <br />
<br />
Because this is something that you know is absolutely vital to your company, it’s worth getting it right early.<br />
<br />
<h3>
Data Collection Is Not a Mystery</h3>
Most of your product development is going to be a mystery. That’s the nature of startups. <br />
<br />
You’ve got a new product in a new market, possibly with new technology. You have to do a lot of digging in order to figure out what you should be building. There’s no guide book telling you exactly what features your revolutionary new product should have. <br />
<br />
That’s not true of gathering data. There is a ton of useful, pertinent information about the right way to do both qualitative and quantitative research. There are workshops and courses you can take on how to not screw up user interviews. There are coaches you can hire to get you trained in gathering all sorts of data. There are tools you can drop in to help you do a/b testing and funnel tracking. There are blogs you can read written by people who have already made mistakes so that you don’t have to make the same ones. There is a book called <a href="http://www.amazon.com/Lean-Analytics-Better-Startup-Faster/dp/1449335675" target="_blank">Lean Analytics</a> that pretty much lays it out for you.<br />
<br />
You don’t have to take advantage of all of these things, but you also don’t have to start from scratch. Taking a little time to learn about the tools and methods already available to you gives you a huge head start.<br />
<br />
<h3>
Good Data Take Less Time Than Bad Data</h3>
Here’s the good news: good data actually take less time to collect than bad data. Sure, you may have to do a little bit of upfront research on the right tools and methods, but once you’ve got those down, you’re going to move a hell of a lot faster. <br />
<br />
For example, customer development interviews go much more quickly when you’re asking the right questions of the right people. You don’t have to talk to nearly as many users when you know how to not lead them and to interpret their answers well. Observational and usability research becomes much simpler when you know what you’re looking for. <br />
<br />
The same is true for quantitative data collection. Your a/b tests won’t seem nearly so random when you’re sure that the information in the system is correct. You won’t have to spend time as much time figuring out what’s going on with your experiments if you trust your graphs.<br />
<br />
<h3>
Good Data Does Not Mean Complete Data</h3>
I do want to make one thing perfectly clear: the quest for good data should be more about avoiding bad data than it is about making sure you have every scrap of information available. <br />
<br />
If you don’t have all the data, and you know you don’t have all the data, that’s fine. You can always go out and do more research and testing later. You just don’t want to put yourself into the situation where you have to unlearn things later. <br />
<br />
You don’t have to have all the answers. You just have to make sure you don’t have any wrong answers. And you do that by setting the bar for “good enough” pretty damn high on your data collection skills.
<br />
<br />
<br />
<b>Like the post?</b> <a href="http://clicktotweet.com/n94Q4" target="_blank">Please share it!</a><br />
<br />
<h4>
<b>Want more information like this? </b></h4>
<div class="separator" style="clear: both; float: left; padding-right: 10px;">
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYhEpDD_fa-yHPgDa3SdQLqIuwkxem7L4A2vpJkNOv-YW_lvDwLuZ3vGMozbTfmKKvEI6wX5PbngE0Vgs4V22dpQl9vVBE2V9lrMw-q8SmBh85jyFiv4DEzEFupm5GgmVDetHY1uLmnV8/s1600/book.jpg" /></a><span id="goog_1459121833"></span><span id="goog_1459121834"></span><a href="http://www.blogger.com/"></a></div>
<div>
<br /></div>
<div>
My new book, UX for Lean Startups, will help you learn how to do better qualitative and quantitative research. It also includes tons of tips and tricks for better, faster design. </div>
<div>
<br /></div>
<div>
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Buy It Now</a></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-78976053759606784752013-04-22T16:35:00.000-07:002013-04-22T16:35:11.212-07:00The Best Best PracticeI get asked for a lot of what I call "generic" advice, which I'm not really very good at giving. People will ask questions like, "Should I make a prototype?" or "Should I build a landing page?" or "Should I do more customer development?"<br />
<br />
If you've asked this in email, you've probably gotten an unreadable 5,000 word manifesto that is essentially a brain dump of everything I can think of on the topic. If you've asked me in person you've almost certainly had to listen to me blather until your eyes glazed over.<br />
<br />
Wherever you've asked, I've probably started the response with the words, "Well, it depends..."<br />
<br />
And it does depend. What you should do right now with your product depends on a tremendous number of factors.<br />
<br />
However, I think I've got some better advice for you.<br />
<br />
You see, there aren't really Best Practices in Lean UX that apply in every situation. There are merely things that would be extremely helpful, except in cases where they'd be a huge waste of time. You can learn all the techniques in the world, but you still have to know when to apply them.<br />
<br />
Every time you are wondering, "should I do this thing?" you should immediately ask yourself the following three questions:<br />
<ul>
<li>What do I hope to learn by doing this?</li>
<li>How likely is it that I will learn what I want to learn by doing this?</li>
<li>Is there a faster, cheaper, or more effective way that I could learn what I want to learn?</li>
</ul>
<h3>
An Example!</h3>
<div>
Somebody recently asked me if his company should build an interactive prototype of a proposed new feature. </div>
<div>
<br />
I asked him what he hoped to learn by building an interactive prototype. He said he wanted to know if people would use the feature. I explained that, actually, interactive prototypes aren't terribly good for figuring out if people <b>will</b> use your new feature. They're only good for figuring out if people <b>can</b> use your new feature. </div>
<div>
<br /></div>
<div>
So, by building an interactive prototype, you're very unlikely to learn what you want to learn. A more effective way to learn if people will use a new feature might be a Feature Stub (also called a Fake Door). </div>
<div>
<br /></div>
<div>
<i>Note: A Feature Stub is where you put some sort of access in your product to the proposed feature. For example, if you were wondering if people would watch an informational video, you might put a link on your site called Watch This Informational Video and then record how many people clicked on the link. If nobody clicked your link, you wouldn't bother to make an informational video. </i></div>
<div>
<i><br /></i></div>
<div>
To be clear, it may be that he should also build an interactive prototype in order to figure out if people can use the feature as designed. However, his first step should be to learn whether the feature is worth building at all. If nobody's going to use the feature, it's best to learn that before you spend a lot of time designing and building it.<br />
<br /></div>
<h3>
It's All About Learning</h3>
<div>
The reason these questions are so important is that Lean Startup is all about learning quickly. If a particular Best Practice helps you learn what you need to learn, then you should use it. If not, you shouldn't. At least, not just yet. In other words, it depends.<br />
<br />
<b>Want to learn more? Buy this book.</b><br />
<br /></div>
<div>
<div class="separator" style="clear: both; float: left; padding-right: 10px;">
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYhEpDD_fa-yHPgDa3SdQLqIuwkxem7L4A2vpJkNOv-YW_lvDwLuZ3vGMozbTfmKKvEI6wX5PbngE0Vgs4V22dpQl9vVBE2V9lrMw-q8SmBh85jyFiv4DEzEFupm5GgmVDetHY1uLmnV8/s1600/book.jpg" /></a><span id="goog_1459121833"></span><span id="goog_1459121834"></span><a href="http://www.blogger.com/"></a></div>
<div>
<br /></div>
<div>
My new book, UX for Lean Startups, will help you learn how to build great products. It also includes all sorts of Best Practices and when you should use them. </div>
<div>
<br /></div>
<div>
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Buy It Now</a></div>
</div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-29346621597805805372013-04-18T13:13:00.000-07:002013-04-18T13:18:01.259-07:0010 Reasons Founders Should Learn to DesignI know, I know. Founders and entrepreneurs are already being told that they need to learn how to code, hire, raise money, and get customers.<br />
<br />
Screw that. What founders and entrepreneurs should really do is learn how to build a great, usable, useful product. And that means learning the fundamentals of research and design.<br />
<br />
Don't believe me? Here are 10 reasons you should learn to be your own UX designer (or at least learn enough about UX design to fake it).<br />
<ol>
<li>You can't build a great product if you don't know what problem it solves for which people. UX design and research helps you figure that out.</li>
<li>The only thing harder to find than a great designer is a unicorn.</li>
<li>It is almost impossible to judge somebody else's UX design skills unless you have designed things yourself. </li>
<li>The only thing more expensive than a great designer is a faberge egg. Sitting on top of a unicorn. </li>
<li>It's much easier to manage somebody who is doing a job you truly understand. </li>
<li>Jason Putorti already has a job.</li>
<li>UX design is a team sport. You don't want to get picked last for the team, do you? </li>
<li>You have a million fabulous feature ideas. It's easiest to communicate them to your team and customers through design. </li>
<li>You should already understand your product and users better than anybody else. This just takes it to the next logical step. </li>
<li>Adding extra people to the Build>Measure>Learn loop does not make it faster. </li>
</ol>
<div>
Convinced? Great! First, <a href="http://clicktotweet.com/yoc7d" target="_blank">share this list with people!</a></div>
<div>
<br /></div>
<div>
Now, here's a book to help you learn how to do enough user research and design to get your product into the hands of people who want to buy it. </div>
<div>
<br /></div>
<div class="separator" style="clear: both; float: left; padding-right: 10px;">
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYhEpDD_fa-yHPgDa3SdQLqIuwkxem7L4A2vpJkNOv-YW_lvDwLuZ3vGMozbTfmKKvEI6wX5PbngE0Vgs4V22dpQl9vVBE2V9lrMw-q8SmBh85jyFiv4DEzEFupm5GgmVDetHY1uLmnV8/s1600/book.jpg" /></a><span id="goog_1459121833"></span><span id="goog_1459121834"></span><a href="http://www.blogger.com/"></a></div>
<div>
<br /></div>
<div>
It's called UX for Lean Startups. It's by me. It will help you learn how to build great products. I promise. </div>
<div>
<br /></div>
<div>
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Buy It Now</a></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-5898944903549066462013-03-19T09:49:00.000-07:002013-03-19T09:54:58.737-07:00Design Hacks - The TalkI write a lot about user research - generally tips and tricks for people who don't have much experience with it. The reason for this should be obvious. Understanding your user, by any means necessary, is always the first step in creating a compelling product.<br />
<br />
Seriously, you can't build a product without understanding the problem you're solving and the people for whom you're solving it. Various forms of research are the best way of understanding people who aren't you. It's really as simple as that.<br />
<br />
But I've also seen another common problem. A whole lot of folks have learned how to go out and listen to their customers and understand problems, but they still make bad, hard to use products that don't really solve a problem. It turns out that, while learning your users problems is a necessary first step, it's not the only step.<br />
<br />
You also have to be able to create something that people understand and want to use, and you don't do that by simply trying random ideas until one of them sticks unless you have an infinite number of monkeys and typewriters. If you are constrained with respect to monkeys, typewriters, or VC funding, you might want a little guidance on what to do once you understand the problem.<br />
<br />
Getting your design closer to right on the first, second, or third try will speed things up considerably. It's hard to learn anything from a badly designed, unusable product other than the fact that people hate badly designed, unusable products. And believe me, that lesson has been learned. Kind of a lot.<br />
<br />
That's why I'll be giving a talk at Lean Startup Circle on Wednesday, March 20th. It starts at 6:30. There will be other interesting speakers, as well. You can sign up here: <a href="http://sanfrancisco.leanstartupcircle.com/events/102633722/">http://sanfrancisco.leanstartupcircle.com/events/102633722/</a><br />
<br />
I'll be talking about Design Hacks. These will include a few general tips on producing a good design. It will also include some (free) resources for getting good design ideas. Time permitting, it will include an example or two of how to think about new features for your product in a way that makes them easier to design.<br />
<br />
This talk is NOT for design experts. Sorry, you'll be bored out of your minds.<br />
<br />
This talk is perfect for founders and engineers who don't have experience with turning what they know about their users into useful designs. And, as always, I'll be hanging around afterward to answer specific questions about your products.<br />
<br />
Once again, to see the talk, sign up here: You can sign up here: <a href="http://sanfrancisco.leanstartupcircle.com/events/102633722/">http://sanfrancisco.leanstartupcircle.com/events/102633722/</a><br />
<br />
If you want to hear about future events where I'll be speaking, you can <a href="http://twitter.com/lauraklein">follow me on Twitter</a>.<br />
If you like to read about things like Design Hacks, <a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">the book is available for pre-order.</a><br />
<br />Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-51433473864854068662013-02-25T17:12:00.000-08:002013-02-25T17:12:17.391-08:00Don't Make Your Users Feel Like Idiots<b id="internal-source-marker_0.4842874766327441"><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">I’m a smart person. I’ve been using the Internet since the early 1990s. I know how to program. I only feel the need to point this out, because I’m about to share with you a story in which I come across as a complete, blithering idiot, and I’m feeling a little defensive about it. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">I got an email from an event that I won’t name, but I’m guessing a few of you are getting emails of your own. If you didn’t make the same mistake, then bask in the glory of being better at computers than I am. If you did make the same mistake, welcome to the club. You’re not alone. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">The email I received was several paragraphs long and told me all the places and times where I could pick up my badge for the event. It also said that they were introducing something new this year called a QuickCode. The email instructed me to bring my photo id and my QuickCode to pick up my badge. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">Then it had the following line:</span><br /><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Laura Klein’s QuickCode:</span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">That’s it. After that, it went on to give me more badge-related information. “Aha, I thought. The automated system has failed to print my QuickCode.” </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">I immediately wrote back and said that I didn’t get my QuickCode. To the credit of the organization, I was immediately written back to by a very polite person who explained that the QuickCode was an image and even gave me instructions on how to turn on images in my email, in case I didn’t know how. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">I was, as you might imagine, embarrassed. I mean, of course I know how to show images in an email. I just want to make that clear, because I’m coming off as enough of an idiot without you thinking I can’t use Gmail. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">What I didn’t know was that the QuickCode was an image. Because I’ve never seen a QuickCode. Because a QuickCode wasn’t a thing to me until an hour ago. Because a QuickCode is just a name that somebody made up for a bar code that they’re using to help with their badging system. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">Obviously the people writing the email knew what a QuickCode was, so it wasn’t at all surprising to them that you’d have to turn on images to see one. For those of us (ok, me) who had never heard of a QuickCode, this wasn’t immediately obvious. A QuickCode could just as easily have been a string of numbers and letters that could have been printed in the email. Of course, when I went back and re-read the email, the first paragraph did mention “scanning” the quick code, so I might have figured out what it was, but there were a lot of paragraphs in the email that I quickly skimmed. This is not unusual user behavior. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">The interesting thing is that they could have avoided my acting like an idiot and subsequently having to deal with my support email by just including the phrase, “If you don’t see your QuickCode, try turning on images in your email.” They could have made that the alt text for the image so only people who didn’t have images turned on would see it. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">Why am I telling you all this? I’m telling you this because we make assumptions of this sort in our interfaces every day. We assume people know that a QuickCode is an image, even though they’ve never heard of a QuickCode. We assume people know what our products do, even though they’ve never heard of our product. We assume people know where to go within our products to find the things they’re looking for, even though they weren’t in the meeting where we determined our product structure. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">We are almost always wrong. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">The moral of this story is not (just) that your users are going to do stupid things sometimes. It’s not even that they’re probably only going to skim our very long emails. The moral is that we constantly need to be asking ourselves what we really expect a user to understand about our product, and we need to have ways to preemptively help them in places where we’re presenting new concepts or unfamiliar terminology. </span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"></span><br /><span style="font-family: Arial; font-size: 15px; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">Users don’t know our slang. They don’t know our jargon. They don’t know our product. If we want them to use our products successfully, we need to teach them what they need to know without making them feel like idiots. </span></b>Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-19352689506735486752013-02-20T10:12:00.000-08:002013-02-25T11:47:50.201-08:00Combining Qualitative & Quantitative Research<br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Designers are infallible. At least, that’s the only conclusion that I can draw, considering how many of them flat out refuse to do any sort of qualitative or quantitative testing on their product. I have spoken with designers, founders, and product owners at companies of all sizes, and it always amazes me how many of them are so convinced that their product vision is perfect that they will come up with the most inventive excuses for not doing any sort of customer research or testing. </span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Before I share some of these excuses with you, let’s take a look at the types of research I would expect these folks to be doing on their products and ideas. </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><br />
<h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">Quantitative Reserach</span></b></h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">When I say quantitative research in this context, I’m talking about a/b testing, product analytics, and metrics - things that tell you what is happening when users interact with your product. These are methods of finding out, after you’ve shipped a new product, feature, or change, exactly what your users are doing with it. </span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Are people using the new feature once and then abandoning it? Are they not finding the new feature at all? Are they spending more money than users who don’t see the change? Are they more likely to sign up for a subscription or buy a premium offering? These are the types of questions that quantitative research can answer. </span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">For a simple example, if you were to design a new version of a landing page, you might run an a/b test of the new design against the old design. Half of your users would see each version, and you’d measure to see which design got you more registered users or qualified leads or sales or any other metric you cared about.</span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><br />
<h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">Qualitative Research</span></b></h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">By qualitative testing, I mean the act of watching people use your product and talking to them about it. I don’t mean asking users what you should build. I just mean observing and listening to your users in order to better understand their behavior. </span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">You might do qualitative testing before building a new feature or product so that you can learn more about your potential users’ behaviors. What is their current workflow? What is their level of technical expertise? What products are they already using? You might also do it once your product is in the hands of users in order to understand why they’re behaving the way they are. Do they find something confusing? Are they getting lost or stuck at a particular point? Does the product not solve a critical problem for them? </span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">For example, you might find a few of your regular users and watch them with your product in order to understand why they’re spending less money since you shipped a new feature. You might give them a task in order to see if they could complete it or if they got stuck. You might interview them about their usage of the new feature in order to understand how they feel about it. </span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b>
<br />
<h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">Excuses, Excuses</span></b></h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">While it may seem perfectly reasonable to want to know what your users are really doing and why they are doing it, a huge number of designers seem really resistant to performing these simple types of research or even listening to the results. I don’t know why they refuse to pay any attention to their users, but I can share some of the terrible excuses they’ve given me. </span></b><br />
<h4>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></h4>
<h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">A/B Testing is Only Good for Small Changes</span></b></h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">I hear this one a lot. There seems to be a misconception that a/b testing is only useful for things like button color and that by doing a/b testing you’re only ever going to get small changes. The argument goes something like, “Well, we can only test very small things and so we will test our way to a local maximum without ever being able to really make an important change to our user experience.”</span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">This is simply untrue.</span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">You can a/b test anything. You can show two groups of users entirely different experiences and measure how each group behaves. You can hide whole features from users. You can change the entire checkout flow for half the people buying things from you. You can test a brand new registration or onboarding system. And, of course, you can test different button colors, if that is something that you are inclined to do.</span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">The important thing to remember here is that a/b testing is a tool. Itʼs agnostic about what youʼre testing. If youʼre just testing small changes, youʼll only get small changes in your product. If, on the other hand, you test big things - major navigation changes, new features, new purchasing flows, completely different products - then youʼll get big changes. And, more importantly, you’ll know how they affected your users. </span></b><br />
<h3>
<span style="font-family: Arial; font-size: 16px; font-style: italic; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;"><br /></span></h3>
<h3>
<span style="font-family: Arial; font-size: 16px; font-style: italic; font-weight: normal; vertical-align: baseline; white-space: pre-wrap;">Quantitative Testing Leads to a Confused Mess of an Interface</span></h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">This is one of those arguments that has a grain of truth in it. It goes something like, “If we always just take the thing that converts best, we will end up with a confusing mess of an interface.”</span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Anybody who has looked at Amazonʼs product pages knows the sort of thing that a/b testing can lead to. They have a huge amount of information on each screen, and none of it seems particularly attractive. On the other hand, they rake in money.</span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Itʼs true that when youʼre doing lots of a/b testing on various features, you can wind up with a weird mishmash of things in your product that donʼt necessarily create a harmonious overall design. You can even wind up with features that, while they improve conversion on their own, end up hurting conversion when they’re combined. </span></b><br />
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">As an example, letʼs say youʼre testing a product detail page. You decide to run several a/b tests simultaneously for the following new features:</span></b><br />
<ul>
<li><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="vertical-align: baseline;"> customer photos </span></b></b></li>
<li><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="vertical-align: baseline;">comments</span></b></b></li>
<li><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="vertical-align: baseline;">ratings </span></b></b></li>
<li><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="vertical-align: baseline;">extended product details </span></b></b></li>
<li><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="vertical-align: baseline;">shipping information </span></b></b></li>
<li><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="vertical-align: baseline;">sale price </span></b></b></li>
<li><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="vertical-align: baseline;">return info</span></b></b></li>
</ul>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Now, letʼs imagine that each one of those items, in its own a/b test, increases conversion by some small, but statistically significant margin. That means you keep all of them. Now youʼve got a product detail page with a huge number of things on it. You might, rightly, worry that the page is becoming so overwhelming that youʼll start to lose conversions.</span></b><br />
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Again, this is not the fault of a/b testing – or in this case, a/b/c/d/e testing. This is the fault of a bad test. You see, itʼs not enough that you run an a/b test. You have to run a </span><span style="font-family: Arial; font-size: 15px; font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">good</span><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"> a/b test. In this case, just because the addition of a particular feature to your product page improved conversions doesn’t mean that adding a dozen new features to your product page will increase your conversion. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">In this instance, you might be better off running several a/b tests serially. In other words, add a feature, test it, and then add another and test. This way you’ll be sure that every additional feature is actually improving your conversion. Alternatively, you could test a few different versions of the page with different combinations of features to see which converts best. </span></b></div>
<div>
<h4>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></h4>
<h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">A/B Testing Takes Away the Need For Design</span></b></h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">For some reason, people think that a/b testing means that you just randomly test whatever crazy shit pops into your head. They envision a world where engineers algorithmically generate feature ideas, build them all, and then just measure which one does best.</span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">This is just absolute nonsense.</span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">A/B testing only specifies that you need to test new designs against each other or against some sort of a control. It says absolutely zero about how you come up with those design ideas.</span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">The best way to come up with great products is to go out and observe users and find problems that you can solve and then use good design processes to solve them. When you start doing testing, youʼre not changing anything at all about that process. Youʼre just making sure that you get metrics on how those changes affect real user behavior.</span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Letʼs imagine that youʼre building an online site to buy pet food. You come up with a fabulous landing page idea that involves some sort of talking sock puppet. You decide to create this puppet character based on your intimate knowledge of your user base and your sincere belief that what they are missing in their lives is a talking sock puppet. Itʼs a reasonable assumption.</span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Instead of just launching your wholly re-imagined landing page, complete with talking sock puppet video, you create your landing page and show it to only half of your users, while the rest of your users are stuck with their sad, sock puppet-less version of the site. Then you look to see which group of users bought more pet food. At no point did the testing process have anything to do with the design process. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Itʼs really that simple. Nothing about a/b testing determines what youʼre going to test. A/B testing has literally nothing to do with the initial design and research process. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Whatever youʼre testing, you still need somebody who is good at creating the experiences youʼre planning on testing against one another. A/B testing two crappy experiences does, in fact, lead to a final crappy experience. After all, if youʼre looking at two options that both suck, a/b testing is only going to determine which one sucks less.</span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Design is still incredibly important. It just becomes possible to measure designʼs impact with a/b testing.</span></b></div>
<div>
<h4>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></h4>
<h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">There’s No Time to Usability Test</span></b></h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">When I ask people whether they’ve done usability testing on prototypes of major changes to their products, I frequently get told that there simply wasn’t time. It often sounds something like, “Oh, we had this really tight deadline, and we couldn’t fit in a round of usability testing on a prototype because that would have added at least a week, and then we wouldn’t have been able to ship on time.” </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">The fact is you don't have time NOT to usability test. As your development cycle gets farther along, major changes get more and more expensive to implement. If you're in an agile development environment, you can make updates based on user feedback quickly after a release, but in a more traditional environment, it can be a long time before you can correct a big mistake, and that spells slippage, higher costs, and angry development teams. Even in agile environments, it’s still faster to fix things before you write a lot of code than after you have pissed off customers who are wondering why you ruined an important feature that they were using. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">I know you have a deadline. I know it's probably slipped already. It's still a bad excuse for not getting customer feedback during the development process. You're just costing yourself time later. I’ve never known good usability testing to do anything other than save time in the long run on big projects. </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><br />
<h4>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></h4>
<h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">Qualitative Research Doesn’t Work Because Users Don’t Know What They Want</span></b></h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">This is possibly the most common argument against qualitative research, and it’s particularly frustrating, because part of the statement is quite true. Users aren’t particularly good at coming up with brilliant new ideas for what to build next. Fortunately, that doesn’t matter. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Let’s make this perfectly clear. Qualitative research is NOT about asking people what they want. At no point do we say, “What should we build next?” and then relinquish control over our interfaces to our users. People who do this are NOT doing qualitative research. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Qualitative research isn’t about asking people what they want and giving it to them. Qualitative research is about understanding the needs and behaviors of your users. It’s about really knowing what problem you’re solving and for whom. </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Once you understand what your users are like and what they want to do with your product, it’s your job to come up with ways to make that happen. That’s the design part. That’s the part that’s your job. </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><br />
<h4>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></h4>
<h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">It’s My Vision - Users Will Screw it Up</span></b></h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">This can also be called the "But Steve Jobs doesn't listen to users..." excuse. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">The fact is, understanding what your users like and don't like about your product doesn't mean giving up on your vision. You don't need to make every single change suggested by your users. You don't need to sacrifice a coherent design to the whims of a user test. You don’t even need to keep a design just because it converts better in an a/b test. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">What you do need to do is understand exactly what is happening with your product and why. And you can only do that by gathering data. The data can help you make better decisions, but they don’t force you to do anything at all. </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><br />
<h4>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></h4>
<h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">Design Isn’t About Metrics</span></b></h4>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">This is the argument that infuriates me the most. I have literally heard people say things like, “Design can’t be measured, because design isnʼt about the bottom line. Itʼs all about the customer experience.”</span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Nope. </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Wouldnʼt it be a better experience if everything on Amazon were free? Be honest! It totally would. </span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Unfortunately, it would be a somewhat traumatic experience for the Amazon stockholders. </span></b><b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">You see, we donʼt always optimize for the absolute best user experience. We make tradeoffs. We aim for a fabulous user experience that also delivers fabulous profits.</span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">While itʼs true that we donʼt want to just turn our user experience design over to short term revenue metrics, we can vastly improve user experience by seeing which improvements and features are most beneficial for both users and the company.</span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Design is not art. If you think that thereʼs some ideal design that is completely divorced from the effect itʼs having on your companyʼs bottom line, then youʼre an artist, not a designer. Design has a purpose and a goal, and those things can be measured.</span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><br />
<h3>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-weight: bold; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></h3>
<h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">So, What’s the Right Answer?</span></b></h3>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">If you’re all out of excuses, there is something that you can do to vastly improve your product. You can use quantitative and qualitative data together. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Use quantitative metrics to understand exactly what your users are doing. What features do they use? How much do they spend? Does changing something big have a big impact on real user behavior? </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Use qualitative research to understand why your users do what they do. What problems are they trying to solve? Why are they dropping out of a particular task flow when they do? Why do they leave and never come back. </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Let’s look at an example of how you might do this effectively. First, imagine that you have a payment flow in your product. Now, imagine that 80% of your users are not getting through that payment flow once they’ve started. Of course, you wouldn’t know that at all if you weren’t looking at your metrics. </span></b><b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">You also wouldn’t know that the majority of people are dropping out in one particular place in the flow. </span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Next, imagine that you want to know why so many people are getting stuck at that one place. You could do a very simple observational test where you watch four or five real users going through the payment flow in order to see if they get stuck in the same place. When they do, you could discuss with them what stopped them there. Did they need more information? Was there a bug? Did they get confused? </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"><br /></span></b></div>
<div>
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">Once you have a hypothesis about what’s not working for people, you can make a change to your payment flow that you think will fix the problem. Neither qualitative nor quantitative research tells you what this change is. They just alert you that there’s a problem and give you some ideas about why that problem is happening. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">After you’ve made your change, you can run an a/b test of the old version against the new version. This will let you know whether your change was effective or if the problem still exists. This creates a fantastic feedback loop of information so that you can confirm whether your design instincts are functioning correctly and you’re actually solving user problems. </span></b></div>
<div>
<b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial;"><span style="font-size: 15px; white-space: pre-wrap;"><br /></span></span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;">As you can hopefully see from the example, nobody is saying that you have to be a slave to your data. Nobody is saying that you have to turn your product vision or development process over to an algorithm or a focus group. Nobody is saying that you can only make small changes. All I’m saying is that using quantitative and qualitative research correctly gives you insight into what your users are doing and why they are doing it. And that will be good for your designs, your product, and your business. </span></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><b id="internal-source-marker_0.018527592532336712" style="font-weight: normal;"><br /></b><br />
<b id="internal-source-marker_0.018527592532336712"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"></span><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"></span><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"></span>Like the post? </b><br />
<b style="font-weight: normal;"><span style="font-family: Arial; font-size: 15px; vertical-align: baseline; white-space: pre-wrap;"></span></b></div>
<div>
<b style="font-weight: normal;"><a href="http://twitter.com/lauraklein">Follow me on Twitter!</a></b></div>
<div>
<a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Pre-order the book! </a></div>
Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-16117773688760410182013-02-04T15:51:00.000-08:002013-02-04T15:51:28.599-08:00Make Meetings Less Awful<div class="p1">
Meetings are the worst. I mean, my God, they suck. The vast majority of meetings are simply awful. </div>
<div class="p2">
<br /></div>
<div class="p1">
But they don’t have to be!</div>
<div class="p2">
<br /></div>
<div class="p1">
If you’ve ever been in a meeting where you felt like your soul was being sucked out of your body through your eyes, I have a few tips that will make future meetings more tolerable. If you implement them correctly, they might even make some of your meetings useful! Imagine that. </div>
<div class="p1">
<h3>
<br /></h3>
<h3>
Write It Down Ahead of Time</h3>
</div>
<div class="p1">
Agendas. You should have one. Well, this seems painfully obvious, doesn’t it? But seriously. How many meetings do you attend where there isn’t a single person who knows exactly what you’ll be talking about in the meeting beforehand? </div>
<div class="p2">
<br /></div>
<div class="p1">
Here’s a simple solution for making meetings wildly more productive. The person who is in charge of the meeting needs to make an agenda and send it out to all the attendees before the meeting. A full day is great, especially if there are things that people might want to research in preparation for the meeting. Even a few hours is helpful. It’s best if the person in charge reaches out to attendees early to see if they have anything they’d like to see on the agenda. </div>
<div class="p2">
<br /></div>
<div class="p1">
The corollary to this is that the meeting attendees must actually read the agenda, understand what will be discussed, and come to the meeting prepared to discuss and make a decision on any of the agenda items they care about. </div>
<div class="p2">
<br /></div>
<div class="p1">
And, of course, if they don’t care about any of the agenda items, they probably shouldn’t attend the meeting. </div>
<div class="p2">
<br /></div>
<div class="p1">
Another, slightly more spontaneous, method is the box on the whiteboard. We used to do this in engineering meetings at IMVU. Before the weekly eng meeting started, people could add topics they wanted to discuss to a list on the whiteboard. Once the meeting started, someone drew a box around the list. Nothing could be added to the list once we started, and nothing was discussed that wasn’t in the box. As a bonus, it encouraged people to get to the meeting early if they had a topic to discuss. </div>
<div class="p1">
<h3>
<br /></h3>
<h3>
Everything Has a Next Step </h3>
</div>
<div class="p1">
Meetings are not open ended discussion forums. They’re not group therapy sessions. Meetings are for making decisions. Every single thing you discuss in a meeting should have an decision and a deliverable. </div>
<div class="p2">
<br /></div>
<div class="p1">
Here’s an example. Once, I was in a meeting to talk about a change somebody wanted to make to a product’s design. We sat together for half an hour discussing the types of research she could do to figure out whether the design would work or whether it was small enough just to ship. At the end of about 30 minutes, she announced, “Well, I don’t think we’re going to decide this now.” To which I responded, “Why the hell not?”</div>
<div class="p2">
<br /></div>
<div class="p1">
Stop having discussions just to have discussions. Refusing to make a decision in this meeting just ensures that you need to have another meeting later, and nobody wants that. Make sure that all agenda items at meetings have outcomes. Sometimes the outcome will be, “Susan is going to go off and investigate these three questions and report back so that we can make a more informed decision.” Sometimes the outcome will be, “Laura is in charge of building a prototype and will pull in whomever she needs to help.” Sometimes the outcome will be, “We’re shipping this damned thing as soon as we leave the room.” I kind of wish that were always the outcome.</div>
<div class="p2">
<br /></div>
<div class="p1">
The outcome will never be, “Well, we need to think more about this.” The problem with this statement is that it’s too vague. There is nothing actionable about this. Nobody is assigned to do anything, so nothing will really get done, and the next time the point comes up, you’ll have to have the whole conversation over again. Everything from a meeting needs a specific next step and somebody who is assigned to take it. </div>
<div class="p1">
<h3>
<br /></h3>
<h3>
Fewer Attendees</h3>
</div>
<div class="p1">
Meetings become far less productive after about four people, so whenever possible, keep meetings as small as you can. Obviously you sometimes need to have more folks, but really ask yourself whether everybody needs to be in the meeting, or if somebody would do just as well with a quick report after the fact.</div>
<div class="p2">
<br /></div>
<div class="p1">
If there are people who routinely aren’t contributing to the meeting in any way - no agenda items, no adding to the discussion, no making decisions, no deliverables after the fact - then they are great candidates for not getting an invitation next time. Presumably you’re paying these people, and I have to imagine there is something more productive they could be doing than sitting in a meeting checking their email.</div>
<div class="p1">
<h3>
<br /></h3>
<h3>
Every Meeting Has a Leader</h3>
</div>
<div class="p1">
Someone has to be in charge of the meeting. Always. </div>
<div class="p2">
<br /></div>
<div class="p1">
The person in charge of the meeting has a lot of responsibilities. The leader must make the agenda, keep everybody on track, mediate disputes, ensure that everybody who has a contribution gets to make that contribution, make sure that all the deliverables and next steps are being captured, and follow up on the things that come out of the meetings. </div>
<div class="p2">
<br /></div>
<div class="p1">
I was in a meeting once that was led by a particularly ineffective PM. We were discussing what the priorities would be for her product (don’t even get me started on why engineers and designers were discussing this when it was so clearly her job). We were each giving our opinions about what should be done first, and the discussion began to get heated. </div>
<div class="p2">
<br /></div>
<div class="p1">
Instead of stepping in and guiding the discussion or just deciding what order we’d build things in, the PM sat back and let everybody scream at each other. The meeting ended with someone in tears (unsurprisingly, this person wasn’t me) and no decision made about prioritization. </div>
<div class="p2">
<br /></div>
<div class="p1">
Unless somebody is in charge, meetings just meander and go on for three times as long as they need to with nobody who is willing or able to say, “Right. We’re done here. Let’s go do something productive.” Having someone whose job it is to end discussion and assign tasks makes things go much more smoothly and quickly. </div>
<div class="p2">
<br /></div>
<div class="p1">
Besides, if we actually expected some work from the people who call all those meetings, maybe they’d call fewer damned meetings. </div>
<div class="p1">
<h3>
<br /></h3>
<h3>
No Broadcast Meetings</h3>
</div>
<div class="p1">
I’m going to assume that everybody working for your company is literate. If this is true, please stop having meetings where you read things to them. You’re not in kindergarten. This is not story time. </div>
<div class="p2">
<br /></div>
<div class="p1">
I have been to too many meetings where a PM or CEO or somebody else who should know better shows a slide deck and then proceeds to read all the slides to the audience for an hour. </div>
<div class="p2">
<br /></div>
<div class="p1">
Here’s an idea: send the deck out the day before. Tell people to read it for themselves and come up with questions. At the meeting, spend no more than five minutes summarizing the most important things about the slide deck (“We made more money this month than last month! Yay!”), then take questions from the audience about the rest of the deck. </div>
<div class="p2">
<br /></div>
<div class="p1">
If you are concerned that people will miss critical information because they are failing to read important emails, that’s really something that you need to address separately. I’ve found that reducing meeting times by a few hours a week gives people far more time to read their email or to do something actually productive. </div>
<div class="p1">
<h3>
<br /></h3>
<h3>
More Discussions, More Working Sessions, Fewer Meetings</h3>
</div>
<div class="p1">
You know what I like more than meetings (besides everything)? I like discussions. Discussions are things that happen between two or three people who are all interested in and informed about a particular topic. They tend to happen in hallways and they often help disseminate important information to the people who need it. </div>
<div class="p2">
<br /></div>
<div class="p1">
I also like working sessions, in which a few people all work together on something like a design or code. Working sessions generally involve a lot of writing on whiteboards or pair programming or gathering around somebody’s screen to try different variations of a particular wireframe. Working sessions are better than even good meetings because by the end of the working session, you’re often done with whatever it was you were going to just talk about in the meeting. </div>
<div class="p2">
<br /></div>
<div class="p1">
And maybe that’s the most important point here. Meetings are not conducive to DOING. They are conducive to TALKING. Talking is the enemy of doing. By making a few small changes in the way you conduct your meetings, you can turn them into places where things get done rather than just talked about. And that will make meetings suck a whole lot less. I promise. </div>
<br />Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-37455741846053872522013-01-22T16:27:00.000-08:002013-01-22T16:27:03.258-08:00To Kill or Not to Kill<div>
After my <a href="http://usersknow.blogspot.com/2013/01/expect-more-from-product-managers.html">rant last week about product managers</a>, the excellent Joshua Porter (<a href="http://twitter.com/bokardo">@bokardo</a>) made a great point about it. He said, “In my own experience the hard part is knowing when to kill something vs. when to give it more breathing room, as sometimes a really new idea can’t really be tested in low fidelity.”<br />
<br /></div>
<div>
As much as I’d love to send my pageviews soaring by starting a flame war with somebody popular on the internet, I have to admit that he’s 100% right. Killing a feature or product is exceptionally difficult. It’s tough to know when to do it. It’s tough to figure out if you made the right decision. And it’s tough emotionally to let go of something you really thought was going to be great. <br />
<br /></div>
<div>
First, let’s talk a bit about why you kill products or features. You kill them because they’re not succeeding or because you don't expect them to succeed. That could mean that they’re not getting enough traction or because you’ve determined that they’re never going to turn into an important part of your business. You kill them because the ROI isn’t high enough to justify investing more resources in them. You kill them because they are using resources that would be better spent in other places.
<br />
<br /></div>
<div>
They’re hard to kill precisely because you never know whether they’re just a few days away from taking off and turning into everything you thought they’d be. After all, every successful product went through some period of time before everybody found about it.
<br />
<br /></div>
<div>
So, let’s look at a few questions to ask yourself before killing a product or feature. <b>For the purposes of this post, I'm just going to talk about killing existing features or products. </b>I'll probably address how to decide to kill things before you build them in a future post.<br />
<br />
These questions won’t make killing easy, but hopefully, they’ll make it possible. </div>
<h2>
Why Isn’t Everyone Using It?</h2>
<div>
There are four reasons people don’t use your product or feature. Yep. That’s right. There may be thousands of reasons that people do use a product, but there are really only four basic reasons that they don’t.</div>
<div>
<br />
People don’t use your product because:<br />
<ul>
<li>They don’t know about it </li>
<li>It doesn’t solve a problem for them </li>
<li>They don’t understand that it will solve a problem for them </li>
<li>The problem it solves isn’t worth the investment of time, money, or effort</li>
</ul>
</div>
<div>
Before you kill your existing product or feature, figure out why it’s not popular. For example, if you’re simply not getting any traffic to your page, it means not very many people know it exists. On the other hand, if you’re getting tons of traffic, but none of it is converting or engaging, then your problem is one of the last three. People are finding your product, but they don't want it or understand it enough to convert.<br />
<br /></div>
<div>
You can find out if the product solves a serious problem for people by talking to the types of people you expect to have that problem. Develop a persona that represents the sort of person who might suffer from this problem, and interview them about that portion of their lives.
</div>
<div>
<br />
Don’t just ask, “do you suffer from x problem?” Have them tell you stories about their real life experiences in situations where they might have experienced the problem. For example, if you’re testing to see if people need turn by turn navigation on their phones, you might ask them to tell you about the last time they were trying to get somewhere and they got lost. Then you might ask how often that happens. If it’s extremely rare, they probably don’t have the problem you’re trying to solve.
<br />
<br /></div>
<div>
If you’re trying to figure out if they understand the problem your product or feature solves, you can do that by showing them your product or feature (or a mockup or prototype) and asking them to tell you about it. Don’t prompt or prep them. Just show them the product and say, “Tell me what this does. Who do you think it’s for?” You will be shocked by how often your perfectly crafted prose and imagery cause nothing but blank stares.
<br />
<br /></div>
<div>
When determining whether or not your product is worth getting, don’t forget that money isn’t everything to your potential users. Sometimes there are switching costs that they’ll have to deal with or just the cognitive load of learning how to use a new product. I can’t tell you how often I’ve seen people stick with a completely suboptimal solution to a problem, just because that’s what they’re used to.<br />
<br />
Regardless of which it is, determining the reason people aren't responding positively to your product will go a long way toward telling you whether to kill it or keep it. </div>
<h2>
Who Is Using It? </h2>
<div>
So, once you’ve determined that there are people who are using your product or who you expect will use it because it solves a serious problem for them at a price they’re willing to pay, it’s time to look at who those people there are and how many of them exist.
<br />
<br /></div>
<div>
A great company with a very engaged group of users recently killed a feature. Unsurprisingly, there was a huge outcry. They got many, many complaints telling them how sad users were that the feature was going away. If they had gone entirely by the comments on the blog post about removing the feature, they would have been justified in thinking that they were making a huge mistake.
<br />
<br /></div>
<div>
Luckily, they didn’t do that.
</div>
<div>
<br />
It turned out that the number of people using the feature was an incredibly small percentage of their user base. More importantly, the people using the feature were not, by and large, paying customers. In other words, a couple percent of very vocal users who didn’t earn a cent for the company were upset by the removal.
</div>
<div>
<br />
While it’s always best to avoid making your users angry, there are certainly users that it’s safer to anger than others. Keeping a feature or product that is disproportionately useful to people who aren’t benefitting your business in some real way means that you have fewer resources to devote to things that might make you some money. </div>
<div>
<br />
The other thing to consider here is how many people you might reasonably expect to have use this product if everybody knew about it. Unless there is a huge potential market for your feature or the small market that exists is willing to pay quite a lot to use it, you may want to consider killing it.
</div>
<div>
<br />
<i>Note: for those few people who inevitably write to me and complain that “it’s not all about money,” I would like to point out that it very frequently does have to be about money or you will go out of business. If you want to keep your 10 free users super happy, you go right ahead. I’m going to cater to the large number of folks who pay me. </i><br />
<i><br /></i>
<i>And yes, I do understand the difference between long term and short term gains, and I expect my readers do, as well. Assume I'm optimizing for lifetime value here and not simply what makes the most money right this second.</i></div>
<h2>
What Is the Actual Cost of Keeping It?</h2>
<div>
Now that we’ve determined that people are using your product or feature, we should figure out how much it costs to keep your product or feature alive.
</div>
<div>
<br />
Of course, if you’re talking about your whole product, this math is relatively easy. The only hidden cost to keeping your product alive is the opportunity cost of building something else. If you’re working on your current product, you can’t be working on something more promising.
</div>
<div>
<br />
However, if you’re talking about a piece of your overall product, sometimes it can be harder to figure out how much it costs to keep a feature alive. Obviously there is the cost of the engineers or customer support people or sales people, but often they’re working on other things as well, so it’s not clear that cutting any particular feature will really save you any money. If even a few people are using a feature and it’s already built, why not just let it hang around indefinitely?
</div>
<div>
<br />
Well, consider some of these hidden costs to keeping a feature:<br />
<ul>
<li>Bug fixes </li>
<li>Customer support </li>
<li>A more complicated code base </li>
<li>A more complicated user interface (more features means more cognitive load on your new users) </li>
<li>Server and infrastructure costs </li>
<li>Additional work if you decide to do a site redesign or visual refresh</li>
</ul>
</div>
<div>
These may seem like small things, and in some cases they are, but don’t ever think that a feature is free just because you no longer are actively building it.<br />
<br />
Of course, there's another alternative, which is to continue to iterate on the feature or product. This obviously adds hugely to the expected costs. Let's say that you create a new search feature for your product, and very few people end up using it. The actual cost of that feature needs to include all the iterations and changes that you're willing to try before people start using it or you give up on it. </div>
<h2>
What Is the Actual Cost of Killing It?</h2>
<div>
In a similar vein, sometimes things can cost more to kill than you think. Unhappy users can cause trouble in forums or for support staff.
<br />
<br /></div>
<div>
Of course, I did mention above that it’s sometimes acceptable (and inevitable) to annoy some of your users, but don’t underestimate the work that it will take to keep that unhappiness from spreading throughout your entire community.
</div>
<div>
<br />
There are engineering costs to turning off a feature, as well. Either you need to pull it out of your code base or leave it there to rot. Neither of those options is free, although both can be ultimately cheaper than maintaining the feature.
</div>
<div>
<br />
If you’re killing your whole product, you are often throwing away a huge percentage of your customer base. Just because you’re pivoting doesn’t mean that all of your users will pivot with you.
</div>
<div>
<br />
And the same goes for your employees, if you’re lucky enough to have any. Killing a product or significant feature can be absolutely terrible for morale. Obviously you’re not going to keep a failing product just to make your employees happy, but make sure that you are prepared for the fallout – and possibly resignations - when you do decide to make a major change.</div>
<h2>
So, Should You Kill It?</h2>
<div>
In the end, it really comes down to the expected ROI, and the future is notoriously difficult to predict. Good customer development techniques can help you get a clearer idea of the eventual potential of a product or feature that seems to be failing. An honest assessment of real costs can help you determine the investment that you're really making into the product.<br />
<br /></div>
<div>
But it's an art, not a science. In the end, you're still going to have to make the decision. And it may be the toughest decision you ever make as an entrepreneur. Good luck!<br />
<br />
<b>Like the post? Here's what you should do next:</b><br />
<br />
<ul>
<li><a href="http://twitter.com/lauraklein">Follow me on Twitter</a></li>
<li><a href="http://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911">Pre-order the book</a></li>
<li><a href="http://workshops.leanstartup.co/">Attend a workshop</a></li>
</ul>
</div>
<br />Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-40762881337063306452013-01-17T20:36:00.000-08:002013-01-17T20:55:45.209-08:00Expect More From Product ManagersI talk to a lot of startups, and I've noticed a really troubling trend at some of them. A huge percentage of Product Managers at startups suck.<br />
<br />
Not you, obviously. I mean, you're a product manager at a startup, and you're the exception. Good for you. I mean all the other ones.<br />
<br />
I mean the Product Managers who are failing to do the following obvious things:<br />
<h2>
Understand their Users</h2>
I was visiting a company, and I asked about what sort of ongoing user research they were doing. It turned out that they had an intern for a few weeks who was doing a giant research study to try to understand how people viewed the product. The Product Managers would occasionally attend a session, but basically they seemed uninvolved in the research. They knew nothing about the planning. They didn't monitor to see how things were going.<br />
<br />
The research involved talking to a lot of people who had heard about the product but who had never used it before to see why they weren't using it. The Product Managers' main job with regard to research seemed to be to read a report produced by the intern at the end of the few weeks.<br />
<br />
Meanwhile, nobody was doing targeted usability research on whether people were confused by the product. Nobody was doing any sort of inquiry into how big customers were using the product. Nobody was calling people who had stopped using the product to find out why. Nobody was following up with new users to understand their initial experiences.<br />
<br />
Unsurprisingly, none of the PMs in charge of deciding what to build next had any real idea about usability problems, what separated their biggest customers from everybody else, or why people tried the service once and never returned. And that meant that they weren't very good at figuring out how to build their product, so when they did add a feature, it very rarely improved any of their key metrics.<br />
<br />
The single most important thing you can do as a Product Manager is understand your users. This is the foundation for making every single decision about your product that you will ever have to make. If you don't know who your customers are and what motivates them, you can't consistently deliver features that will make them happy. It really is that simple.<br />
<h2>
Know Exactly How their Product Works</h2>
I was talking to a different startup about their onboarding flow, and I asked the product manager to explain how it currently worked for certain types of users under specific circumstances. The product manager said he'd have to check with the designer to get all the details.<br />
<br />
The designer, of course, knew exactly how the product worked, since she was the one who had designed it. She also knew all about the user needs and the issues with the current flow and what she wanted to try next. All of this led me to wonder why on earth she wasn't the one in charge of the product.<br />
<br />
When I attended meetings with both of them, the product manager constantly had to refer to the designer when talking aout what things they had tried, what had worked, and what users were currently seeing. Whenever an engineer asked a question about how something was supposed to be built, the PM would simply pass the question along to the designer and then relay the answer back to the engineers.<br />
<br />
As far as I could tell, the PM was nothing more than a buffer between the engineers and the designer. Once the designer started working directly with the engineers, the PM had almost nothing to do except track the project schedule.<br />
<br />
If you don't know everything about how your product works and why it works that way, how are you supposed to make good decisions about it? The role of a product manager isn't to be a passive conduit for information. A great PM needs to understand the product well enough to make important decisions about how to change it.<br />
<h2>
Validate Assumptions Before Building</h2>
I'm not going to tell a specific story about this one, because I've seen it happen absolutely everywhere.<br />
<br />
Essentially, Product Managers seem to fall in love with ideas. Maybe they get the ideas from meetings or from their bosses or the ideas appear to them in a flash of light one morning in the shower. But regardless of how it happens, today's idea is always the Big Idea that is going to change everything.<br />
<br />
Once they've got the idea, of course, they jump straight to the question of how to get it built. Typically, they get the feature on the schedule, break it down, get a designer in to mock it up, and get the engineers working on it. At no time before all this happens do they stop and ask the question, "How can I tell if this idea is any good before I spend a lot of time and money on it?"<br />
<br />
No matter how good your instincts are, you don't really know that adding this new feature is going to be an enormous hit with your users. Sometimes you're right, and the feature is a game changer, but just as often, an unvalidated feature has a negative ROI.<br />
<br />
Good product managers do as much work as possible ahead of time to figure out if they're spending their resources on the right stuff. Maybe they devise a small experiment to test whether people will use the feature. Maybe they do a very small version of the feature first. Maybe they do a concierge version of the feature. Hell, maybe they even sell the feature before they build it.<br />
<br />
Whatever their strategy, good product managers validate their features before they build them, and that's why their ideas are so much more likely to improve the bottom line of the company. They don't necessarily have better ideas. They just kill the bad ones before spending too much time on them.<br />
<h2>
Prioritize Changes Based on Business and Customer Needs</h2>
Everything can't be a top priority. That's not how priority works. But you'd never know that to talk to some product managers. I can't tell you how often I've seen product managers try to build everything at once, because they simply couldn't make the decision about what was most important to either the business or to users.<br />
<br />
Unfortunately, this tends to cause problems as engineering gets spread too thin and the team gets confused about what they should be working on.<br />
<br />
Without clear prioritization, nothing really gets done well or quickly. Everybody ends up working on different projects, and all the projects move much more slowly than they would if everybody worked together.<br />
<br />
A good product manager can make priorities clear without micromanaging. She makes the decision about what to work on based on things like expected ROI and the outcome of early validation tests. She balances features that are great for the business with features that are great for the users, and she always tries to find features that are good for everybody. She looks at things like long term vs short term pay off and makes sure that features are delivering value to all the different types of customers - new users, power users, business users, etc.<br />
<br />
She clearly says that the entire team's goal is to improve a particular key metric and then makes sure that the team understands what that means. She then prioritizes which features should be delivered first while monitoring the metrics, and she keeps the team motivated to follow up by making progress toward the goal very clear.<br />
<h2>
Keep Engineers from Getting Jerked Around</h2>
How many of you have been working on something when a product manager has suddenly told you to stop working on that and work on something entirely different? How often does that have to happen before you become completely unmotivated? Not very often, right?<br />
<br />
Of course, sometimes things change. Bugs are found that need to be dealt with. Business people make new deals. Company priorities get shifted around. Organizations get shuffled.<br />
<br />
A good product manager protects her team from as much of this as she possibly can. She does this by pushing back on pressure from above to change priorities midstream. She does this by making sure that what her team is working on is important enough that she has a good reason to keep them on it, even if her boss suddenly wants something new and shiny. Sometimes she does it by making sure that there is somebody who can triage high priority bugs in order to keep the whole team from getting pulled off their work in the event of an emergency.<br />
<br />
A good product manager manages up as much as she manages down.<br />
<h2>
Do Jobs that Aren't Technically Product Management</h2>
Just because the word manager is in the title doesn't mean you're off the hook for actually building things yourself. This is especially true at startups, where there are very few people trying to do a whole lot of work.<br />
<br />
When I was working as a product manager, I frequently wrote copy, answered customer support questions, touched up images, built prototypes, consulted with the CEO on strategy, ran scrums, responded to people on Twitter, and made user research calls. Oh, and about hundred other jobs that had nothing to do with management.<br />
<br />
I did those things because they had to be done, and there was nobody else to do them, but I also did them because the act of doing them made me a better product manager. By answering customer support questions, I learned how users felt about the product and where they got confused. By touching up images, I learned how much time it took to do the job so that I could gauge how efficient other people were when they were doing it. By monitoring Twitter, I learned who was talking about my product and what they were saying. These things were all critical to doing my job well, plus it meant that we didn't have to hire a bunch of specialists to do these things.<br />
<br />
If you're not doing things outside of your normal job description, take a good hard look at whether you're really doing the most important parts of the job. I'll give you a hint, if what you're doing involves hours of meetings every week, there are more important things you could be doing.<br />
<h2>
This Sounds Hard</h2>
This sounds hard because it IS hard. Product Management <b>should</b> be hard. You're in charge of creating something. You have to make important decision affecting a huge number of people all the time. If you think it's all just going to meetings and making schedules for other people to stick to, you're doing it wrong. <br />
<br />
Like the post? <a href="http://twitter.com/lauraklein">Follow me on Twitter!</a><br />
Want more info on Lean Startup? Check out the <a href="http://workshops.leanstartup.co/">Official Lean Startup Workshops Series</a> I'm working on.Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.comtag:blogger.com,1999:blog-2199992789862129057.post-40016168576366309872012-12-28T19:06:00.003-08:002012-12-28T19:17:04.854-08:00A Perfect Use for PersonasI was reading <a href="http://news.ycombinator.com/item?id=4978719">Dave McClure's post about changes to menus (and its not always flattering Hacker News thread)</a>, and I found myself both violently agreeing and disagreeing with both. I kept thinking something along the lines of, "That would be great! Except when it would be incredibly annoying!"<br />
<br />
That's when I realized what was missing for me: personas.<br />
<br />
First off, apologies to Dave, who certainly doesn't need me to defend or improve his ideas. This is just meant to be an explanation of the process I went through as a designer and researcher to understand my weird, ambivalent reaction to his product suggestions.
Here are the problems that Dave listed in his post that he was solving for:<br />
<br />
<ul>
<li>Too many items, not enough pictures, simpler & more obvious recommendations. </li>
<li>Not online, no order history, no reviews, no friends, no loyalty program, no a/b testing. </li>
<li>Have to wait forever for waiter to order, re-order & pay. </li>
<li>Nothing to do while I'm waiting. </li>
</ul>
<br />
Then he presented reasonable solutions to these problems. All of the suggestions seemed geared toward making restaurants quicker, more efficient, and lower touch. Interestingly, both the Hacker News complaints and my own seemed to be from the point of view of people who do not have these problems. They were saying things like, "this would make restaurants awful!" but what they really meant was, "I, as a potential user, don't identify with that particular problem you're trying to solve, so your solution does not really apply to me."<br />
<br />
In other words, Dave's suggested solutions might be great for people who have these problems but might not appeal at all to people who don't have these problems.<br />
<br />
So, then I started to think about the types of people who would have those types of problems. I put together a few rudimentary personas of people who likely would benefit from things like recommendations, entertainment while waiting, a more efficient order process, and a faster way to pay.
<br />
<br />
As a note, these personas are behavioral, not demographic. This means that you might sometimes fit into one of them and at other times you wouldn't. It depends more on what you do than who you are.<br />
<br />
<h3>
</h3>
<h3>
The Business Person</h3>
Imagine that you're on a business trip to someplace you've never been. You're quite busy, and it's likely that you'll have to eat a few meals on your own, possibly on the way to or from a meeting or the airport. You're not a fan of fast food, so you'd rather be able to find something you like at an interesting local place than at a big national chain.<br />
<br />
In this instance you might LOVE having things like recommendations from people you trusted, pictures on the menu of unfamiliar dishes, and a quick, efficient ordering and payment system that guaranteed you wouldn't hang around for twenty minutes waiting for a bill. You might also really enjoy some entertainment so that you'd have something to do that wasn't stare creepily at the other patrons.
<br />
<br />
<h3>
</h3>
<h3>
The Barfly</h3>
Now imagine that you're at an incredibly crowded night spot. You are desperate for a bourbon, but you don't want to queue up five deep at the bar to try to get someone's attention. You manage to get a table, but now you have to decide whether to leave it to flag down one of the few waitresses or or just wait it out.<br />
<br />
In this instance you would almost certainly be excited to be able to order and pay directly from your table using some sort of tablet. You'd also be able to quickly order your second, third, and (dare I say it) fourth rounds without having to go through the whole process again or count on the waitstaff knowing exactly when to ask if you want a refill.
<br />
<br />
<h3>
</h3>
<h3>
The Group Luncher</h3>
Last one for now, I promise. You're out to lunch with eight of your coworkers. You need to get back to the office in 45 minutes for another stupid meeting. You don't want to spend 10 of those minutes just for a waiter to make it to your table and take your orders. Also, you really don't want to be the one in charge of figuring out how to split the bill, especially since three of your coworkers always get booze, one of them never eats more than a salad, and two of them order the most expensive thing on the menu.
<br />
<br />
In this instance, you'd be thrilled to be able to just sit down, punch in your order (and your credit card!), get your food delivered to you quickly, and get to spend more time chatting with that cute new person in accounting rather than negotiating who forgot to figure in tax to the amount they owe on the bill.
<br />
<br />
<h3>
And the rest...</h3>
There are probably a half dozen other hypothetical persona groups, all of which would obviously need to be validated (or invalidated) with various forms of user research and quantitative testing.<br />
<br />
The persona groups that aren't on this list are also important. Many of these types of innovations might make things worse for the types of folks who are enjoying the experience of being in a restaurant as an event. For example, a romantic dinner for two at a high end restaurant is not improved by shaving thirty minutes off the wait between courses. Other people might enjoy the personal exchange with the waiter or a consultation from a sommelier more than reading about items on a tablet.<br />
<br />
That's ok. These products aren't necessarily going to be for every type of restaurant all at once. There's no need to worry that suddenly Manresa is going to be putting pictures on the menu like Denny's.<br />
<br />
The reason I bring this up is that it often helps me to evaluate product ideas through the eyes of the people I expect to use the product. When I find myself saying things like, "Driving sucks! I'm going to fix driving!" I have to step back and realize that driving (like eating in restaurants) is an almost universal activity that has a constellation of problems, many of which are not shared by all types of drivers (or eaters). If you think your startup has a brand new product that's going to solve all the driving problems for stock car drivers, commuters, and truck drivers, I think you're probably wrong.<br />
<br />
Instead of arguing back and forth whether or not these problems exist, it's very easy to identify particular types of people for whom these problems MIGHT exist and then do some simple qualitative research to see if you're right. After all, we know at least one person (Dave) has these problems that he wants solved. Presumably Dave (or the companies he invests in) are doing the sort of research necessary to make sure that there are enough people like Dave to make a profitable market. That market might not include you, but there are lots of wildly successful products you don't like.<br />
<br />
So. Long story short: personas, yay!
<br />
<br />
<h3>
</h3>
<h3>
Postscript</h3>
For those of you who notice these things, you're right, I didn't include the personas for the other side of the equation: the restaurant owners. Whenever your customers (the people who give you money) and your users (the people who actually use your product) are different, you're in a much more complicated space from a user experience point of view. I'm assuming that, if we can make a specific type of end user happy enough it will make the types of restaurant owners who cater to those users interested in purchasing the product.<br />
<br />
That's just another hypothesis, and all hypotheses need to be validated, not assumed to be facts.Laura Kleinhttp://www.blogger.com/profile/00037358313958626151noreply@blogger.com