SEEK is the largest online employment marketplace in Australia.
With most of SEEK’s revenue coming from job ad placements, it was critical to improve the existing online payment form.
When I started working on the project, less than 20% of people posting their job ads paid for them using our credit card form at the time of ad posting. Instead, they opted to pay upon receipt of an invoice.
This had a major impact on cash flow, as well as cost associated with debt collection and unpaid invoices.
My challenge was to design a new payment form and increase the number of people paying by card.
The existing online payment form was archaic to say the least. When you ask people to hand over their financial details online, you have to instil confidence. A form that looks like this falls short in the task of instilling confidence
Credit card forms are nothing new. I didn’t see it as my job to create something completely new, but rather to take stock of existing best practice designs and put together a design that suited our user base and the flow the card payment would be used within.
I looked at the ways different sites handled input masking, card type selection, saving of card details and help for the security code.
I collected a folder of examples I liked, and used some of these as inspiration for my designs.
There were two innovative card form designs that I really liked, but chose not to use as they don’t fit with our design philosophy or our audience.
The first is the single field card form, popularised by Brad Frost.
This is a brilliantly elegant solution, particulary for mobile phones where space is at a premium. I chose not to use it for two reasons. Firstly, our form was being built exclusively for desktop. More importantly, SEEK caters to an extremely diverse audience of users with varying levels of computer literacy – providing credit card details this way would not be familiar to most of our audience.
The second pattern was the skeuomorphic form that reflected the appearance of a card. One example is the Skeuocard by Ken Keiter.
This is another neat and innovative pattern. What I particularly liked about is that we could do away with instructions for retrieving the card security code, since we could show it on the card itself.
However, this wasn't enough of a reason to depart from a tried and tested way of collecting card information. In addition, the style we have been evolving at SEEK leans away from skeumorphism in favour of near flat design.
The answer was ‘no’. Not for now anyway. Our current job ad posting workflow is desktop only. Since the card payment is part of that workflow, it made no sense to build a responsive payment form at this stage.
The first step in nudging more people to pay by card, was to make the ‘Pay via credit card’ option more prominent.
The current design had the two options presented with equal visual weight.
While leaving both options available, I changed this to make the card option much more prominent than the invoice option.
Transcribing long numbers into an online form is hard, because it is easy to lose track of where you are up to. For this reason, input masking that reflects the grouping of card numbers on the card itself makes number entry much easier.
We made sure we reflected the different number patterns, depending on the card type.
For American express...
And for all the other cards...
There are many ways to capture the expiry date. I considered the following options.
I ruled out alt F straight away because drop-downs are the most ‘expensive’ in terms of interaction cost.
Alt B and D appealed because they reflected the way the expiry date is presented on the card itself, most often inlcuding the ‘/’ character. However, I did not like using two fields to capture what is esentialy a single piece of information.
This left me with alt A, C and E. I felt that some guidance regarding what was expected in the field was needed, so I rulled out A.
I am generally against using placeholders in fields, and we don’t do it at SEEK. However, alt C most closely reflected the way expiry date is shown on the card itself. We were also able to automatically ‘type’ the ‘/’ character for the user, once they entered the month. This made it very easy to enter the date, as we validated in our usability testing (see below).
There is a big benefit in storing users’ card details. It makes subsequent checkouts quicker, ultimately improving the checkout rate.
Many people are weary of storing their card details online, so we carefully crafted the micro-copy around this option.
Let’s break down this copy.
We tested the credit card form as part of the job ad posting process. We waited for each participant to express whether they would pay for the ad by card or invoice. If they opted for card, they were given a dummy credit card so they could enter the details.
The key things I was interested in seeing first hand were:
We found that none of participants attempted clicking on the card logos, meaning they were not misunderstood for interactive elements. A couple of participants commented on how useful it was to get the confirmation that your card type was recognised, once they started typing the card number.
The input masking for the expiry date worked without a hitch. Typing was evidently a natural way for people to enter dates.
Half of the participants expressed hesitation with saving their card information in general, not just on our site. However, they commented that our explanation made it clear why we gave that option and that it put them more at ease about doing so.
After the first six months of the new form going live, the percentage of payments being completed by credit card (instead of invoice) jumped from 30% to 74%.
The number of card transactions increased by a factor of six, meaning that we were sending out a lot less invoices.
Most importantly, our upfront cash flow increased by a six figure sum and the debt collection agency we used reported a reduction in business from SEEK.