Nathan J Pledger

The little things in checkouts can make all the difference

I have just completed revisiting the checkout portion of the various e-Commerce sites I help manage. The reason for the revisit was to establish ways to improve the conversion rate of users that enter the checkout and complete the checkout to make the purchase.

Part of the testing process has highlighted some interesting points about e-Commerce checkouts and forms in general. I'll share them with you, here.

Make sure the Enter key targets the appropriate button on submission

Users can find it difficult making the transition between conventional desktop use, where Enter keys and mouse actions perform certain actions, and web use where Enter keys don't follow such stringent rules as windows and dialogue boxes and double-clicks aren't useful. (Even though users double-click on web pages an awful lot.)

One aspect of this is users' habit (and perhaps rightly so) of pressing "Enter" after finishing a particular section of a form. For example, when logging in to a site, typing:

<username>TAB<password>ENTER

to enter the requested details and actioning the request. Of course, on the web, thing's aren't so straight forward as a Windows dialogue box. This is particularly a problem for .NET sites, thanks to the way that ASP.NET renders it's pages, but a fix is available in ASP.NET 2.0. I have used the new DefaultButton attribute to achieve this:

 <asp:Panel ID="pnlForceEnterKeyToLogin" runat="server" DefaultButton="btnLogin">
  <fieldset>
   <legend class="hidden">Login</legend>
   <asp:PlaceHolder  ID="plhExistingUserValidation"  runat="server"></asp:PlaceHolder>
   <p>
    <asp:Label  ID="lblExistingEmailAddress"  runat="server"  AssociatedControlID="txtExistingEmailAddress">Email Address:</asp:Label>
    <asp:TextBox  ID="txtExistingEmailAddress"  runat="server"  />
   </p>
   <p>
    <asp:Label  ID="lblExistingPassword"  runat="server"  AssociatedControlID="txtExistingPassword">Password:</asp:Label>
    <asp:TextBox  ID="txtExistingPassword"  runat="server"  TextMode="Password"  />
   </p>
   <p>
    <asp:Button  ID="btnLogin" CssClass="button" runat="server"  Text="Continue  &gt;"  />
   </p>
  </fieldset>
 </asp:Panel> 

You'll also notice that I have used the '>' character to convey movement to the next screen. I'll probably replace this with an image shortly, but the point remains the same, small visual cues like this say more than you think.

Check page-flow is useful to the user

Make sure that page-flow from adding an item to the user's basket and putting the item in the basket is logical and obvious. There are three options, each with it's own considerations:

• Recycle the same page - Users can add items to their basket very quickly and not "lose" position in the site. This is particularly useful for pages with multiple items for purchase. However, make it obvious something has happened. Previously, I have emboldened the last item added to the basket, but a distinctive message would also suffice.
• Jump into the checkout - Once "Buy" is clicked, sending the users straight in to the checkout certainly emphises the process of purchasing, but then forces users who want to continue shopping to then come back out of the checkout to continue purchasing. It also gives a slightly forceful impression, which may reduce the number of units bought per purchase.
• Jump to a page full of other products - This is probably the most widely adopted method for companies who are more on the ball with their e-Commerce offerings. Once a product has been purchased, even basic cross sell logic could generate a series of products which may also interest the user either as a complement or otherwise to their purchase. Amazon.com do this, as do Marks and Spencer. However, again, make it clear that the user has added the item to their basket.

When errors occur, make it bloody obvious!

For complex pages, validation can be a pain in the @rs3! Where do you put the validation errors? Do you out them at the top of the page, or alongside the individual controls? I choose to put them at the top of the <FIELDSET> containing the controls, for accessibility, but this means that if the user has a particularly full basket, they may not see the errors as they may "fall off" their immediately viewable screen, resulting in the impression the page hasn't done anything when they clicked the button.

I have reinforced the messages within the <FIELDSET> by a distinctive banner that is shown at the very top of the page that advises them to look further down the page for why the request didn't work out.

Usability testing

While a fully budgetted for focus-group is an ideal thing to have to help identify niggling issues in usability, throwing the checkout at random people in the office could also be a great way of spotting errors, niggles and spelling mistakes you would never spot yourself. It can also be used as a training exercise for the support staff, such as customer services teams.

And of course, accessibility goes without saying ... doesn't it?

Even now, four years or so after it became a "good idea" to make sites accessible, developers STILL generate HTML 4 with no regard to semantic or accessible content. The same rules still apply:

• Use FIELDSET's to separate sections of a form and label them with a <LEGEND>. You don't have to display the legend, hide it if it detracts from the design.
• Use XHTML+CSS to seperate your markup and content from your design. And while you're at it, how about making a print stylesheet by using media="print" on your <LINK> tag?
• Use AccessKeys on key parts of the form, such as submission or common fields such as email address. And make sure your TabIndex works correctly.
• I like to try and reduce the number of images in the "content flow" as much as possible, unless there is a particular relationship between the adjacent content. Therefore, "furniture" such as icons, decorative elements, etc. I put in CSS. That way, a user on a light-weight browser or slow connection does not have to wait for it all to download and render (assuming you are using CSS media types).
• Don't rely on JavaScript - and definitely not Flash!
• Make sure your text is of a large enough size as to be legible. Remember that about 60% of users who use the web have some degree of eye problems.

And while I'm here, this is a really neat way of hiding content from browsers, but not hiding from speech readers:

* hidden { position:absolute; left:0px; top:-500px; width:1px; height:1px; overflow:hidden; }

The problem being that it is often required to have content within your markup, but want to hide it for design purposes as elements such as <LEGEND>s, <CAPTION>s, etc. are often targetted to specific platforms and users. Hiding it with a display: none or visibility:hidden is no good, because speech readers (being one of the specific accessible platforms) have started to implement these rules. This method, however, moves it off the content layer, then either moves it out of the rendering viewport or makes it obscenely small so as to make is invisible and (hopefully) so small that if it was rendered it wouldn't affect your overall design.