When I started this blog my very good
friend and ex colleague Abi said to me “It’s good but…have you plans to make it
less…funny?”…I took that as a compliment at the time.
In theory this blog WAS supposed to be serious from the
start but for some reason it’s veered towards the funny/critical (how did that
happen? Not like me at ALL!). Anyway,
near year new me and all that. Cue “A
Serious Post About Payment”.
When designing a checkout flow payment page is a funny beast
– sometimes you can feel like you’re leading your customer through a lovely
pleasant fairy-tale of ‘just browsing’ - a heady, lighthearted experience - and then they
hit the payment page and all of a sudden they’re in the wicked witches clutches
devoid of power , confused and disappointed. It’s a let-down which results in one of a few outcomes – you panic and run away (drop out), carry on through the pain and
end up feeling slightly scarred by the experience (convert with difficulty) or you attempt to
get through and end up getting turned to stone by some repeating error message
or problem you just can’t get past (drop out without wanting to). Enough with
the analogies – often people get checkout design wrong – and the payment page
can be the epitome of the big bad wolf in a bad checkout (ENOUGH!)
Ok so in order to design a payment page (I'm calling it a page
but it could easily be a form- one page
checkouts are more and more common now) where do you start?
Let's take that form as an example. Entering card details.
For me it’s first and foremost about the customer – the context
of what you’re doing. What’s the driver here? Well in most cases the customer
just wants to pay, - they’ll be thinking about their order and the items they’re
buying and they’ll be focused on getting to the end. Some will be at work and
trying to enter their card details quickly to get out of the boss’ siteline,
others will be at home with phones ringing, doorbells going and kids interrupting.
Some customers will want to feel reassured throughout that they’re in a secure
environment, others won’t be so concerned. Woah that’s a lot of drivers. If you
look at all this in isolation it looks scary-
and when things look scary the way through the wicked witches woods’ is
to go SIMPLE, CLEAN and ORGANISED.
OK so the first thing I do when faced with this challenge is
write down everything that needs to be on the page (or if you’re that type
enter everything which could be on the page and then cross a load of stuff
out). For payment forms this is usually universally the following:
Card type
Cardholder name
Card number
Expiry date
Start date
CVV/CV2/Security number
Issue Number
Security logos
Payment type logos
After crossing out the things you don’t need – or adding
additional things you need for your site (card nickname if you like, a save
card for later checkbox if you offer it). Then the next task is to order them
into some kind of hierarchy. I’d favour
something like:
I always like to see the card number first – purely anecdotal
evidence suggests to me that when entering a card customers find that they
stumble here as they always want to enter their card number first so they end
up with an error. I think it’s because you don’t know your long 16 digit number
off by heart so you’re more likely to want to just get it onto the page before
anything else. I could be wrong. So I’d end up with something like this:
Hmm but wait – something is wrong here. The types of
information you’re asking a customer to enter are going to change depending on
what that piece of information is. We
also have to think about our interface requirements with a PSP – they need
certain information in a certain structure. So let’s restrict the format the
customer can enter that information in. Let’s also make sure it’s easy for the
customer to see what that format is. For a start date or expiry date we know
the boundaries of what the customer will enter for example the customer sees
MM/YY on their card, we should attempt to replicate that here.
Ok so next thing that’s bothering me is that the two fields
at the bottom represent very shirt pieces of information. Issue number is
usually a single or double digit, and the security code is 3 digits (4 for
AMEX), so let’s create that expectation for the user and shorten up those
fields.
But wait – Issue number and start date? I don’t have those
on my cards? That’s because these are only requirements for certain types of
cards (Maestro), so let’s not show them when the customer doesn’t need them. To do this we need to know what type or card
the customer is entering up front, You can do this in a number of ways, either
with radio buttons and images of card types, with a dropdown – ideally I’d like
it to be transparent to the user (they don’t care what the card type is) so it
could detect from the number they enter into the field. Let’s for now make it a
dropdown. And let’s make it
clear when the information is needed.
For a non-Maestro customer here’s what I have now.
I think I could improve on the descriptive-ness of my field
labels. They’re a bit techie. Let’s make sure the customer knows exactly what
they should enter into the field.
Some fields may need more explanation so I’ll add some
tooltips
That enter text’ is annoying isn’t it? Let’s make it useful.
I’m quite happy with that. As discussed above customers can
find security a problem when paying online so a bit of reassurance of trust
logos, card schemes etc. won’t go amiss here and depending on where you add
your payment types accepted (basket page is useful) - it’s worth re-iterating again here,
especially if you do/don’t take AMEX or any international card types.
This might seem incredibly simple - and the result is pretty simple. But it’s clear from just a few minutes browsing the web
that a lot of sites aren’t following the basics when dealing with transactions online. Pret a
Manger’s online top up for their Pret Card is pretty hideous- they don’t seem
to know what to call things so have gone with the ‘/’ approach (FYI Pret you can just
call it a ‘card’ - customers get it!). The
Maestro information is shown for everyone and the expiry date is hidden to the
bottom – with some badly pixelated non transparent 3D Secure scheme logos (this
is how I discovered this issue – by constantly failing to fill in the expiry
date and thus failing to pay)
This
is from Kurt Geiger- better isn’t it?
Lovely, clean, simple and ordered. My favourite type of form.
Now I have my basic form I’d start looking at validation and
error messages next..but that’s too much serious for one week so you’ll have to
hang on for that one until next time.
