Since the world discovered the joys of credit history, tracking people’s personal adventures in rental properties and the world of moving house has been something every company has taken up with great abandon in order to profile their customers and their existence in this world.

To the customer, the idea of being dragged into an interrogation room and quizzing them about where they’ve been, what they’ve been doing, and if they consumed Weetabix last week is all a little too threatening.

Who are you, what’s your name, and where’d you come from

Enter the world of phone tariffs and insurance, amongst other draining industries, where it is imperative that you provide many companies with your past 3 years of housing history.

For many years this sort of questioning was reserved to call center thin clients, and occasionally a nasty long paper form, but these days it isn’t uncommon to find yourself on the thick end of one of these forms when buying services online.

O2 and “how not to do it”

Picture the simple situation: my iPhone contract is up soon, so I’m going to change to a rolling O2 monthly contract to save some cash.

So, like a loyal customer go to try and order a package, and by the first page of the checkout screen, I literally can’t go any further because it can’t find my old address. That’s my old, very standard address, which comes up in every other address database I’ve ever used.

I’m left being told I need to call the Royal Mail. Yes, that’s right, not enter my address I “think” I have and they’ll check it for me because I’m giving them business. Call the Royal Mail. And then come back to the site to try again.

The point that O2 have fundamentally missed here is that the user owes them nothing. The user is about to (if they could get past this damn form) commit to a contract with them. It’s the ultimate sacrifice a user can make online – a purchase. O2’s responsibility to check a customer’s credit history is none of the user’s concern and neither should it be.

Problems with data integrity

O2 have expected the user to compensate for the unreliable nature of centralised databases, ignoring some of the most crucial problems of using a third party (or even first party) database:

• Data is often validated but not verified
• Even data that is verified may no longer be valid
• People lie
• People make mistakes

A consumer database is almost never 100% correct. From these problems we can assume the following rules:

1. Never assume data is correct

Yes, just one rule. The complexity is not in the data, it is in the solution to dealing with the lack of data integrity.

For any company involved in creating this kind of form, they want the minimum effort on their own part when it comes to processing transactions. For any potential customer using this form, they want minimal effort. Both parties want the same thing.

Dealing with data integrity

Unfortunately for company X (or in our case, O2) they can’t get away with doing nothing. A user who can’t find their address is a lost sale, or a long, expensive support phone call, leading to a remote possibility of a sale. The company’s job here is to ensure that in any reasonable scenario, the user can get to the end of the checkout; if it means checking manually entered data with real human beings, then they need to organise this.

The company may want perfect data integrity, but if they can’t provide it to the user in the first place, they can’t expect the user to send it back.

Out-designing data issues

So the solution? It’s an obvious one which most places grasp – occasionally, some users won’t have their address listed, so we need to allow them to enter their own – but it comes with a weight of interface conundrums and 101 ways of doing the same thing.

One of the hardest problems with address entry is that it is monotonous and repetitive. It doesn’t forgive and it doesn’t reward at any stage (even if that really great phone is just a click away), and so the necessity for a conversational approach to hold the user’s hand, reassure them and make sure that they feel part of a finite process is absolutely imperative.

Using this approach, we can avoid many of the problems with what is essentially a database search – we can ask them if the address is correct, and if not, please correct it. Using suggestive language like this, we are not feeding them negative actions such as [CLICK HERE IF THIS IS NOT YOUR ADDRESS], nor are we adding unnecessary clicks.

In fact, as shown above, if the user is uncomfortable with using the search again (it’s easy to lose trust in these search mechanisms), they can simply wipe all the fields and tell us that they live in Disneyland. The point is that we’re lowering the cause for resentment, and raising the likely hood that the user will sail through the form nonchalantly. We’re saying “just give us a little, and we’ll do the rest”.

With some neat client side scripting, we choose to can track whether the user actually modified the address fields, and with some simple pattern matching, we can ignore simple modifications a user has made (case changes, splitting incorrectly concatenated names, etc) and still provide incredibly accurate data from the majority of users. Submissions from users who have entered completely new or different addresses can be flagged for review.

We’re also addressing the issues with ‘Time at Address’. A user will likely rarely remember when they moved, but they will generally be able to give a vague estimate of how long they have been at each address.

Asking the question in this way allows us to estimate what dates they were at each place, and also allows us to stop asking the question once they reach 3 years. For the user, it’s a satisfying end to a well communicated finite process, and for the company, it’s enough information to assess the user. Both sides are happy.

Yeah, yeah, UX, whatever. My address database is read only!

Your address database that you are designing for may very well be read only. The system may only be able to identify users against addresses using index keys between the databases. You may have a database admin who refuses to let you modify this data. The backend may run off Gorgonzola and Tomatoes. This shouldn’t stop you.

You should work to devise a solution that holds user-entered addresses in an escrow-style service, which your own company has to deal with through manual processing or through developing an automated process. Whatever you do, don’t make the user do it.

Look, I’ve got better things to do than this!

As designers and developers we should be looking to mitigate risks created by legacy backends, and whilst we can’t always control the nature of the backend, we should be prepared to design and develop middle-man services which deal with these issues in order to aid the user.

It’s worth noting that whilst this is nothing groundbreaking, this kind of design pattern regularly comes up and can be applied to forms which deal with data sets other than addresses. So many of these problems seem trivial, but at the heart of them lie significant barriers to transactions, customer satisfaction or even obtaining customers in the first place.

It is only through doing this and with considered design that users will begin to trust the process of providing companies with their sensitive data.

Thanks

Thanks to some discussion from the excellent @yahnyinlondon and @bashford who greatly influenced the outcome of this work.