As a product owner, you’re intimately familiar with every part of your app. Unfortunately that means that you’re too freaking smart for your own good. There are some huge pitfalls that come from knowing too much, so sometimes it’s best to start by forgetting what you already know.
When you approach the results of user testing with a clear head, you’re in a better place to be able to understand what those results mean. Bear in mind that the result is simply a data point. The condition which caused the result is what you’re aiming to fix.
So with the help of a few anecdotes from FullContact’s Product Manager Matthew Hubbard, here are the most important things we’ve learned, and how they changed our user testing strategy.
The Problem: One thing that we know for sure around the FullContact office is that communication is paramount. But there are some issues that we’ve discussed so often that we take the communication surrounding them for granted. For instance, when the FullContact address book takes multiple contact listings and merges them into one complete view, we call that a Unified Contact.
But our users had no idea what unified contacts meant, because we didn’t explain it.
The Solution: Go through every piece of language that you use in your application. Could it be simplified? Have a completely non-technical person look at your app. What do they call a certain feature? Chances are good that their terminology is going to be different than your own. Listening to them can give you a totally different perspective on not only what they call something, but also what they expect it to do.
Paint a Picture
The Problem: Icons can be a developer’s best friend. They’re an easy way to explain a feature. But as a product owner you have to bear in mind that your users aren’t necessarily as technical as you or your team are. Maybe it’s the Google+ icon, or something like the dreaded “hamburger” menu icon. Unless your user has a clear picture of what touching an icon is going to do for them, they’re going to be confused at best.
The Solution: Look over your icon use. Are you only implementing ones that are universally recognized? If so, is there any way that pushing the icon could lead to an unexpected action? If so, it’s time to reevaluate your design.
Show, Don’t Tell
The Problem: People don’t read. As Matthew pointed out to me, “you can build the greatest tutorial in the world, but most people will skim through it at best”. For whatever reason, people just don’t want to take the time to read about what they’re using.
The Solution(s): So how do you, as a product owner, combat that behavior? There are two methods that we’ve found to work very well:
Show, don’t tell. For instance, when you look at the FullContact home page, you’ll notice that we have a graphic that shows social media icons floating into your address book. That gives you a clear indication of part of what FullContact does.
The second method that we’ve found to work very well is to skip the introductory tutorial. People tend to learn better when what’s being taught is done in context. So if a user doesn’t touch a feature for the first six months, they won’t ever see a tutorial about it. But the first time that they start to use it, they’ll get an unobtrusive introduction to what the feature does and how it works. This helps to make sure that the topic is fresh in their head, and contextually relevant to what they’re trying to do right now.
Be a Leader
The Problem: Building a product is hard. We’re all looking for ways to make the process easier. But there’s a notable difference between something being easy and something being effective. While the two paths do sometimes converge, the easy road isn’t necessarily always going to be effective.
The Solution: Use the pull, don’t push methodology. It’s something that we talked about before as a way to make your team more effective, but it translates equally as well to your application design and testing. The easy road looks like this:
- Get them to sign up.
- Show them a tutorial.
- Let them use the app.
The effective road looks a bit different:
- Get them to sign up.
- Show them what’s important for their first steps via a short tutorial.
- Show them how to use each feature, but only when they start to actually use it the first time.
- Give them a task that answers the question of “what do I do next?” at every point where this makes sense.
The difference between a customer who signs up and then abandons and one who turns into an DAU (daily, active user) is often as simple as simply telling them what they need to do next.
Sometimes the hardest part about user testing is the need to fall out of love with your product. Everything that I pointed out in this post happened because of assumptions that we made as the product’s creators and not as its users. So stop thinking like a product manager for a bit and start thinking like someone who’s never used your product – or even someone who’s never touched a computer.
Forget what you know. Talk like your customer. Give examples. Lead the way. Four simple behaviors that can mean the difference between a good product and a great one.