User Data

An extension of Input and Forms, these chapters deal with the “special cases” of handling user input. Payments, currency, shipping, and images are all covered with tried-and-tested UX principles.

Allow Users to Enter Phone Numbers However They Wish

Phone number entry should be as painless as possible for the user. Don’t attempt to validate them, split them into groups of numbers, apply brackets, or any of the other weird tricks you see all over the web and in apps. If you’ve tried to use a UK mobile number on a form that’s demanding a US number, then you’ll know the feeling.

My theory is that this sort of design comes from traditional paper form filling. Designers are tasked with copying or recreating what was once a paper form into the company’s shiny new web application, but they take this too literally and users end up with a horrible experience as a result.

Stop and think about whether a phone number is even necessary for most registration forms. I hate using the phone. The “Phone” app is my least favorite app on my phone (I’ve tried deleting the app but it won’t let me). However, I concede that there...

Use Dropdowns Sensibly for Date Entry

A user entering a full date (like a date of birth) should be offered a dropdown for the day and month, then a numeric entry for the year. Day and month are sufficiently short that a dropdown doesn’t feel too cumbersome. It also solves the issue of US dates having their day and month in the opposite order to most of the rest of the world.

Don’t use a dropdown for the year though: it looks crazy and forcing the elderly to scroll back to the early 1900s seems very cruel. For mobile, use responsive design to show mobile users the date picker, a custom-designed UI on iOS and Android that makes picking dates a piece of cake.

Be honest—would you rather build your own mobile date entry UI or stand on the shoulders of the designers and researchers at Apple and Google, who’ve done all the hard work for you?

The system-native date picker will also be familiar to users, reducing cognitive load and giving them one less...

Capture the Bare Minimum When Requesting Payment Card Details

The end goal for a lot of sites and apps is getting a customer to pay for a product or service. It’s a cause for celebration: we’ve made something or are offering something so good that the user is happy to spend their hard-earned currency with us. So, why do we make it so hard for them to do so?

Over the years we’ve all pieced together a robust mental model of what it means to pay for something online. Any attempt to change this model to something different or more complex is going to create user friction and confusion. A credit or debit card number is already an unwieldy amount of data for a user to enter, so make it as easy as possible for them:

• Only collect what you need: the card number, expiry date, and CV2 code should be sufficient for almost all online purchases.
• Depending on your payment provider you may also have to collect postal (or ZIP) codes.
• Allow the user to...

Make It Easy for Users to Enter Postal or ZIP Codes

Postal codes and ZIP codes vary wildly around the world. Don’t try to guess the format for the user: simply give them a text entry input field and allow them to enter their code. You can carry out validation if you need to on the server side.

Some of the better forms that I’ve seen in recent years include a “live lookup,” where entering a postal code (or part of a postal code) will return a list of possible addresses for the user to tap or click. Obviously, this reduces the keystrokes and clicks that the user needs to make to enter their address, and also reduces error rates by pre-filling fields with data that has already been sanitized. There are several free (and paid-for) services that offer this, including Google’s “Place Autocomplete.”

If you’re dealing with a web page (as opposed to a native app, for example), then using the autocomplete attribute on an input...

Don’t Add Decimal Places to Currency Input

This is yet another example where keeping it simple is the best option. Many currency input situations (sending a bank payment or adding a tip, for example) require the user to enter a value, which could be a whole amount ($10) or an arbitrary amount (£5.99).

Products sometimes try to be too helpful by auto-adding the decimal place or adding “.00” to the end of the value, which tends to lead to errors. Not the fun kind of errors either, but the kind where you bid $1000.00 for some underpants on eBay when you meant to offer $10.00 for them as the absolute maximum. To avoid this, allow the user to type the decimal themselves, but assume a “.00” if they don’t.

You can improve some experiences by offering pre-set amounts. Tipping is a great example—many ride-hailing apps will have pre-set tip buttons for $1, $5, and so on.

Figure 59.1: Please don’t do this

This...

Make It Painless for the User to Add Images

There are a lot of situations in web and mobile apps where the user is asked to upload an image. It’s done in a variety of ways, but here are some principles for getting user input in the form of images:

• Give the user the choice of picking a file or taking a picture, which is especially useful on mobile or tablet, where the request can trigger the system image picker, which has more functionality than your app can provide.
• On iOS and Android, the user will be asked to give permissions the first time they’re asked to add a photo—and it’s really easy for them to accidentally tap “deny.” You should provide some help text or hint on how they’d go into settings to correct this.
• Consider whether you would like the user to upload multiple images. If so, allow them to do this in one go, rather than lots of separate selections. The markup to allow the browser to send multiple...