CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Katie Albers <[log in to unmask]>
Reply To:
Katie Albers <[log in to unmask]>
Date:
Tue, 6 Nov 2007 10:33:53 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (102 lines)
At 10:47 PM +0000 11/5/07, Nick Gassman wrote:
>On Mon, 5 Nov 2007 09:35:41 -0800, Susan Farrell wrote:
>
>Susan, thanks for your comments. Let me explain some of the
>complexities.
>
>>Our recommendation is to make registration optional, but to offer it
>>at the _end_ of the checkout process, so that people can simply
>>create a password and be done (all their other info has just been
>>entered while purchasing).
>
>In our case, someone is buying travel. They may be buying it for
>themselves, or for someone else. A lot of PAs for example, purchase
>travel for their bosses. In many cases, the person making the purchase
>will enter someone else's email address, as they will want the other
>person to receive the confirmation email with the travel details.

I don't understand why this makes the "end of purchase" model 
difficult or impossible. So, you have a separate field for 
"notification email" or some such.

>Also, we don't need a delivery address, now that people no longer
>receive a physical ticket. We do need a billing address, but there are
>many travellers who will use a billing address that isn't where they
>live (most of the time).

Again, how does this affect the registration process? Do you need a 
residential address for the delivery of something to the registrant?

>
>If the travel is for more than one person, we require the names of all
>the travellers.
>
>It doesn't make sense for us to include registration questions on the
>payment page, which could result in registration errors. We want the
>money at that point.
>
>We know that on the confirmation page customers primarily want to
>check that the travel information is correct - it's high in money and
>emotional value. They don't want clutter - like registration - there.
>And there is also important servicing information and actions
>required.

I've often designed the end-of-process registration as just a 
checkbox on the confirmation page - "Do you want to become a frequent 
flyer" all the information has been entered. The fact that your 
customer has already entered other information as well is irrelevant, 
as is the fact that in the future they will still have to enter data 
which are not part of the registration record. That's what computers 
are for.

>
>It should be pitched as a convenience to
>>the customer for ease of shopping next time. At that point, people
>>can evaluate the benefit exactly, in terms of how much time it might
>>save re-entering their details.
>>
>The customer would also be joining the frequent flyer scheme, and
>would earn miles, if they are travelling.
>
>>When registration is placed first in the checkout process for a
>>first-time buyer, it discourages people by asking for personal
>>information without showing the benefit first.
>
>There are some travel websites that just require registration with no
>explanation. This is typically placed after the price has been
>displayed, and before personal information is entered. It would be
>quite possible to have an optional registration process at this point
>that explains the benefits.
>
>Also if anyone fails
>>to register correctly or refuses to enter the required data, they are
>>unable to purchase.
>
>We would allow the customer to opt out of the process at any time.
>
>These factors end up requiring us to have a new page just for optional
>registration during checkout.
>
>*    Nick Gassman - Usability and Standards Manager - http://ba.com *
>
>     --------------------------------------------------------------
>            Tip of the Day: Postings must be in plain text
>      CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
>               MODERATORS: mailto:[log in to unmask]
>        SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
>     --------------------------------------------------------------


-- 

----------------
Katie Albers
[log in to unmask]

    --------------------------------------------------------------
    Tip of the Day: Quote only what you need from earlier postings
     CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------

ATOM RSS1 RSS2