When To Get Help With User Research

I don't spend a lot of time on this blog telling you why you should hire me to talk to your customers. In fact, the vast majority of the posts are meant to make it more possible for you to talk to your customers without hiring somebody like me. It's not that I don't like working. It's just that I think that anybody who is responsible for making decisions about products should know how to learn from users on their own. It results in better products for all of us.

Product owners need to be involved in customer research for a lot reasons. Reasons like:

• You're more likely to believe the results if you participated in the research.
• You're more likely to understand the relative importance of customer problems if you observed the problems happening.
• You will come up with more comprehensive solutions to problems when you understand the context in which they're happening.
• It's far too easy to ignore a report written up by a usability consultant, it's incredibly easy to forget to watch the testing videos.
• If you do it yourself, all of the lessons you've learned will stay within the company, long after a consultant has gone on to other projects.

That said, I'm about to tell you why you may need to hire somebody like me. For a little while at least.

When I talk about customer research or customer development or learning from customers, I really mean quite a lot of different techniques. Sure, there are general best practices around talking to customers, tips for improving your research skills, and important things you should avoid, but there are also things like picking the right testing method or tool that you almost certainly have no experience with. You need to know what is the most important thing for you to do right now.

Do you know when it would be helpful to do a card sort? A journal study? A contextual inquiry? Do you know when it's fine to do a remote usability study vs when you should really run one in person? How about when your product will benefit from using an online tool like usertesting.com or fivesecondtest, and when something like that isn't useful? Do you know what sort of testing to do in order to find out why specific metrics are lower than you'd like? Do you know when you should start your visual design and when you need to concentrate on usability? Do you know how many people to talk to in order to answer a specific question? Do you know at what points in the development cycle talking to users is critical and when it's a waste of time? Do you know how to take several hours of free form user conversations and turn it into a small number of features or bug fixes that can be communicated to your engineering team?

If you answered, "of course I know that" to all of those questions, then move along. You almost certainly have no use for somebody like me to come in and help you out. If you answered, "I'm going to learn the answer to all of those questions," then I wish you good luck on your journey of discovery. I'll warn you though. There are more questions just like those.

If, on the other hand, you said, "I don't know the answer to a lot of those questions, but I wish somebody could help me understand the small subset of them that matter to me, as a product owner, so that I could get on with the business of building a great product," then you might want to give me (or somebody like me) a call.

Because it's true that there is a huge amount to know about talking to your users. But it's also true that, at any given stage in your product development, you probably only need to be concerned with only a little bit of it. And, it's also true that figuring out which bit of it you need to know can be really hard to do without help. That's where people like me come in handy. We can help you figure out what to do next, and then we can help you learn how to do what you need to do next.

But be careful. If you're a lean startup, you probably don't want to pay us to actually do what you need to do next. For all the reasons I mentioned above, that's still your job.

Interested in this sort of service? Learn more about Users Know here.

Want to read more posts on how to do this stuff yourself? Follow me on Twitter!

Shut up, and Show Me Something

I admit it. Quite often on this blog I give you long lists of fairly hard things to do. I ask you to change your whole approach to design or product management or customer interviewing or analyzing data. But not today. Today, I share with you one simple thing that is easy to remember and will transform your entire approach to customer research.

Ok, maybe it's not quite that cool, but it really will help you communicate with your customers better. Are you ready? Here it is:

Never have a conversation with a user (or potential user) where you don't show them something.

That seems simple enough, right? But why on earth should you do it, and what could you possibly show them?

Reasons for Communicating with Customers

Let's back up for just a moment. The main reasons that people generally talk with a user are:

• To get information from them - what they like, what they don't like, what's confusing, why they're not buying things, etc.
• To give them information - here are the features of the product, here's how to fix your problem, we swear it's a feature and not a bug, etc.
• To sell them something - whatever it is that sales people do...besides drinking heavily

All of these things are much easier to do when you're looking at visual aids.

