Recently, 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.
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.
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: UXD for Developers.
In my episodes, I cover an Intro to Lean UX and Qualitative vs. Quantitative Research for UX.
New episodes are released every Tuesday, so make sure to subscribe to the channel to get all the updates!
Tuesday, January 21, 2014
Friday, October 25, 2013
How 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.
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.
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.
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.
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.
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.)
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.
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.
Like the post? Follow me on Twitter!
Like the post but wish there were more of it? Buy the book!
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.
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.
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.
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.
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.)
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.
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.
Like the post? Follow me on Twitter!
Like the post but wish there were more of it? Buy the book!
Monday, October 14, 2013
Stop Making Users Explore
Often, entrepreneurs ask me something to the effect of, “What’s the best way to let new users explore my product?”
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.
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.
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.
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.
Nonsense.
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.
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.
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.
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.
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.
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.
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.
It’s not about exploration of the product itself. It’s about getting you involved with the things the product is selling.
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.
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.
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?
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.
Like the post? Follow me on Twitter!
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.
Users Don’t Care About Exploring Your Product
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.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.
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.
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.
But What About B2B Products?
I know, I know. B2B products are different! They’re more complex! They have so many features! They require training and exploration!Nonsense.
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.
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.
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.
But...but...but...Games!
Nope. Sorry. Still very little open exploration for new users.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.
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.
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.
E-Commerce?
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.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.
It’s not about exploration of the product itself. It’s about getting you involved with the things the product is selling.
What Should You Do Instead?
Stop thinking about letting users explore your product. In fact, stop thinking about letting them do anything at all.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.
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.
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?
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.
Like the post? Follow me on Twitter!
Want more advice like this?
How about buying the book? It will help you learn how to build great products. I promise.
Wednesday, September 4, 2013
The Best Way(s) to Learn Lean User Research
I'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.
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.
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.
The first third of my book, UX for Lean Startups, 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.
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.
If you would like to sign up to be the first to hear when these guides are available for purchase, go here and sign up.
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 laura@usersknow.com.
If you'd like something to read in the meantime, did I mention I'd written a book?
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 sign up here.
And if you still have questions, you can reach me on Clarity for a quick call or sometimes hire me to consult, depending on my availability.
You know what this means, right? It means that pretty soon you will have absolutely no excuse for not learning from your users.
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.
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.
The first third of my book, UX for Lean Startups, 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.
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.
If you would like to sign up to be the first to hear when these guides are available for purchase, go here and sign up.
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 laura@usersknow.com.
If you'd like something to read in the meantime, did I mention I'd written a book?
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 sign up here.
And if you still have questions, you can reach me on Clarity for a quick call or sometimes hire me to consult, depending on my availability.
You know what this means, right? It means that pretty soon you will have absolutely no excuse for not learning from your users.
Tuesday, September 3, 2013
Don't Allow Behaviors. Encourage Them!
I wrote this post for the O'Reilly Programming Blog. Here's an excerpt:
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.
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.
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.
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.
Read More at O'Reilly >
Read More at O'Reilly >
Monday, August 5, 2013
Maybe You're Just Delusional
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.
“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.
The sad thing is that vision and customer feedback don’t have to be at odds.
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.
Vision #1
“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.”
Vision #2
“Some pet owners are upset about how much their pets cost. This product is going to make it more affordable to have a pet.”
See the difference? I mean, besides the fact that the first one is completely delusional?
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.
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.
But the most important thing to note is that the second vision is entirely compatible with user research.
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!
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.
Then listen to your users. Observe them. Learn from them exactly how you can solve their problem.
That’s the best way to make sure that your vision becomes a reality.
This was written for Startup Edition. The question was, "How do you balance user feedback with your long term vision?"
This was written for Startup Edition. The question was, "How do you balance user feedback with your long term vision?"
Want more information like this?
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.
Wednesday, June 19, 2013
Mobile 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!
Why "flow" and "context" are more important than screen size."
Here's an excerpt:
Are we done with the Mobile First meme, yet? Can we be? Please?
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.
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.
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.
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.
Those two things are: Flow and Context.
Read the rest at the O'Reilly Programming Blog >
Why "flow" and "context" are more important than screen size."
Here's an excerpt:
Are we done with the Mobile First meme, yet? Can we be? Please?
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.
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.
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.
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.
Those two things are: Flow and Context.
Read the rest at the O'Reilly Programming Blog >
Want more information like this?
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.
Subscribe to:
Posts (Atom)