By Michael Woloszynowicz

By Michael Woloszynowicz

Sunday, January 29, 2012

Your Users Won't Read

As web designers or developers we often have a tendency to fall back on text to convey a message or instructions to an end user. Our thought process is that if we provide the necessary steps as written text, how can anyone mess it up? As useful as text can be, the approach is inherently flawed as text is often ignored or at best scanned, and inference or expected behaviour prove to be a more powerful force. Even if your process is straightforward, text becomes useless if the actions on the page infer something that is counter to it.

While I've grown to appreciate this fact more and more over time, it's never become completely clear until a recent discovery with one of our applications processes. The below wireframe is a rough representation of what a fragment of our page for accepting an invitation to a company site looks like. Once a user selects that they would like to accept the invitation, we ask them if they are already users of our application, or if they wish to create a new account. We all thought the process was simple enough with little room for misinterpretation or error.


After witnessing a few users interacting with this page, we discovered that there were two main problems with this approach. The first was that we relied heavily on the "Do you already have an account" statement to be read, which turned out not to be the case. The second is that we didn't expect the "Yes" and "No" buttons to be interpreted the way they were. What ultimately happened can be seen in the pseudo heatmap below.


Users completely ignored the "Do you have an account" message and interpreted the dialog box as a confirmation box. As a result, the "Yes" and "No" text in the buttons was all that was read, and people merely saw the "Yes" as a confirmation of their intention to accept. Since most users didn't have an account, upon clicking "Yes" they were asked to provide a username and password which they viewed as "select a new username and password" as opposed to "login with your username and password". This clearly caused a good deal of frustration and confusion as the system would then tell them that their login or password were invalid when in fact they had no login to begin with. As we can see, the entire process broke down because of the expectation that one particular line of text would be read before an action was taken.

Our revised and so far (we're still testing) more effective process looks something like this:


By removing the dialog box, users no longer interpret the next step as a confirmation. Furthermore, the removal of the "Yes" and "No" terms within the buttons places the focus on the "Create new" and "Sign in" keywords that carry greater meaning. Finally, we've moved the more common action of not having an account as the first option. So from this particular example the key takeaways are:
  1. Association or inference will always overpower instructional copy.
  2. People will read text but only keywords such as the first word or two in a button.
  3. You can't write your way to a good user experience
  4. Always perform usability testing!
If you liked this post please follow me on Twitter or upvote it on Hacker News

No comments:

Post a Comment