 |
|
^ click above ^ |
04.28.04
 By
Jared M. Spool
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?"
Is Your Web Site a Talking
Horse?
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. |
Talking Horses are Everywhere
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.
eBay's Talking Horse
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.
The Top 3 Priorities of the Talking
Horse
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:
1. Focusing on Necessary Features
2.
Reducing Support Costs
3. Looking for Additional
Opportunities
Priority #1: Focusing on Necessary Features
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.
Priority #2: Reducing Support Costs
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.
Priority #3: Looking for Additional Opportunities
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.
***
Consumer Targeting ***
Deliver contextually relevant messages that drive click-through
and conversion rates 20-40 times higher than traditional banner
ads. >> 2
min. Quick Tour |
Keeping the Horse Talking
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. •
Want to learn more? On Day 2 of UIE's upcoming Summer
Roadshow, Christine Perfetti and Jared M. Spool will address the
four stages of maturity, including the 'talking horse' stage. Each
stage requires a completely different design approach. At the UIE
Roadshow, we'll share the proven approaches that are most effective
at each stage to get usable products out the door.
About the Author:
A software developer and programmer, Jared founded User Interface
Engineering in 1988. He has more than 15 years of experience conducting
usability evaluations on a variety of products, and is an expert in
low-fidelity prototyping techniques. Visit http://www.uie.com/
for more usability information. You can reach Jared by calling our
office or by sending mail to jspool@uie.com.
Read this newsletter at:
http://www.thedevweb.com/2004/0428.html |
|
| From
the Forum: |
| CSS
Idiot |
OK, got my CSS designed. BUT I cannot find
anywhere or probably more properly decipher, how to make the
content appear in the center section and change with each
link. Or do the outside sections just get repeated on each
subsequent page? What I understand is that using CSS I can
just change the center content, keeping header and nav buttons
constant...
|
|
|
