SIGIA-L Mail Archives: SIGIA-L: User preferences regarding onli
SIGIA-L: User preferences regarding online applications--Summary of responses
From: samantha bailey (a2slb_at_bellsouth.net)
Date: Mon Nov 05 2001 - 21:11:41 EST
Hi,
Last week I sent an inquiry about user preferences with online applications
(I work at a bank where we have a lot of online applications and more
customers opting out before completion than we'd like) to both CHI-WEB &
SIG-IA.
This is the summary of responses I got, both off list & on. There was such
good stuff here, most of it embedded in the context of the messages that a
summary alone wouldn't do it justice, so the
(slightly edited) responses appear after the summary. The original
question/message appears at the very bottom.
Summary:
-Keep the application as short as possible and cut out *anything*
extraneous-only request information imperative for completion of the app.
-Definitely provide the ability to complete the operation online, without
requiring interacting with a human and preferably in a single session, as
savvy users will be counting on this and any other provision will not really
fulfill the expectation set by an "online application"
-Provide an "escape" option so that users can opt out after giving minimal
info and then have a phone call for people who are confused, frustrated or
don't want to give all the info online. (Be aware that there is the
potential to confuse users so make sure that the design avoids creating two
options/paths to achieve this.)
-Provide prominent access to a toll-free number so that all users are
reassured that they can speak with a live customer service representative,
should they need to.
-"remember that registration, or account setup in your case, is an
unfortunate side-effect of conducting transactions on the web (from the
user's point of view) and unless the experience is painless, quick, and
provides a real benefit, many users simply will not bother." -Jeff Parker
Responses:
§ I am working on an application that has a long registration process that
also deviates somewhat from standard online shopping registration processes.
It is for an app that allows access to sensitive records (not shopping).
Because the user will need to sign-up for the program in person, and
receives a packet of information at that time, I am recommending that the
user be walked through registration by the person who gives them the packet
and signs them up. Otherwise, I am afraid that less savvy users will become
frustrated during the registration process (our own version of the abandoned
shopping cart) and not use the product. (Julie;hillanj_at_MMRF.MFLDCLIN.EDU)
§ No hard facts about the trust issue, but from a questionnaire point of
view, we found that the shorter the questionnaire the more likely it was
filled out. We implemented two types of questionnaires
1. a "quick" questionnaire of up to three questions servedup to people after
they did a search and before they received their search results - about 70%
return rate
2. a longer questionnaire, asking them about their experience with the site.
(Margaret; mairead_at_yahoo.com)
§ From my own experience as a customer of online banking solutions, I would
prefer to have an immediate response and use the service rather than wait
for 5 days for my PIN to arrive in the mail (this has happened from the
three online banks I have used) (Margaret; mairead_at_yahoo.com)
§ something we saw when testing the egreetings store is that seeing a
prominent 1-800 number on the check-out pages engendered trust-- it was the
promise of human contact. (Christina; cwodtke_at_eleganthack.com)
§ maybe they want to interact with a human at some point, but the delays of
that (live chat is not good) are worth less. also, live chat is a very
expensive option... I don't know how you can make a good ROI for that.
(Cesar Martin-iworkwithyou_at_yahoo.com)
§ ibm.com's commerce team certainly seem to feel that being able to talk to
a human in the purchase process is important. Many of our commerce pages
have "Call Me" button with the idea being that the user reaches a point
where the website doesn't answer their question and they need to talk to a
person to finish the transaction. I suspect that this was implemented for
much the same reason that you are considering how to include a human--we
were losing a lot of folks part way through a transaction. (Karyn;
karyn_at_shredbetty.org)
§ Research shows that people prefer personal contact and that a large number
of dropouts occur before any on line form/purchase is completed. If those
are your two options I would go for the first. There are those who do prefer
to complete on line and be done with it. I would personally give them the
choice of option 1 or 2 at a strategic point. ie continue on line after
option 1 or would they like a personal call. (Vivienne;
vfarrell_at_groupwise.swin.edu.au)
***
Having spent some time observing call centers as a consultant a few years
back, and having since been a very active internet and phone user, I'd say
"it depends".
There are tasks that I really want to be able to accomplish online, e.g.,
buying a plane ticket easier than through an interaction with a person.
However, I have rarely experienced a "smooth" transaction online where I
have not had to resort to the good ole Toll Free number.
Sometimes a CSR, even though sometimes less prepared to answer correctly
than a computer interface, is just so much more reassuring than a FAQ page
that doesn't allow me to ask a personalized question. As a baseline for a
large company whose goal is customer focused there is probably an
expectation of both touch points (web and toll free) as well. To cut one out
is to potentially lose audience members, no? This seems like a potential
business justification, especially if a system already exists somewhere.
Also at that baseline, it depends on how good both online and offline
interfaces are for your customers. Both your site and your CSRs should be
tested for effectiveness and refinement. This can be hard to control, but my
advice would be to teach operators how to search for the right information
and empower them to distribute it in the name of customer service. I assume
there is good demographic information out there to back up the idea that
people still need people. (sniff ;-) (Dennis, djhuston_at_21stcentury.net)
***
I recently did a site for a fuel company. A typical scenario is that the
heating company delivers fuel and leaves a bill to be paid in 10 days or
30 days. Opening an account like this requires establishing a credit account
with the fuel company. Problem is very few customers think about it as
asking for "credit".
We discovered this in usability testing. The big hitch was giving a social
security number, although other questions also felt invasive. These are
questions that a person opening an account with a bank wouldn't give a
second thought, but we found the mindset was totally different for fuel
customers.
Our solution was a combination of wording changes to get them in the
establishing credit mindset and bailout points. On specific sticky
questions - like ss number - we added a sentence saying that if the didn't
want to give it online a CSR would call for it. We also divided the form
into two sections and gave people the option to submit it at the end of the
first page and do the rest by phone or continue on and complete the form.
The combination of letting people know why specific info was needed and
letting them submit when they wanted has worked. Online applications for new
fuel accounts have exceeded the client's goals.
(Elisabeth;epaine_at_megalink.net)
***
I don't have any research at hand to support the following, but I'd like to
comment on your question.
>From my experience and from research I have read, the primary cause of
dropout during registration (or checkout) of any kind is the fact that it
is a task that often has nothing to do with the user's primary goal--that of
getting information, paying a bill, purchasing a product.
It's important to remember that registration, or account setup in your case,
is an unfortunate side-effect of conducting transactions on the web (from
the user's point of view) and unless the experience is painless, quick, and
provides a real benefit, many users simply will not bother.
Two examples:
I. A medical education site run by a major pharmaceutical company.
The usage rate of the site was much lower than anticipated and the bailout
rate on registration was approaching 90%(!). When went to redesign two major
problems became evident.
1) Much of the content was "hidden" behind the registration. The users were
not only unable to access the materials without registering, but didn't even
have a good idea of what would be available if they did register.
2) The registration form(s) were way too long and asked for a lot of
personal, medical information. People were simply unwilling to spend time
filling out the forms and/or to provide such personal information with
little indication of the benefits provided.
To combat these issues, we implemented did two things:
1) We made the majority of the site's content available for viewing without
registering. Only for certain key functions, that we felt provided enough
real "benefit" to the user required registration. (e.g. a "Goals planner" to
help users manage asthma, a pollen alert function that would send pollen
warnings to the user's email address.)
2) We implemented a "drip" registration process whereby users supplied only
the information necessary to get they information they wanted at a
particular point in time. However, as the user continues top use the site
and access more features, a profile of that individual is built that allows
the vast majority of the original registration info to be collected over
time. For example, rather than ask for personal medical info for no apparent
reason, this info was collected as the user took a quiz. Same info gathered,
but now in the context of a user's goal--that of collecting information
about their disease and assessing their level of health.
II. An extranet for a fortune 500 Mail and Document company.
Due to logistical nightmares having to do with legacy systems on the
backend, users would have been forced to enter a great deal of esoteric
information (account numbers, machine codes, billing numbers, etc.)to access
all of the functionality on the site--some of which they may never use.
Again, we implemented a drip registration scheme in which the user provides
info in a just-in-time basis. So, to start using the system, all the need to
enter is a name, username, and password. When they utilize function A, they
enter the info (account numbers etc.) needed to process that function.
(Note: User research showed that the majority of users would use only one or
two of the functions available on the site--functions having to do with
their-day-to-day activities.)
Again, over time, a profile of the user is created and they never have to
endure a single, long registration process.
In both examples above we (the IA/Design company) had to fight hard against
internal marketing people in the companies--especially in the case of the
Asthma site. From theses folk's perspective, the entire initiative was about
gathering consumer profile information for other on and offline marketing
efforts. (i.e. They freaked when they saw that their "important" profile
questionnaire (over 50 questions) was trimmed to about 6 questions on the
initial registration/login screens. However, we won most of the battles, and
the strategy paid off. More people register and they actually collect more
information about users in the new system that in the old. (Remember that
90% bailout rate!)
option 1: provide a short application (takes 5 minutes to complete) online
that is followed up within one business day by a phone call from a
bank representative who completes the process and assigns an account
number
First of all "short" is a relative term. Five minutes is a long time on the
web. However, I also understand that a banking site is different from a
consumer info portal. People would generally expect to have to provide a
good deal of information when opening an account--so perhaps they could deal
with it. (i.e. Even though it is a registration (the messy paperwork) it is
also an understood necessity to setting up an account--their primary goal.)
However, my gut reaction is that having an agent call is a bad idea for two
reasons.
1) Not inline with the user's goal of opening (not starting the PROCESS of
opening) a bank account. I think if you did the research, you would find
that those that use the web for such things do it to avoid this human
interaction. I for one would be very disappointed if I spent five minutes
filling out forms just to find out I have to be available for a phone call
within the next 24 hours. In fact, I think this fact would cause me to abort
the whole experience using the logic: "You claim to offer online banking,
yet I have to go through offline channels to do my banking. Sorry, I'll take
my business to an institution that delivers the goods." (Of course my
"opinion" is just that, an not a good indication of how your audience will
respond. Only research could provide the real answers.)
2) Not inline with the bank's goal of reducing costs and/or increasing the
level of customer service. I'm assuming here that the bank is not engaging
in online initiatives out of the goodness of their own hearts, but rather
for a very specific business goal. And the truth is, humans are expensive,
call centers are expensive. Reducing the load on call centers would go a
long way towards providing measurable ROI for your client. It's a
tangible"thing" they can measure. Or, let's assume the "call back person"
would have to be a new function/employee in the bank--to handle all the new
business from super-cool new site you are building. I can't imagine that the
client would be too happy about your design creating a new,
long-term,(expensive) expense.
>option 2: provide a longer application (takes 15 minutes) and receive the
new account number in >the online session. User can proceed as an
established customer and neither needs (nor has) >contact with a bank
representative.
I think I addressed this one above, with the caveat: trim the registration
form at all costs! Work with the bank to determine what info is actually
NESSESARY to establish an account, vs. that info which is used for
marketing/customer profiling purposes. Then, only hit the user with the
necessary information to get going and come up with other ways to build a
consumer profile over time--drip registration again.
>do customers prefer to interact with a human at some point in a transaction
where a trust >relationship is being established and an account
>is being *originated*
Again, I can only offer opinion. I have no data. Only a usability test
and/or focus group test could answer this for YOUR particular audience
segment. But I would say, take the human out of the loop. If the user
doesn't have the level of trust to conduct their transactions
electronically, then why would they be registering at your banking site in
the first place?
>opinions or hard data on whether there is a benefit to providing both
options
No data. But providing an 800 number to an existing call center might not be
a bad idea. Those that need the "security" of talking to a human could get
it without you having to implement two separate registration paths--which
could also be confusing. (Jeff; JParker_at_FrankfurtBalkind.com)
***
My perception of your question (not necessarily correct, of course) is that
you're touching on the classic problem of channel conflict. If you've got
two different ways of communicating with your customers, how do you make
sure they use the right way (or how do you make sure you're using the right
way?)
Answers are complicated by business requirements & costs in addition to user
needs, but I'll chime in.
All of my experience has indicated that customers need to establish a trust
relationship with any business, and this will in general involve some form
of 'human contact.' Without establishing this relationship, customers are
not likely to proceed with a faceless relationship.
Email is still perceived as human contact, however, and many times answering
an email message prior to the customer's registration can establish this
trust.
Forcing a customer to interact with a human when establishing an account can
be extremely disruptive. If they are on dial-up Internet access, they may
have to disconnect and place a phone call. If they have to visit a physical
location, they are not likely to bother unless the reason is compelling
enough.
Offering both options is a reasonable way to go, providing it doesn't blow
your costs out of proportion. You could flood your telephone support system
unexpectedly, dramatically increase your telecommunications cost etc. to
find out that most of your users choose the easier route of simple
registering online.
Typically, it's a question of whether they trust the medium in addition to
your company. If your audience is older, less tech savvy...offering both is
likely to accrue a benefit. If your audience is younger, more Internet
aware, more accustomed to the medium you're probably wasting your budget.
Some anecdotes: I do all my banking online. 100% of it. When I opened my
recent bank account, I visited the location and picked up a paper
application form and dropped it off a couple of days later. Why? If I had
registered online, I would have had to visit the location to sign a bunch of
documents anyway. More of a pain.
When I order contact lenses, I order them from Vision Direct Canada online.
I've never once spoken to anybody at this company, I found them through a
search engine and I've never even had a personal email message from anybody
there. Good service has kept me ordering from them for over two years now.
When I built a mutual fund account access tool, our customer service staff
were able to register people by phone but we never told anybody, and they
were not encouraged to do so. 4 years ago, 4,000 users registered in the
first week, well over 99% of them registered online. No regrets about
setting up the infrastructure to do phone registrations, but we could have
skipped it.
I'm currently building an online lottery which will sell tickets worldwide.
I'm aggressively discouraging offline registration or purchase completion of
any sort. Why? I don't want to pay the telecommunications costs, or the
staffing costs associated with multi-lingual phone support. It's my belief
that the cost will far outweigh the benefit (it also dilutes the message:the
Internet is the delivery mechanism for tickets, so allowing them to buy by
phone undermines the medium.)
Good luck, and I hope this is helpful, or at least not a waste of your
time. (Scott; scott_at_penguinstorm.com)
***
I don't know of any research, but I have filled in many such application
forms and often found them frustrating. The main points I would advise a
designer to deal with are:
1. Make sure that the information is captured and stored frequently
during the input process. If anything goes wrong with the user's
connection, or if they interrupt the process to check something else,
they should be able to resume where they left off without having to
input data again.
2. Make it possible for the user to go back to previous pages and check
or alter what they said.
3. Use immediate validation as each field is input if possible. If a
field is invalid, explain exactly why. State explicitly whether logon
names and passwords are case-sensitive.
4. If you provide a free text box for the user to type into, make it big
enough. I hate typing through a keyhole where I can see only the last
couple of lines of what I have written.
5. Make it easy for the user to keep a copy. Provide a printer-friendly
version of the information that the user can print before confirming the
transaction, and a printable confirmation message when you have accepted
it. Printouts should include the full text that has been typed into
every box, even though it exceeds the space provided and has to scroll
when inputting (but see 4 above).
6. Tell the user how many pages the form occupies, tell them what page
they are on, and let them know at the start what the printing
arrangements will be. Otherwise they may feel that they have to print
each page as they complete it, to capture data that will otherwise be
lost.
7. Provide an email address to which they can send comments and queries
using proper email, not just a Web form. If you support encrypted email,
such as PGP (and it's highly desirable that you should), give details.
8. I have no wish to talk to someone on the telephone, and I generally
prefer not to, as I have no written record of the conversation and no
assurance that what I have said has been noted accurately and will be
acted upon. Email messages at least give me some evidence that I can
quote later if there is a problem. The question of "trust" is
irrelevant, as I assume that anyone I speak to on the telephone will be
an employee in a call centre with whom I will have no more of a personal
relationship than I have with the institution's computer.
(Leonard Will; L.Will_at_willpowerinfo.co.uk)
***
Recommended resources:
-http://www.zurich.ibm.com/~mrs/chi2000/contributions/egger.html (Julie)
-search on TRUST on the Usable Web site (usableweb.com) (Keith;
sigia_at_instone.org)
-Jacob on registration:
http://useit.mondosearch.com/cgi-bin/MsmGo.exe?grab_id=2588500&host_id=2&pag
e_id=195&query=registration&hiword=REGISTRATION+REGISTRANT+REGISTRATIONS+
(Jeff)
-Creative Good's 2000 Holiday shopping report--free but requires (a brief!)
registration.)
www.creativegood.com
(Jeff)
-I also received 2 pdfs and will be happy to send them to anyone who
requests (as soon as I secure permission from the folks who sent them).
***
Original Inquiry:
I'm curious to know if anyone has experience with or is aware of any
research regarding whether customers prefer to interact with a human at some
point in a transaction where a trust relationship is being established and
an account is being *originated*.
I'm working on redesigning the interface for an online account application.
I haven't found any information on this issue, specifically, so I'm hoping
folks will let me know if you have experience with this and/or know of any
studies/research in this area.
We're having more folks opt out of finishing online applications than we'd
like and we're looking at ways to address this. One of the issues is that we
have to integrate our online application process with our backend processes
and there are basically two ways to approach the issue--we're trying to
determine which customers would prefer (and whether providing both would
help or hinder)
option 1: provide a short application (takes 5 minutes to complete) online
that is followed up within one business day by a phone call from a bank
representative who completes the process and assigns an account number
option 2: provide a longer application (takes 15 minutes) and receive the
new account number in the online session. User can proceed as an established
customer and neither needs (nor has) contact with a bank representative.
As mentioned above, here are the 2 things I'm looking for feedback on:
* do customers prefer to interact with a human at some point in a
transaction where a trust relationship is being established and an account
is being *originated*
* opinions or hard data on whether there is a benefit to providing both
options
Thanks very much. I will compile all results and report back with the
summary.
Sb
Samantha Bailey
samantha_at_baileysorts.com | http://baileysorts.com
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:52 EST
|