Getting Information from Users

Let's perform a thought experience. Without thinking about it, name three things you hate about doing your taxes. Were you able to do it? Of course you were. If you can't think of three things you hate about doing your taxes, either you're not paying attention, or your hiding all of your money in an offshore account in the Caymans. But are they really the three worst things?

Probably not. They're just the three things that you happen to think about when put on the spot. Next tax season, you'll be doing your taxes and think to yourself, "Oh right, THAT thing! I hate that thing! I wish I'd thought of that when I was asked for three things I hate." And you most likely would have thought of it if you'd been going through your tax preparation software when I asked.

Sure, you can just ask users what they like and dislike about your product, but you will get much better information if you're both looking at the product together. Even better, ask them to perform some tasks or just use the product while you watch. This not only jogs the user's memory about all the little annoying things that they're sort of used to, but you can also observe all the things that they don't even notice or are too embarrassed to mention they're having trouble with.

Nobody is Thinking About Your Product

When you're working at a startup it can be all-consuming. You can forget everything else in your life pretty easily when you're neck deep in valuations and minimum viable products and customer acquisition and a million other things that need your attention. You tend think about your product every waking minute.

That's why it can be such a shock to realize that nobody else is thinking about your product. Well, ok, unless you're Apple, but there's clearly some kind of weird mind control thing going on there. In general, when you have a new product, you're incredibly lucky if you're getting more than a few minutes of attention from anybody but your most passionate early adopters.

Why is it important to realize this? It's important, because it has a really big impact on how you design your product and connect with your users.

Make Everything More Discoverable

You know exactly where in the user interface to go to do every task that can be completed with your product (I hope!). Other people, especially new users, don't even know that most of your features exist. This means that it's just as important to design for discoverability as it is to design for usability. But how are they different?

Let's do a quick thought exercise. Imagine somebody hands you a featureless metal box. You might look at it for a minute or two. If it's particularly attractive, you might admire it, but you're probably not going to spend a lot of time with it. Now imagine that the box has $10,000 dollars inside of it. You will probably spend a lot more time figuring out to get it open, yes?

Your product is like that box that is hiding money. If people don't discover very quickly that it provides something valuable to them, they're not going to spend much time figuring out how to use it. You need to help people understand immediately that your product has features they really, really want. That's discoverability.
You also need to make it pretty easy to actual learn how to use those features, once they've decided to dig into the product a bit. That's usability. For bonus points, you can make the whole process interesting and engaging so that people actually enjoy discovering features and using your product. That's fun. 

Key Take Away: Users are not going to spend any time learning to use your product if they don't immediately understand what's in it for them. Make it easy for them to figure out what features exist and why they're useful.

Some Surprising Problems Caused By Using Your Own Product

We've all heard the stories of huge companies that started because the founder wanted to do something specific but didn't have the proper tools. He or she built the proper tools and quickly realized that he or she wasn't the only one who wanted those tools. Paul Graham wrote a very interesting blog post about what he calls organic startup ideas a couple of months back and why building something you need is often the best way to start a company.

There are a lot of benefits to being your own product's first and biggest user:

• You will always have at least one person who likes and uses your product
• Even if nobody buys it, you'll still be happy you built it, since you get to use it
• You always have a user available to consult on which feature to build next
• It should be easy to initially identify a target persona (hint: you may need a mirror)
• You probably have a network of similar people who may also want the product
• You can find a lot of bugs and corner cases by using your product on a regular basis

But there may be a few problems that you weren't expecting.

Understanding the New User Experience

Frankly, there is nobody worse at figuring out how confusing the new user experience can be than an expert. And, if anybody is an expert at the product you've built for yourself, it's YOU.

Have you ever tried to explain something "simple" to somebody and realized that it isn't, in fact, simple at all? It is extremely complicted with lots of steps. The only reason you think it's simple is because you've done it a million times. Unfortunately, it can be very difficult to assess how hard it is to learn something once we know too much about it.

