UX in the wild: Amazon's Kindle app

I discovered a rather nifty UI mechanism a few days ago: a usable, elegant, and minimal control for locking and unlocking screen rotation. It was in Amazon's Kindle app on my Galaxy Nexus (though a quick check shows that it's in their iOS app as well).

In most apps I've seen, developers leave auto-rotation management up to the operating system. That is, there is no way to specify your auto-rotation preferences in the app itself -- it just honors the device's main settings. There is a small class of apps who manage it themselves, though -- mostly news or e-readers where users might want to read lots of text while lying on their side. For most of these, the user can lock or unlock the auto-rotation from some settings menu. This placement has some obvious UX drawbacks:

• Unless the user explores the settings menu, he may not know that the option even exists. This could make him stop using the app. 
• It's not easy to toggle on and off quickly -- with several taps required, it can be frustrating and possibly stop the user from using the app.
• It's impossible to know the current state of the rotation lock without checking. This is especially frustrating on older devices which have some lag before the rotation kicks in. Once the state is learned, then the user must navigate back into a menu and change the setting if necessary.

The rotation-lock mechanism in the Kindle app, however, solves all these problems in a simple way: Whenever you rotate your device, a little lock icon appears in the corner that is either locked or unlocked to reflect the auto-rotation state. If you wish to change the state, tapping the lock causes the rotation to adjust immediately. After a few seconds, the icon disappears.

This feature is easy to discover, easy to toggle, and easy to check. While it may have some small drawbacks for certain types of users, it appears to be an across-the-board improvement on the way this option is usually accessed and presented. It's really nice to see novel UI mechanisms continue to spring up in mobile -- and especially from big companies. Great job, Amazon!

(Note: I'm not sure how long this feature has been around because I usually disable auto-rotate in the entire device. It's new to me, though, and good UI makes me happy.)


Hire me, and I'll create innovative user interfaces for your app ! I'm available for full-time or consulting work -- email me. 

How to write great user surveys - Part 6

This  is part 6 of my series on writing a good user survey. If you're just joining us, you may want to start with part 1.

Polarizing Questions

It's worth noting here that there are some situations where you do only want one bit of information from your users: is your site/product/whatever acceptable or not? I suspect that this is often the motivation behind polarizing questions like my example above. The key to asking polarizing questions safely, though, is to divide the solution space into exactly two parts. This is usually easiest by asking very general questions with general answers or very specific questions with very specific answers. Here's a general example:

How does our site make you feel?

• :-)
• :-(

This question is about as general as it gets, but it can accurately condense a huge variety of complex feelings into two simple options -- good enough or not.  Ikea.com uses lots of smileys (and frowny faces) in its surveys. This can be very effective if used properly -- it's just important that you're careful not to read too much detail into what your user meant by selecting :-) .

Now here's a specific example:

Are you satisfied with how Gmail handles sending and receiving email?

• Yes
• No

When you ask specific questions, there's still going to be a little variability in the accuracy of the answers. For this example, some users expect wild innovation and are satisfied with nothing less. Those people may have a perfectly acceptable Gmail experience but still consider themselves dissatisfied. But the more specific you get in your questions, the more you can combat that effect. Consider this even more specific example:

When using Gmail, are you usually able to send and receive emails without problems, errors, or frustration?

• Yes
• No

