Are you designing/coding something with radio buttons or a drop-down menu? Stop!
I’m going to show you how taking an extra 30 seconds to identify the type of choice and presenting the appropriate defaults can save you a ton of errors, dropoffs, and customer frustrations.
Which of these describe your choice:
There is only one right answer, and that answer is obvious to the customer
Don’t set a default. For radio buttons or checkboxes, that means nothing should be selected. For dropdown menus, that means adding an explicit first option called “Choose one:” so that the menu doesn’t default to the first alphabetical choice.
There is only one right answer, and that answer is NOT obvious to the customer
Don’t provide options at all. This seems counterintuitive, right? If you’re asking a hard question, it seems like you should help the customer by telling them what the possible options are.
But what happens is that customers will simply choose an option at random, and if they guessed wrong, an error will happen. (Very bad if you are doing an emergency funds transfer to save yourself from overdraft!) It’s better to force them to type in an answer, which they will do slowly and with more care.
There are multiple acceptable answers, but you can guess which one would be preferable to the customer
Set a default and (preferably) explain why. I often hear product managers say something like “well, the customer should pick X, but I want to let it be their decision…” Guess what? People hate making decisions! If you know we should pick X, throw us a bone and pre-select X for us. Please. We will appreciate having that 5 seconds of my life and those 5 brain cells spared!
There is one answer that is probably right unless [some situation applies]
Set a default and explain clearly what that exception situation is. Offer an email address or more info icon so the customer can feel really sure that the situation does / does not affect them.
Popularity: 13% [?]
September 1st, 2011
View Comments
When you see a dropoff like this in one of your product workflows, it’s time to spring into action.
Here are the first 5 questions you should ask yourself:
1) Where is the dropoff happening?
Where the dropoff happens usually provides some clues as to why it’s happening:
- After the homepage: your homepage is crappy OR your potential customers are unqualified
- After being asked to pay: no one likes to pay, but more likely you haven’t communicated WHY they should well enough
- After being prompted to install or configure something: no one likes to spend time, but more likely you haven’t communicated WHY they should / reassured them that it’s safe and easy
- After step 4 or 5: seriously, how many more steps are you going to make them go through?
2) Can I spot the problem?
I shouldn’t even have to mention this, but I know I do. Go through your own product slowly and look at the place where you’re losing people. Is there a glaring browser bug? Is the call-to-action button missing? Is there some text missing that makes the flow really confusing?
If you know your product “too well”, it can be easy to miss even the giant gorilla running through the basketball game. A good way to overcome this is to sit down with one of your coworkers and “demo” the product to them, moving slowly and narrating your actions and reading the on-screen text out loud.
I just did a recent walkthrough of my own product and — embarrassingly — unearthed some awful copy, a call-to-action that was tiny and below-the-fold, and a payment flow that dead-ended. That led to some very quick changes that we could roll out even faster than proceeding to user feedback.
3) Is this a “usability” problem or a “decision” problem?
A usability problem means that customers can’t find the next step, can’t read the text because it’s too low-contrast, don’t know which widget to pick, can’t find the information on the page. You can usually learn about usability problems by putting any random “new” person in front of your software and asking them to complete a task while narrating it out loud. Throw usertesting.com at the problem or offer to buy someone their coffee at Starbucks if they’ll sit down with your laptop for 5 minutes.
A decision problem is where your customers are making a decision — to install your software, to sign up for your trial, to pay you money, to entrust you with their data, to contribute content to your site. The decision they make is highly dependent on their situation, how they perceive you, and what expected value they think they will get from you. You’re going to have to ask real customers, preferably while they’re on this page. Ask a KISSinsights question like “Is there anything stopping you from completing this purchase?” or “What additional information do you need in order to continue?”
4) Can I make the text shorter and clearer?
Writing good copy is hard, but it’s usually the fastest change you can make to your site. Based on the insights you got from your user test or survey question, what can you change about the existing text to make the purpose of this page clearer and easier to understand? And shorter — trust me, almost always, is better.
5) Can I add a screenshot or a video?
Most of the dropoff problems I’ve seen could’ve been improved with some more visuals. Even if the “real” solution is to reduce steps in the workflow or totally change how the customer interacts with that section, a simple picture or video can be a good stopgap measure.
Popularity: 10% [?]
August 25th, 2011
View Comments
I know, your app/service/site probably is better once I’ve invited my friends.
But here’s the thing: if you act like a jerk, I look like a jerk.
You’re asking me to take a chance with my social capital, without giving me any reassurance that you’ll behave appropriately. Are you going to email my friends only once, twice, or every single day? Are you going to send a cheerful email that provides context as to why they’re getting this email, or are you just going to splash “Cindy thinks you should check us out!!!” across the top of your boilerplate promotional content?
This doesn’t just apply to consumer social products, either.
I was talking with a customer once who had been considerate enough to screencast his walkthrough of our product with comments and questions — hugely valuable — but the file was too large for his corporate network to send via email and he wasn’t sure how to do file conversions. I scanned the website of a big file-sharing site and it sounded like as long as I had a paid account, another person could easily send me a file of that size. Sounds good, right? I entered my credit card and made the request…
This poor guy had to create an account, get 3 marketing emails and 2 upsell requests before he could just complete his one upload.
So, if you want me to invite my friends, include my network, or share, here’s what you need to tell me:
- What are you going to say to my friends? (Let me see the email.)
- When are you going to contact my friends? (Immediately? Whenever a specific trigger condition is met? At your discretion? <– Note: that last one sucks.)
- How often are you going to contact my friends? (Once? With a followup reminder? At the interval they choose? At your discretion? <– Note: that last one sucks.)
If you’re going to create a process between me and another person, here’s what you need to tell me:
- Who does what (you’re going to email my friend, my friend will come to the website and set up X, you will email me to come see X)
- Escape route (your friend can cancel at any time / set up preferences / you can revoke permission)
If it’s complicated to explain in words, draw a diagram.
But please, don’t assume that I’ll trust you. Because I don’t, and that lack of trust is what’s keeping me from being a customer.
Popularity: 5% [?]
August 18th, 2011
View Comments
Do you talk to the engineers you work with?
I mean, outside of specs, user stories, and meetings to review specs or user stories?
If you aren’t, you’re leaving a lot of untapped potential on the table and your company is losing a competitive advantage because of it.
I mean, you’re probably pretty smart. But unless you are also an engineer (and no, having come from an engineering background 5+ years ago doesn’t count — that’s like 35 years in Internet-years), you really don’t have a good sense for what is possible.
The little off-the-record conversations I have with our engineers are usually one of the highlights of my day. That really annoying product quirk that costs me an extra 20 minutes every day? Fixable with a 2-minute code commit. That ‘if only our customers could do X…’ idea? 10 minutes for an engineer to throw together a bookmarklet that solves it.
(And on the other side: that feature request that will be a beast to build? 3 minutes and we’ve negotiated a simpler version that can be built in half the time.)
Now, I’m not saying that engineers should be at the whims of product managers poking their heads over the cube wall with every wacky idea that pops into their heads. Pulling someone out of ‘flow’ when they’re coding might cost you 3 hours of productive time, even if your request “only” took 5 minutes.
But your culture needs to allow for asking questions and mentioning problems in an off-the-record way.
Engineers need to feel empowered to answer your question with “Nope, actually that would be a really tough change and hard to test” — without someone accusing them of being lazy. They also need the freedom to respond to your question with “Hey, it took me 2 minutes to build what you asked for!”
Product managers need to feel empowered to ask a quick question — without spending an hour going through official process and writing a spec. They also need the discipline to retract a request when it becomes clear that there’s a high time cost or high risk involved.
This is a big challenge when the culture isn’t in place. Far too many companies have an adversarial products vs. engineering culture — and whichever team dominates, the other team often ends up blamed for too many things and overly defensive. This makes it hard for this kind of conversation to flourish — but makes it even more critical. Because regardless of which way the pendulum swings, both teams have some crazy ridiculous stuff to put up with. Better to understand together, commiserate together, and problem-solve together than over the wall.
Popularity: 6% [?]
August 11th, 2011
View Comments