For example, if you already know that a feature exists somewhere in the product, it's much easier to figure out where it is than if you're brand new to the product and have no idea that the feature even exists. It's also easier to understand the logic of how different features work together if you're the one who put them together in the first place. 

The fix: Luckily, there's an easy fix for this. Watch new users with your product. Select people in your target market and just observe their struggles. Use products like usertesting.com to observe the first 15 minutes of their usage. Get in touch with people who have only used your product a few times and ask if you can watch them (not in a creepy way), in order to understand what slightly more experienced people are doing with your product. Whatever you do, when you see somebody making a mistake, don't correct them! It's important to see how people who aren't you are using the product.

Asking for Feedback

Remember all that stuff I recommended you do for new users? You should also be doing it for much more experienced users too. The problem is, you probably won't.

In my experience, people who are big users of their own product are less likely to think that they need to observe customers because they have one right there in the building! It's hard to admit that you don't know everything about a product that you're both building and using extensively.

The issue here is that you're not the only type of user. You may not even be the main type of user. When Twitter was first developed as an internal communications tool, do you think that the creators thought that Ashton Kutcher would one day be using it to tell his fans what he had for lunch? People are out there doing really surprising things with your product. You need to learn what they are, and you can only do that by talking to them and observing them.

The fix: This one's easy. Just make sure to keep getting feedback from other users. Preferably, search out people who are different from you or who are using your product in very different ways.

When You Should Hurt Your Users

I'm going to let you in on a little secret. I don't always do what's best for users. I know, I know. This is a horrible thing for a UX person to admit, but it's true.

This shouldn't come as a surprise to anybody, but it's shocked enough of my clients that it bears stating clearly. As an interaction designer, my job isn't (or at least, it shouldn't be) always to optimize everything exactly for the end user. There are several reasons for this.

The Best Thing For the User May Be Bad for Business

One of my favorite Dilbert cartoons explained that what users really want is "better stuff for free." As much as I dearly love to help the end user, my clients would quickly go broke if I gave users everything they wanted. A big part of the UX job should be balancing what is best for the user with what is best for the business. Sadly, those aren't always the same thing.

What does this mean in reality? It means that every time you see a banner on a free site, some UX designer accepted the necessary evil of showing an advertisement for acai berry in return for offering content for free. It means that sometimes a pricing page will be designed to showcase a more expensive option than the user might otherwise have chosen. It also means we have to work extra hard to identify features that are good for both users and the business (for example, features that make current paying users happy and thereby increase retention), so that we don't always feel like we have to sacrifice either revenue or customer happiness. 

Caution! This can go too far in the other direction. I would argue that a lot of Facebook's recent privacy debacles have been driven by optimizing too much for the business and not enough for the end user experience. The result of this, of course, can be losing end users, which can end up being bad for business in the long run.

Getting It Out There May Be Better Than Getting It Perfect

Nothing is perfect the first time it's released. If it is, you probably spent too much time on it. And sometimes the very best solution for the user is impractical for a lot of other reasons.

What does this mean in reality? Well, it means that if the absolute optimal solution for end users will take 6 years and a team of 20 geniuses to implement, I will try my hardest to find the next best alternative. I'm not saying I'm going to settle for a bad user experience. I'm just saying that there are a lot of different ways of making the user happy, and if it can be done without killing the engineering department, that's a bonus. 

Caution! This does not mean that you get to ship a bunch of crappy features and then never touch them again. If I give you a pass to deliver a suboptimal first version to the user in the interest of time and engineering effort, I expect that it will be iterated upon and improved in the very near future. It may never be perfect, but it had better improve!

When Talking to Customers Isn't Enough

A few weeks ago, I was talking to the head of a small company about next steps. His company had a product with many happy, paying customers, and he wanted to know what to do next to make his current customers happier and attract some new ones.

