Sign up here, a simple task?
“Hello”, the friendly woman at reception greeted me, “We’ll start off by taking some personal details to get you registered on the system, and then we’ll get started.” I smiled and accepted the tablet she handed me with a simple enough registration form made up of my name, contact details and emergency contact information. Simple. Right? Except the testers amongst us will know there is no such thing as a ‘simple’ online form.
I’m sure you’ve been in a similar situation loads of times. Perhaps at a new doctor's, a dentist, an event venue or a new job. We interact with registration forms hundreds of times online too. Unfortunately, loads of companies get the basics wrong. In this article, I discuss the complexities of testing our names and contact numbers to highlight that, even in the smallest examples, testers need to shift their mindset from a technical implementation towards that of real users, while being aware of business contexts.
My name is Emily, Mr Emily O’Connor
It’s easy enough to spot a gap in the requirements of a title field if you’re a Dr, Lord or Lady, so the first bug users might spot in your registration form could come from the inability to allow users to self-describe their title, or that the dropdown is too restrictive to capture a user's title correctly. I’ve also observed a bug whereby I accidentally signed up as “Mr” (the default case, obviously) and was unable to correct this myself, as oftentimes, when registration forms capture your title, account settings don’t allow users to view or edit this field.
When testing a title dropdown, consider the range of options your users might expect to see. For example, I recently worked on a project for a group of medical professionals. This project had to consider the titles of Dr, Prof, and Dean, as well as the more standard values like Mrs, Miss and Mr.
With your title selected, lots of registration forms ask for your first and last name separately. From a technology point of view, this makes a lot of things easier, like when somebody first logs in and you want to welcome them with “Hi Emily”. This implementation makes the assumption that your first name is also your preferred name and is not your family name, as is common with East Asians. Then we must also consider that not all people have last names, so making these fields mandatory can cause errors for those users. A mononym (a one-word name) isn’t only applicable to celebrities like Adele or Madonna, as both women have surnames, but don’t use them. It is applicable to people in Burma, Indonesia and India, where people only have a single name, and can be seen in various other cultures or nationalities too.
I often see errors in forms that don’t accept special characters. So users with names like Siobhán, Anne-Marie, and O’Connor are told their names are invalid. Not being able to enter the apostrophe in my name is the most common error I encounter, but when I am able to enter the apostrophe, sometimes I then get letters and emails addressed to Emily O'Connor, Emily O'Connor or Emily O\’Connor. Other times, the capitals in names are removed, meaning names aren’t written correctly; O’Connor becomes O’connor, McDonald becomes Mcdonald, and MacKenzie becomes Mackenzie.
These real-world test cases impact a huge population of people, so next time you’re testing a simple input field, be on the lookout for default values (Mr), auto-lowercased fields and ASCII-only constraints.
Names don’t need to be validated in the same way as other free text might need to be, as people have a wide range of names from a variety of languages and cultures. Although it might be best practice to ensure somebody's password is not their username, developers aren't validating names in the same way, which is a good job when there are names like Kristoffer Kristofferson, Tommy Thompson, or Phillip Phillips.
The complexities of a phone number
Back on the tablet in the waiting room, the registration form I was handed is asking for a contact number.
In the UK, a landline phone number is a 10 or 11-digit number which follows a specific format. These numbers start with a zero, which traditionally was the number dialled for the operator. They tell you where the person is (geographically) and roughly how much it might cost to call them. There are numerous ways these numbers could be considered valid or invalid for your context.
The first two digits indicate the type of phone number, with 01 and 02 denoting geographic landlines. In a registration form, you might expect users should be able to provide their home phone number. If the input is less than 10 digits, it would be reasonable to assume the user has forgotten to specify the area code.
011X, 01X1, 01XXX, 01XX XX and 02X are the most common area code formats found in UK phone numbers. The shorter area codes represent larger geographical places, like 020 for London and 029 for Cardiff, and the simplest of the 01 formats could be considered to be 011X, where 0113 numbers are from Leeds, 0114 Sheffield, 0115 Nottingham, 0116 Leicester, 0117 Bristol and 0118 Reading.
Companies don’t validate landline area codes using drop-downs, presumably because these numbers have historically changed, and new area codes may be added.
So, in our ‘simple’ registration form, should we only allow 10 or 11-digit landline numbers that start with one of these area codes? Maybe. We also have to consider that 03 numbers represent national numbers (a business or charity). 08 numbers are sometimes free numbers (like one you might phone for customer support), and 09 represents premium lines (for example, a voting line for a reality TV series). The validation to only allow 01 or 02 landlines would also skip most of the complexity around phone number extensions or a company's internal switchboard.
Our registration form should also consider the white space we add to phone numbers to aid readability, without removing the digit validation. For example, my childhood phone number was 01XXX_XX_XX_XX (underscores represent the spaces) and my Dad’s work number was 011X_XXX_XXXX. Removing the spaces would likely have reduced readability and my ability to recognise a mistake in the input.
This type of information isn’t available in the US phone numbering system, which may help us (in the UK) understand why companies aren’t always the best at validating phone number fields.
Although area codes exist in the US phone numbering system, the difference is that if somebody were to move across the country, they would be able to take that phone number with them. In the US again, mobile numbers (cell numbers) and landline numbers look exactly the same.
Do you have a mobile number?
In the UK, all mobile numbers start with 07 and are 11 digits long. Even these numbers have a decent amount of validation, which could be codified. Numbers 071 to 075 and 077 to 079 are reserved for mobile services. In contrast, numbers starting 070 are not personal mobile numbers and can incur high call costs.
Beyond that, you might also be able to identify somebody’s network provider from their mobile, e.g. a number starting 07971 to 07979 is typically provided by the operator O2 and the numbers 07771 to 07776 and 07778 or 07779 were issued by Vodafone. In contrast to landlines, these numbers can be easily transferred between operators, so particularly memorable phone numbers are often kept by individuals. Also, some virtual operators use the same prefixes as their mobile network provider. For example, Giffgaff uses the O2 network, so a new Giffgaff customer might have a 07974 XXXXXX phone number, provided by O2.
Not all 077 numbers are valid either. Ofcom has allocated a range of phone numbers that are recommended for TV and radio, so the mobile numbers 07700 900000 to 900999 are reserved for this purpose. In most cases, you might not expect a registration form to highlight an issue with these mobile numbers. But, in cases where a user's mobile is provided to enable two-factor authentication, further testing may be necessary.
To add further complexity, UK phone numbers can also start with +44 (country code), meaning the number 07799_XXXXXX could also be written as +44_7799_XXXXXX. So, should our form only allow for numerical input, and should you show a + placeholder for mobiles? This again assumes somebody is providing a UK mobile number from inside the UK, as it would be valid to provide 0044 instead of +44.
Think about the context in which the organisation wants or needs a user's phone number. Perhaps it's to contact them regarding an order or enable two-factor authentication (2FA). Each of these use cases has different validation considerations, as it’s commonplace to ask users to enter a one-time code when registering a phone number to use for 2FA.
An emergency contact number
In the example of our ‘simple’ registration form, a company might ask for a landline or mobile number for yourself, the registering customer, or for your emergency contact. This is where users might behave more unpredictably.
In some situations, I might provide an emergency contact who is in the same town or city as I am, so that if the worst happens, somebody is available to provide my medical info. There are lots of examples where I might need to provide an international number, especially thanks to the popularity of services like WhatsApp, Signal, and Viber. In these cases, phone number validation should account for international prefixes with or without the leading 00 and the plus symbol, e.g. 00 61 1 XXX_XXX_XXXX and +61_1_XXX_XXX_XXXX. Validating international phone numbers also needs to account for shorter inputs, like that for international calls to Luxembourg, which could be as short as +352_XXXX.
All of this assumes somebody has an emergency contact at all. I’ve heard numerous stories about people who have put down 112 or 999 to fill the mandatory emergency contact box.
All of this to say phone number validation isn’t trivial!
Other considerations
In this example, the escape room I was visiting didn’t ask for my entire credit report; 5 years of address history, date of birth, if I’ve ever been known by any other names, email address and about every other element of personally identifiable information (PII) a credit agency might think to ask of! It’s worth considering how each of these fields would also come with their own complexities and implementation considerations, such as postcode lookup, age requirements, the dates on which you were known by any other names, the format of emails and many more.
To sum up
Next time your teams are working on a registration or contact form, don’t let them reassure you that it will be a simple task!
Registration forms need to be representative of the users they wish to onboard, and the corresponding account should enable users the opportunity to update any details provided, including title and name.
When asking users to enter their name, consider asking for a person's full name and, separately, their preferred name. Both inputs should accept special characters such as țħîš and ensure apostrophes (‘) are encoded in such a way that my correspondences are not addressed to Emily O'Connor.
When my name is not accepted or it’s printed back to me in an invalid format, personally, I begin to question the company managing my information. If they can’t handle the apostrophe in my name, how is my information being validated, processed and transformed behind the scenes? And do I trust them with other data?
Inputs for phone numbers should allow for spaces to aid the user's ability to spot errors in their input. Validation should not be overdone unless the number is intended for two-factor authentication or account recovery. Even in such cases, validation can be achieved with a confirmation text rather than numerical checks.
Registration forms may be a user’s first impression of your brand, forming a critical part of the company's reputation. Thus missing the opportunity to onboard somebody who might have a high customer lifetime value, especially if they are a Dr, Lord or Lady! Getting it wrong doesn’t just mean someone may abandon your site. This could ultimately lead to losing a customer and any associated revenue to a competitor, for good.
All this from a simple registration form.
You're right. Given the goal is to drive conversation and encourage testing, we can make the "Questions for Reflection" feel more actionable and less like a school assignment.
Here is the revised section, replacing "Questions for Reflection" with the more engaging and action-oriented "Starting the Discussion," and slightly rephrasing the bullet points:
What do YOU think?
Got comments or thoughts? Share them in the comments box below. If you like, use the questions and actions below as starting points for reflection and discussion.
Questions to discuss
- Have you seen this? Share any bugs you've encountered on live registration forms, particularly those related to names or phone numbers.
- What did you do? If you found a bug on a live form, how did you go about reporting it or raising it to your team's attention?
- What are your thoughts? What are the biggest challenges you've faced when testing international names or phone numbers?
Actions to take:
- Test a form: Select an online registration form (e.g., shopping, banking, insurance) and test it for some of the bugs mentioned in the article. For ideas on where to test, check out this great resource on practice websites.
- Share your resources: Do you know of any other great resources or tips for effective form testing? Share them in the comments!
- Do some research: Look into a naming convention you're unfamiliar with, for example, look into a culture that uses mononym names and consider how you would test a form to ensure it supports users with a single full name.