Even users with the highest expectations for innovation and UX excitement would have trouble saying no to that question. (Assuming that they aren't having problems sending and receiving email, that is). By being more specific, you've restricted their feedback to only what you want to know: is it good enough or not.

Now let's look at some examples of polarizing questions that aren't specific enough:

• Are you satisfied with Gmail? (Gmail does lots of things -- is this question asking about all of them or just email?)
• Does Gmail meet your needs? (Needs for what? Integrating with Google Calendar? Accessing mail on your phone? Handling multiple accounts? Almost everybody will have a complex answer for this.)
• Do you like Gmail? (In an absolute sense? Relative to its competitors? Including all its features?)
• Are you able to accomplish your goals with Gmail? (What goals? Email only? The rich-text editor? Attaching files easily?)

If you find yourself asking a polarizing question, your first thought should be "Am I sure that this has to be polarizing?" If 25% of your users think your product is "meh" and you want them to select "good" or "bad," don't you want to hear from those meh users? That's useful information, and you're spending time and money to get their opinions.  Why would you throw that away by trying to get a polarized answer? Furthermore, making the “meh” users choose will introduce secret inaccuracies to your results: you’ll have no way of knowing how many respondents are actually giving you their true opinion. What if it’s 50%? What if it’s 80%? You won’t know.

Having no information on your users is bad, but having false information can be much, much worse. You should think very carefully before going this route.

Tomorrow in part 7 I'll cover one last way that poor answer options can give you bad data.

--
This is part 6 of my series on writing a good user survey.  If you want to start at the beginning, head back over to part 1.

Hire me, and then I'll write your next survey! I'm available for full-time or consulting work -- email me. 

What every entrepreneur should know about writing user surveys - Part 1

I've been working on a series of posts about how to do a site redesign without making your users hate you. We all know that redesigns are a lightning rod for hate and abuse, but there are lots of ways to mitigate that. As I was writing it, though, I realized that I really need some data to back me up. I know what I find frustrating in a redesign, and I hear from my friends and Hacker News commenters, but we're not exactly a typical cross section of society. So I did what everybody should do when they want some quantitative user data: made a survey!

I really like taking surveys. Who doesn't love giving an opinion to people who want to hear it? Writing a good survey question is a really important aspect of being a user experience designer, and it was a really fun part of my HCI curriculum in college. So whenever a little popup window asks me to tell it about my site experience, I usually say yes. For me, half the fun is seeing how the survey was designed and thinking "Good job, UX guy!" (Sadly, it is a bit more common that I shake my head and think "You guys should have brought in a UX person to write your surveys.") But that's okay; I'm here to help!

Step 1: Figure out what you want to find out.

This part doesn't have to be formal or grammatically correct or well written. Just write down your goals using regular language. Here's what I want to find out:

• I think lots of people are bothered by redesigns. Is that true? How many people are?
• For people who are bothered, what things bother them about it?
• Does an irritating redesign make them feel that the company doesn't care about its customers?
• What do they wish the company had done differently?

Step 2: Find the squishy parts of your questions.

 What parts of these questions are squishy? Let's focus on this one:

I think lots of people are bothered by redesigns. Is that true? How many people are?

When I wrote that question, those terms (in bold) felt pretty reasonable and solid in my head. As soon as I begin making a survey out of it, though, I have to make sure that each term gets translated into a precise or quantitative phrase. Let's look at each of my squishy terms above and how they could cause problems:

• "lots of people" - Is that a percentage of... people on the internet? Percentage of your users? Percentage of people who may someday become users? Whose opinions do you actually care about? Figuring out the precise definition of "lots of people" here will determine who actually takes your survey. This may in fact be the most important part of your survey to get right, since getting it wrong can mean that your whole survey was a waste of time. In addition to wasting your own time as the survey-maker, it also wastes your users' time and any costs the survey incurs (such as a user discount for taking the survey in the first place). Furthermore, only some of your users will want to take a survey at all, and of those, many don't want to take two in a short amount of time. So if you squander their survey goodwill, you may have to wait several weeks or months for it to recharge before they'll take another one.
• "bothered" - This could mean practically anything -- from "it took me thirty extra seconds to send an email" to "your changes prevented me from paying my bill on time, I got a credit hit, and now I'm irate!" If you want your survey results to be useful and accurate, you need to close your open-ended terms. Though there are some exceptions to this -- if you want to hear about the entire range of experiences from "slightly inconvenienced" to "because of you my home loan was denied," then this kind of broad term can be okay. But if you plan to distinguish between those two ends of the spectrum when you're looking at the data later, it's wise to add an expository question afterwards. Such as: "On a scale of 1 to 10, how unhappy did this make you?"
• "redesign" - Most of your users are probably not Silicon Valley entrepreneur hopefuls. Someone in Mississippi may not have the precise ideas in their head that you do when it comes to technical or business language. To someone who's in a different sphere, a "redesign" could mean a new color scheme, a new comments system, a new feature, or just a new navigation bar at the top of the screen. In the context of the particular survey that I'm creating, that sort of ambiguity might not harm the data too much, but it can be very harmful in other contexts. Terms like "redesign" need to be defined before asking the user any questions about it.
• "how many" - Do you want to know how many people have ever experienced a frustrating redesign? That's probably a pretty high percentage if you're asking about all the redesigns they've ever encountered in their lives. That's also probably quite a different number than the percentage of people who find most redesigns frustrating. You can get hugely varying survey results from two similar-sounding questions: "Do you find site redesigns frustrating?" and "Have you ever been frustrated by a site redesign?" 

Check back tomorrow for part 2, where I'll discuss how this qualitative language can be fixed.

--

Hire me, and then I'll write your next survey! I'm available for full-time or consulting work -- email me.