The company had already made a good start. They had done surveys of current users asking the standard questions like, "How disappointed would you be if you could no longer use this product." They'd even surveyed current users about what new features they would like to see. The problem was, the happy customers couldn't think of anything else they wanted, and while the slightly less happy customers wanted some new features, there was no general consensus on one big, missing piece or fantastic new idea. So, the CEO wanted to know what to do next.

I believe this can be a problem with the "go out and talk to your customers" solution to product development. We can get so focused on talking to customers that we forget that it's not always the best way to figure out what to do next.

Observe Your Customers

Customers lie. They don't always mean to lie, but it often ends up that way. It's especially problematic when you ask people to explain how they currently use your product. Sometimes they forget parts of their process, or they don't even realize that they're doing certain things because it's all become so routine. Also, they tend to explain their process of using your product from start to finish, as if they weren't doing seven other things while trying to use your product. This can give you a totally skewed vision of what people are actually doing with your product.

What's the solution? Go out and watch them. Sit with them in their offices or homes and observe their real behavior. Most importantly, watch what they do immediately before and after they use your product.

I was talking with somebody who used to work for a marketplace that allows people to buy and sell products directly to each other. While observing users, her team noticed that, while people had very little trouble using the marketplace itself, the sellers spent a huge amount of time arranging shipping of the items. In fact, the shipping process took so much time that it limited the number of items they could list. By integrating with a shipping company to help customers print labels and schedule pickups, the company increased the number of items that could be listed which increased revenue.

Why didn't users ask for that? Well, the customers had a particular way of doing things. They thought of the marketplace as a place where they could buy and sell things, not as a product that helped them mail things. They had another solution that helped them mail things, and they didn't know that there was a better way to do that until they were presented with it.

How Many Features Does it Take to Destroy Your Product?

I work with a lot of startup founders who are extremely excited about their products. This is unsurprising, since nobody in their right mind would launch a startup without being totally convinced that their product is going to be awesome. It’s just too much work and risk for something that you aren’t passionate about.

Passion in startups is a great thing. It can also be incredibly dangerous.

The story is the same with pretty much every group of founders I work with: they have hundreds of great feature ideas for their product. Let me be clear: HUNDREDS of great feature ideas. Don’t get me wrong, many of these are genuinely great ideas. Almost every time I hear one, I think, “Wow, that would be really nice to have in this product and would add a lot of value.”

Unfortunately, starting a product with all of those features causes a lot of problems.

More Features = More Time to Build

Imagine building a house that includes a single room vs. one that has twenty rooms on three floors. There’s a lot more work, design, and planning that needs to go into the bigger design to make sure that people don’t get lost and that the house won't collapse.

This may seem obvious, but building one feature takes a lot less time than building ten. And the more time you spend building your initial product, the longer it takes to start getting metrics from actual users. Sure, you can and should start getting feedback from people using mockups and prototypes, but nothing beats actual data from your real product in the hands of users.

More Features = More UX Complexity

Remember that 20 room house? It has a lot more windows, doors, staircases, and electrical outlets than the one room place. It can be hard to find a reasonable place for everything. The more complex your product is, the more challenging it can be to present all of your features to your users in a usable way.

It’s hard to design a product that has a lot of different features. Everything needs to have an obvious, findable place in the product structure. All the features need to fit together in such a way that a user never gets lost or confused. Starting with a couple of key features keeps the overall UX much simpler and vastly reduces both your design time and the chances that your product will look like a giant mess.

More Features = Less Clear Value Proposition

Ever come to a web site or opened a product and thought, “What on earth does it DO?” Generally, the culprit is a confusing jumble of features, menus, buttons, and calls to action that prevent you from understanding the main value proposition of the product. Sure, companies try to combat the problem with wordy feature descriptions, video tutorials, and on-rails first time user experiences, but those often make things worse.

The simple fact is that the fewer features your product has, the easier it is for a new user to immediately understand what your product has to offer them. When all you have is new users, making sure they don’t get confused and leave is a pretty high priority.