There’s a lot of talk in the usability world about how to create a great user experience. There is talk about the extensive user research that’s needed. There’s talk about developing mockups and prototypes to get user feedback before the development process, or doing user-based testing during the development process (yuck). There is talk about being innovative with new and clever solutions to age-old problems.
Except for the idea of doing user-based testing during the development process, I love the stuff. I think it’s all fantastic. I want to encourage as many people as possible to do it. But the problem is, the devil is often in the details. And many, many products on the market today don’t need to have a full overhaul to obtain significant improvement. They do need to address the details.
Take for example the website for my local government. The new year has started, and with it comes the need to go online and take care of several matters. The company business license needs to be renewed. Business personal property has to be registered. In my case at least, a new company vehicle lease needs to be registered. All of these can be “conveniently” handled online. The applications are not overly sophisticated. For each activity, I usually just need to complete a simple form that does not ask me for too much information. Typically, I just need to provide my company name and address, my phone number, possibly my company’s federal tax ID, and often my credit card number or bank account and routing number.
Using the computer systems that I have, much of this information can be filled in automatically by my browsers, using information I have told it to use. As soon as my computer realizes what I’m doing, it asks me if I would like it to enter all the information it has on file for me into the form. This is a very handy feature and a wonderful timesaver. But now we come to the problem.
The ability of my browser to automatically enter data into a form requires the website developer to identify the form fields so that two software programs can handshake with each other, or strange things happen. If the fields are not identified at all, or are identified too strangely, my first and last name might get entered but nothing else. If the fields are mislabeled, my address might show up as my city. Or my city might end up in a secondary address field. Having some fields with no content is not so bad, but having some of my information end up in the wrong field requires me to delete that content or run the risk of receiving one of the wonderfully worded error messages sites often have.
Of course, I don’t have to use this timesaving feature. I can recall most of this information off the top of my head and enter it all manually. (Yes, I can even recall my bank routing number and credit card number, having entered them enough times.) But even that process is fraught with inconveniences. Most numbers have a specific format that humans are used to. Social security numbers are three sets of numbers separated by dashes. We think of them that way, say them that way, and thus want to enter them that way. Many numbers have multiple ways to make the grouping clear when we write them. Phone numbers are in three sets, but these can be separated by dashes, by parentheses around the first set of numbers with a dash between the other sets, using spaces instead of dashes, or even using periods. As humans, we’ll recognize all of these as the same thing. But many sites require us to use one, and only one, format. My local government website requires me to enter all of these items as a continuous string of numbers—the one format a human would almost never use.
None of these issues are particularly difficult to overcome. Having to fill out many forms means that I encounter them a lot. And these issues result in what a colleague of mine likes to call the “flea on the dog syndrome.” One flea on a dog is not a big problem. Even two fleas are not a big problem. But a lot of fleas will drive the dog nuts. And so it is with these kinds of usability issues. Too many of these little problems can drive you nuts. And none of them are hard to solve.
It would take a developer only a few additional moments to properly label each field so that the automatic fill-in feature would work. Similarly, it would only take a few minutes to write the code that would parse the user’s entry and put it into a standard format. Ironically, the error message usually given for an “incorrectly” entered number says you can’t enter a number with dashes so please reenter it without the dashes. My immediate thought when I see this is: “If you know what’s wrong and how to fix it, you should have just taken care of it for me.” Is this arrogance? Is the developer’s time to write the code really more valuable than the time that every user has to spend throughout the year reentering data, since they are likely to continue to make this “mistake” out of habit? Is this just a lack of awareness that the capability even exists to fix the problem?
Many webmasters or managers of systems don’t have to invest a significant amount of time into user-based testing or into a full redesign process to improve their product’s user experience. They don’t have to seek out innovative and creative new ways to perform their site’s functions. They just need to be aware of the small details. For many products, that’s where the devil continues to live.
