Learning from a poke in the face

During usability testing, I’m always fascinated to see how creatively users misinterpret the team’s design effort. I’ve seen users blame themselves when our design failed, and I’ve seen users yell at the screen because our GUI design was so frustrating.

Wednesday, the tables were turned.

I unintentionally “agreed” to let Facepoke—that social-networking site—invite everyone with whom I’d ever exchanged e-mail. Think about all the people you may have exchanged e-mail with. Former bosses and CEOs. Your kid’s teachers and the principal, too. People you used to date. Prospective business partners, or people you’ve asked for work but who turned you down. Your phone company, car-rental company, bank, and insurance company. Government agencies. The person you just told “I’m too busy to volunteer,” and your teammates from that course in 2005. Your e-mail records are full of people that you simply wouldn’t want on your Facepoke page.

How could I be so stupid?

See paragraph 1:  User blames self for poor design.

Facepoke had been interrupting my flow for several days, offering to help me find Friends by examining my Gmail records.

1.    I gave in, chose three Friends, and clicked Invite.

The screen flashed, but the list was still there.

2.    I clicked Invite again.

Then came the moment of horror: I saw that the list had been changed! Switched! It was now a list of every e-mail address in my Gmail records that was not already associated with a Facepoke account.

With that second click, I had “agreed” to let Facepoke invite everyone with whom I had ever exchanged e-mail. There was no confirmation, no “Invite 300 people? Really?!?”

3.    I sought in vain for a way to Undo.

With each passing minute, I thought of more and more people who would have received this inappropriate inivitation to join me on Facepoke.

FacepokeWhy wasn’t there a confirmation?

See paragraph 1:  User emotes in frustration.

Note to self: Always do better than this

In my usability- and design work, I will continue to ask: “What’s the worst that can happen?” I will promote designs that prevent the worst that can happen. I will not present two apparently identical choices back to back, one of little consequence, one of great consequence. I will allow users to control their account and to Undo or recover from their unintended actions. I will not make users feel like they’ve been misled.

Common tasks losing usability

There’s been a loss of usability for people who type text.

Like me, you may have experienced these unwelcome experiences:

  • After typing a long message in Facebook, when I click send, I get a page error and my entire message is lost.
  • After typing a post in WordPress, if the server has gone down or I press an unintended keyboard shortcut, I lose my entire post.

By comparison, if Word stops responding, it will (try to) offer me my unsaved changes when I reopen the document.

With users increasingly doing their work in browsers, why don’t browsers remember the text we were typing? Or why doesn’t the operating system? Or why doesn’t the weblication make backups? Or the server?

When my actions in a browser fail, imagine a message such as this:

Supporting the user after a failure in the browser

This hints at just one possible solution. In the spirit of Five Sketches™, I bet you can come up with at least five more ways to support users after they’ve lost the work they typed in a browser.