Published: Mar 30, 2004
A guy walks into a bar and tells the bartender he is all excited. Apparently, he just met a talking horse. He goes on and on about how impressed he was that the horse could talk. After a few minutes of listening, the bartender asks, "What did the horse say?"
The guy immediately exclaims, "The miracle is that the horse could talk! Who cares what it says?"
It could be that your site (or part of your site) is a talking horse. Is everyone focusing on just "making it work"? Is it the only place people can accomplish their goals? Does making it easy-to-use seem like a low priority? If so, then you might just have a talking horse.
Anytime somebody does something new with technology, something nobody else has ever done before, that technology goes through a talking horse stage. It's extremely common and, more importantly, it's critical for the design team to recognize that they are in this stage.
We see talking horses all the time. It's common, for example, to find them on intranets.
Imagine your intranet has a sales application that every salesperson has to access to get their work done. The salespeople can't go anywhere else to get the same information. Designers can give the users whatever interface they want -- the salespeople can't get away.
What's amazing is that, very often, the users don't care if the interface of a talking horse is horrible. They are so thrilled to have access to the unique functionality or content that they will put up with almost anything.
This was certainly the case with eBay's Seller Form for many years. The form was so difficult to use that only one out of every four attempts to post a new product actually succeeded. Yet, sellers rarely complained.
In the early days, eBay focused on making the buying process as simple as possible. Since the buyers had many choices of outlets where they could get the same products, eBay had to make sure that the buying process was not an obstacle to purchasing.
However, eBay didn't have the same philosophy for the sellers. As eBay's buyer base grew quickly, every seller wanted access to those customers. They tolerated the seller form, with its exceptionally difficult-to-use interface, because they had no other choice.
Because the successful sellers were making a lot of money, they didn't complain. Instead, they spent hours mastering the Seller Form and saw the rewards of their efforts. They tolerated the idiosyncratic and awkward process because they knew they'd make big bucks when they finally got it posted.
Talking horses are important because they demand a different set of priorities than other types of designs. Since the user's tolerance for frustration is higher, making the design generically easy-to-use has little immediate benefit.
However, there are activities smart designers can do to ensure the horse talks. For most teams, the top three priorities are often:
What makes talking horse designs succeed is that they get out the door. Any design requires certain functions to be useful. Working on these functions is the priority.
For any project, there will always be features that would be "nice to have," yet the users do not require them. Since, by definition, a talking horse has no competitors, these "nice to have" functions can wait until future releases, when they will be necessary to compete. Delaying these optional features allows the team to dedicate its precious resources to the necessary features.
The problem comes when the team can't tell what functions the users require and which ones the team could delay. When this happens, the priority becomes understanding the users' tasks, to ensure the team can clearly identify the required features.
This is when making an investment to identify and research the users' tasks really pays off. What are the users trying to accomplish? How do they know when they've accomplished it? What steps do they currently use to accomplish the same thing without your design?
While there are many ways to answer these questions, techniques like site visits and customer interviews can provide the team with valuable, detailed answers. Talking to and observing a handful of key customers usually resolves any issues and quickly makes the required feature list solid.
Another priority is to ensure that you keep support costs at a minimum. Support is always an additional cost. Whether users are calling the help desk, a customer care center, or just asking each other, there is an associated productivity cost.
While users of a talking horse will work hard through difficult designs, they will eat up resources in the process. Anything designers can do to reduce the demand on these resources will have a direct effect on the bottom line.
The first step to identifying potential support problems is to have a clear understanding of the users' tasks. Again, site visits and interviews will help identify the key tasks users will have.
Once the team knows the users' tasks, they can look for places where support problems can appear. Unfortunately, we've found that inexpensive techniques such as design inspections or heuristic evaluations rarely identify these issues accurately. Teams are better off conducting rigorous, task-based, usability testing. Testing is a better approach to help identify where problems will originate.
Of course, if you've already deployed the design and it is in use, talking with the support team is critical. We've spent many hours "jacking-in" to support calls and find them completely enlightening. Many teams find regularly listening in to calls valuable.
Once deployed, many teams find a continual-improvement program that focuses on eliminating the top 10 reasons people contact support can have dramatically positive effects on their overall quality efforts.
What makes the talking horse important is that the users are locked-in. They don't have a choice to go elsewhere.
However, this doesn't last forever. If your idea is a good and your features are valuable, someone will try to compete with you. At this point, you're no longer the only choice and everything changes.
While this change is inevitable, there are often features that a team can implement to postpone competition. For many teams, identifying these features is an important priority.
To do this, teams will need to research new ways users can accomplish their goals. The only effective way we know to collect this type of information is to spend time with the users and watch them throughout their day.
Spending significant time with users, watching their entire workday, often is extremely enlightening. Finding six to twelve users and spending a day or two with each gives teams many new insights into features and services that will continue to lock the users into the talking horse.
Even though users will tolerate the design flaws of a talking horse, there are still important things that designers should do to ensure the design is as good as it could be. Understanding the different priorities that occur when you have a talking horse is essential to survival. •
Read related articles: