I was visiting at a senior living community lately, and saw a great low-tech security device.
Question: What was your favorite teacher’s youngest child’s first pet’s name?
Answer 1: StupidQuestion TeacherPet Booyah
Answer 2: Green polka dots
See why, below
As part of account creation, many sites require you to answer secret questions. This isn’t only for security. It provides a self-service way for you to reset your password, which is easier for the company, and maybe for you, too. (Remember when you used to call customer care for things like this?) But security questions can be hard to design and use.
Problems with security questions
A system must present users with enough questions so they can pick a couple to answer and remember. Here are some questions and categories that can cause problems:
- “Where was your first kiss?” I’ve seen this make some people laugh, but embarrass others.
- “What’s your favorite …?” Preferences change often, so answers are hard to remember.
- “What was your phone number growing up? Let users know if hyphens, parentheses and spaces count.
- “What’s your youngest child’s first name?” If you have another child (or have none), this won’t work.
- Marriage dates, location or attendants. Not everyone is married.
- Pet names or types. Some people don’t have pets.
Here are some real examples: the first is from Yahoo.com, the second from BarnesAndNoble.com. How many questions could you answer now and remember later? How many just leave you scratching your head? [Images aren't uploading. Working on it. Sorry...]
And there’s the question of whether security questions are useful at all. GoodSecurityQuestions.com points out that
The reality is, security questions present an opportunity for breach and even the best security questions are not good enough to screen out all attacks. There is a trade-off; self-service vs. security risks.
People who know you may know enough to answer your questions; people who don’t know you may be able to find out the answers (how many people on Facebook and LinkedIn know what schools you went to?).
I just came across an interesting example at the Minor League Baseball sites. When I indicated that I’d forgotten my password, I got this screen. Oddly, I had to pick which security question I’d answered and then answer it. As if I could remember that! [Added 25 Sep 2012]
Solutions for users answering questions
One of my most interesting ideas I came across is to answer a completely different question. You might use “green polka dots” when the question is “What street did you grow up on?” That’s harder for someone to guess, but harder for you to remember unless you use it everywhere (which isn’t secure).
Danah Boyd, writing on Apophenia, suggests combining a “snarky bad attitude phrase” with a clue from the actual question, plus a unique word. For example, she writes “when I’m asked the following question: What is your favorite sports team? My answer would be: StupidQuestion SportsTeam Booyah“.
Solutions for designers picking questions to include
Here are some tips for selecting questions for your application:
- It’s OK to have some questions that don’t apply to everyone, but have enough choices so everyone can comfortably use a few.
- Questions shouldn’t be so obscure that people have to write their answers down.
- Answers shouldn’t be too easy for someone to figure out.
- Answers should be unique — there should be just one.
- Answers should be stable over time, unlike favorite things.
- Have reminders about punctuation and case, both for initial and subsequent entries.
- Consider allowing people to specify their own questions in case none of the provided ones work.
Usability testing helps
It may seem trivial to test security questions, but it does help. We got some good feedback in a recent project and changed the questions in our list. There’s nothing like showing your work to real users.
User reactions to self-service features: Is it “Hey, I already have a job, I don’t need to do yours, too”?7 Sep 2012
Companies obviously want to cut down on calls to customer care centers to save money. One way is to allow (force?) users to do more things themselves. We’ve been recovering passwords ourselves for a long time, and many products include other self-service tasks. Even libraries allow patrons to check out their own books.
In a recent design project, I was afraid that customers would dislike the self-service tools we were adding. I thought they might have the same reaction that I have to self-checkout lanes in stores: “Hey, I already have a job. I don’t want to check out and bag my own stuff here!”
But that wasn’t the case. Our users liked the new self-service tools.
We talked with a lot of users in usability studies and customer visits. They mostly had gotten good results when they called for assistance, but it seemed easier to do things themselves.
Calling customer care may seem like more of an interruption, while doing something yourself may seem more like an extension of what you’re already doing. Making the call requires a lot of work:
- Deciding that the problem is big enough to bother someone about
- Wondering if there’s enough time for the call
- Finding out if customer care is available
- Looking for the phone number & making the call
- Going through the voice menu
- Waiting on hold
- Explaining the problem, discussing it and maybe being transferred.
- … and then finally getting a solution
The early results for this product are good. It seems that customers are doing more tasks themselves, and the company is getting fewer phone calls.
Have you noticed that you’re doing more things yourself on the Web? What do you think about it? Are companies forcing you to do their work, or is it a time saver?
The City of Boston recently announced the Boston Meter Card, a prepaid card to use at parking meters. It’s a great idea, but it was impossible for me to figure out because the card doesn’t work the way other cards work. You have to insert the card and keep it in the meter for 10 to 15 seconds.
How do you think it works?
What would you do when you walked up to a meter with the card? I thought about which way to put the card in, inserted it, took it out, and… nothing.
I was there with someone else, and we couldn’t figure it out. Was the card broken? Was the meter broken? What else could I have done?
It doesn’t work the way you’d expect
When you insert the card, you have to hold it in for 10 to 15 seconds and wait while the small display updates a number of times. But you knew that, right?
Problem #1: It doesn’t work like any other card I use. I couldn’t figure it out. Was it user error, or a system-design problem?
Videos of using the Boston Meter Card
Watch video footage of checking in and out of a meter. It’s hard to read the display, but that’s part of the real-life situation.
Now that I know how it works, I understand the transitions in the display:
- 00:00 – there was no time on the meter when I arrived
- 25.00 – I have $25.00 left on the card
- In – I’m checking in
- 4:00 – the maximum amount of time to park
The first time I tried the card, it took the full 15 seconds to get a response. It didn’t display “In” that time, but it did display “1111″ for some reason.
How long do you have to wait and watch? And how many changes will there be? Not knowing makes it hard to know when it’s complete. Is it clear what each display means?? There was no explanation, and it was impossible to figure out the first time. A brochure came with the card, but didn’t mention any of this.
Problem #2: The displayed information isn’t always the same for the same operation.
Checking out of the space was even more confusing because there were more transitions in the display to figure out:
These were the transitions for checking out:
- 2:18 – the time left when I got back
- 1111 – no idea, what do you think?
- 1:42 – the time I had parked and would pay for now
- 22.85 – the money I would have left on the card
- OUt – I was leaving
- 00:00 – the meter was reset and now had no time
Problem #3: There’s no way for a first-time user to know how many display transitions there will be, so there’s no way to know how long to wait before removing the card. (I think you have to wait, but I didn’t test that.) And it’s not clear what it all means.
It works like … nothing else
Even if you use an older ATM that holds on to your card, it reacts within a second or two. Most card-reading machines have instructions saying to “swipe” or “dip” the card; this was the only one that would use a word like “wait”. Here’s an example from a hotel I recently stayed at:
Using the card the first time
The first thing was to figure out how to insert it. This photo shows a graphic on the meter that corresponds to the chip on the back of the card. It’s hard to see and it’s not clear what it means.
The sticker just below the slot would have been a good place to put some instructions. That would have been easier than trying to decipher that little mark under the slot.
Problem #4: The display is hard to read in bright light, and probably worse at night.
I inserted the card different ways, but it didn’t react (because I didn’t know to hold it in place). I spent a lot of time trying to make it work and a lot of time the next day on the phone finding out how it does work.
The problem: User error?
One person I talked with in the Parking Office said that it was “probably user error” because “that is the problem in 24 out of 25 cases.” I don’t generally believe in user error, so I took a deep breath and said that it’s more likely a system-design problem.
After awhile, I found someone who explained about having to hold the card in the meter for 10 to 15 seconds. I identified myself as a user experience designer, and we talked further.
More than user error, I think it was a failure to understand the users and their expectations.
Should a parking meter card need instructions?
He asked if I’d read the brochure that comes with the cards (PDF). This should be so simple that instructions aren’t needed. I don’t think people would read directions, save them or remember what they’d read. I mentioned that, and said that as a typical user, my copy was already in the recycle pile.
We talked about the instructions on the back of the card, too (ALL IN UPPER CASE) That text doesn’t say anything about holding the card in, it didn’t explain the transitions on the display and it didn’t explain when you’re done with a transaction. The brochure did mention holding the card in, but only for signing out.
Problem #5: This system shouldn’t require documentation and what they provide is incomplete.
How can they fix this now that they’re already selling cards?
If the city doesn’t change something to make the system easier to figure out, I’m afraid that it will just fail.
It’s a system with many parts: the card, the display, the insertion method, the information on the meter and the brochure. Plus user expectations. Some parts are easier to change than others, but something has to change.
When I talked with someone in City Hall, I suggested reprinting the cards with complete instructions. He said that the cards came from the vendor. And that they had 10,000 of them. My card has a number in the 400s, so that won’t work.
Next, I suggested printing stickers with better instructions to cover the old text. Again, even if it were a lot of work, at least people would have the instructions with them.
It would help if the sticker on the meter had some instructions. I assume that changing the displays or how the meters work would be too involved, but we didn’t get to those topics.
We talked a little more and I wished him well.
Lesson: Design, test, redesign, test, …
Problem #6: The underlying problem is that the product design process probably didn’t involve any actual users or testing in real situations.
This is a system designed for anyone who parks a car at a meter, day or night, possibly in a hurry. How do you think someone like that reacts to this user experience the first time?
I don’t know who the vendor is, or who designed the system. And I don’t know how they’re going to resolve this problem. I’m pretty sure the program will not succeed without a big change.
I sent what I learned to Eric Moskowitz, the Boston Globe reporter who writes the Starts & Stops column about transportation issues. Maybe he can write a column and help teach people how it works.
It seems pretty clear to me that this whole system was designed the old-fashioned way. Rather than test the system with real users in real situations, they probably talked about it in a conference room and figured it would work out OK. If someone raised the obvious problems, I can imagine someone else saying, “Yeah, but all they have to do is…”
How do people find items in a list?
When people see a list, they want to understand its organization. If it isn’t alphabetical, the order should be clear and related to the information and the task. You want your users thinking about the contents of the list, not its presentation.
I’ve seen different types of problems when usability study participants were looking for information in lists. Here are some:
- A participant looked at a list of database field names that were ordered by the date they were added. He said, “There’s no order to these fields, so I have to fight this every day.”
- Another participant sarcastically referred to the “alphabetized list of our 1000-plus reports”. While it was alphabetical, there were too many items to scroll through. A hierarchical list, or an easy way to remove old reports, or some filtering methods would have helped him.
- In a related study, there was a long list that was organized hierarchically, but it was shown in a very small window. It was like looking into a busy room through a keyhole – people could see a little bit of information at a time, but never get a good feeling for the list as a whole.
- Looking at an online discussion, a participant in another study remarked that he wanted to see “a threaded-message view”, which is another form of hierarchy. It was as a flat list, where it was hard to tell whether a message was a topic, a response or a response to a response.
- Search engines generally show results sorted by relevance. In the early days of search, results included a relevance indicator (e.g., a bar whose length shows the relevance of each result). This isn’t used any more because, as we saw in usability testing, they weren’t meaningful to users.
- Another recent study showed the top five items in a couple of categories. Some participants wondered how the list was put together. It could have been editorial choice, most-viewed or most-emailed. Understanding the source of the list would affect how they interpreted it.
Jakob Nielsen, in his Alertbox column wrote about a number of cases where alphabetical order isn’t the best choice, and other situations where alphabetical order was used, but presented in such a way that it wasn’t clear. Good points that illustrate the need to find the right order and present it in the right way.
One thing to take into account is how people will use the list. Understanding how each user type (or persona) approaches the task can help you decide to use alphabetical order, form groups that create a hierarchy, or find an order specific to your use.
Whenever I use a payment machine for parking or a transit system, it’s like participating in a usability study.
Many of them are just hard to use, but I know it’s a complicated design problem. Why? Anyone can use them: natives and tourists; people who read well, don’t read well or don’t read the local language; new and experienced users, young and old, etc. And there may be a lot of tasks to include in the user interface.
Here are some examples of what I’ve seen
Boston’s multi-space parking meters
These new parking meters serve a number of parking spaces. Pay a fee, get a ticket, display it in the car. Simple, right? They work fine in the daytime but I struggled to read the instructions on a dark sidewalk. I saw a reference to “the green button”, but it was too dark to see color. And I could barely find where to insert the coins.
Providence, RI, airport’s parking machine
One of the big problems with these systems is simply knowing where to start. That was the case here.
Parking machine at Mt Auburn Hospital (Cambridge, MA)
This worked pretty well. The steps are numbered (although not arranged in order) and it uses speech (do you remember DECtalk?). It started talking when I got close and guided me through the process well. It was loud enough for most people, but I don’t know if it uses other languages.
Washington, DC, metro (subway) payment system
This was very confusing. I didn’t know where to start. As in other cities, they have people available to help customers. Do you think that’s necessary, or could they make it easier?
New York City has multi-space parking meters like Boston’s
A friend sent this for my collection (thanks, John)
While we’re looking at NYC, here’s my favorite street sign
They came up with a great graphic to show why parking is prohibited.
Family members know I’ll pull out a camera when I use one of these machines and they laugh. But I think it’s fascinating to see how different they all are, and to think about how much easier some of them could be.
Question: Have you seen machines like these? How easy were they to use? Did you feel like a usability study participant, too?
If you have any favorites images, email them to me and I’ll post them here.