Mobile Form Usability: Avoid Splitting Single Input Entities

This is the 1st in a series of 8 articles on mobile usability that draw on findings from our mobile e-commerce usability report.

During our recent mobile e-commerce usability study we observed subjects struggle with inputs that were split across multiple fields, such as a phone number divided into three fields (area code, central office code, and subscriber number). While the intention is good, these fields proved difficult for the subjects to both understand and interact with on a mobile device.

Specifically, the subjects had a hard time navigating between such fields (Issue #1: Interaction), found it unclear if they were all required (Issue #2: Ambiguity), and sometimes found the division illogical (Issue #3: Perception). In this article we’ll go over each of these three types of mobile form usability issues related to dividing a single input entity into multiple fields.

Issue #1: Interaction

Users generally have a difficult time navigating between fields on mobile devices. Surprisingly few of the test subjects used the ‘Next’ and ‘Previous’ buttons on the touch keyboard – instead they generally navigated to new fields by tapping them on the screen.

On Macy’s, the phone input is divided into three fields (three-digit area code, three-digit central office code, and four-digit subscriber number), which made the input needlessly difficult to enter. See video clip.

To enter a phone number on Macy’s m-commerce site, you must: 1) Tap field. 2) Switch to numeric keyboard. 3) Type first three digits. 4) Keyboard auto-closes (Macy’s for some reason finds it a good idea to auto-close the user’s keyboard). 5) Tap the next field. 6) Switch to numeric keyboard again. 7) Type the next three digits. 8) Keyboard disappears again. 9) Tap the last field. 10) Switch to numeric keyboard once more. 11) Type the last four digits. (And then, to make matters worse, at the last field, the one place where the keyboard could reasonably auto-close, it does not). Even if the keyboard did not disappear as each field is completed, the number of interactions required to fill a phone number in the three fields remain the same (you’d still need to either tap the field on the screen or the ‘next’ button on the keyboard), and the typing flow of the 10 digit phone number would still be abruptly stopped twice. Not to mention all the issues related to editing a phone number split across multiple fields (in case the user spots an error).

While the intention of dividing the phone number into multiple fields is good and indeed serve as a very strong input formatting example, it simply does not work very well on mobile. (On a desktop site where advancing between fields is easier for users the division might be acceptable; our full-site checkout usability study showed no conclusive data on this.)

Issue #2: Ambiguity

Another issue arising from dividing an input entity into multiple fields is the ambiguity of required vs optional fields. Our research studies show that you should always clearly indicate both required and optional fields (with explicit markup for both), however, almost all sites indicate this in the label. This presents a design issue when some parts of the divided input field are required and others are not, as seen on Southwest’s mobile site below:

On Southwest the ZIP code input is divided into two fields (the basic five-digit code followed by the four additional ZIP+4 digits), however, it’s only the first field that is required while the second field is optional, but the user really has no way of knowing this from Southwest’s form design.

Of course one way to solve the issue Southwest runs into is by adding “required” and “optional” labels below each field or as inline text, but why divide the fields in the first place? It adds unnecessary complexity to the form design and suffers from the interaction issues described in the previous section. Also, suddenly changing the position of “required” and “optional” labels will result in an inconsistent form design unless you of course change it for all fields in the form which seems like a rather drastic design change just to be able to divide a ZIP code input across two fields.

Issue #3: Perception

Lastly, there is an issue of perception where an input is commonly presented as separate fields even though users perceive it as a single coherent entity. This is true of “name” fields that are often split into “First name” and “Last name” fields.

Toys’R’Us ask for “First name” and “Last name” instead of a single “Full name”. We saw countless subjects enter their full name in the “First name” field, only to discover they had to split it into separate fields.

During both our E-Commerce Checkout Usability and M-Commerce Usability studies users consistently considered their name a single whole – I am not “James” and “Newman”, I am “James Newman”. Therefore, users often enter their entire name in the “First name” field and then upon advancing to the next field, discover that they must now enter their last name. They then go back to delete their last name from the “First name” field, only to advance to the “Last name” field again to complete it.

While numerous sites ask for the user’s name in two or more fields it simply is not good usability. Of course it can be difficult to discover this if you’re not doing usability tests since all subjects we observed noticed and corrected the error before submitting the form (thus not showing up in most form tracking web statistics). It is therefore not a critical error to make but it does introduce needless friction to the checkout experience. Amazon seems to have reached the same conclusion and instead asks for the user’s “Full name”:

Amazon only uses a single name field on both their desktop and mobile sites, which matches the user’s perception of their name as a single entity.

Another issue related to multiple name fields concerns middle names and titles. If “First name” and “Last name” are separate fields then logically “Middle name” and “Title” should be separate fields too. Suddenly you end up with four fields instead of a single field, or a subpar experience where the user will have to guess whether their middle name should be appended to the “First name” field or prefixed in the “Last name” field. With a single “Name” field you avoid this issue altogether as users simply enter their name from start to end, including any middle name(s) and titles.


As we can see, seemingly innocent and sometimes even common divisions of a single input entity into multiple fields can lead to interaction issues, required vs optional field ambiguity, and misalignment between the user’s perceptions and your site’s form design.

On desktop sites, there may be instances where dividing a single input entity across multiple fields may be acceptable if all the fields are either required or optional and there’s no misalignment between user perception and form design. However, on mobile – even under those narrow circumstances – you should avoid splitting single input entities across multiple fields due to the interaction issues previously discussed.

This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” mobile e-commerce user experience.

Share: LinkedIn

Authored by Jamie Appleseed

Published on February 12, 2013

Comment on LinkedIn

User experience research, delivered twice a month

Join 25,000+ readers and get Baymard’s research articles by RSS feed or e-mail:

Topics include user experience, web design, and e-commerce

Articles are always delivered ad-free and in their full length

1-click unsubscribe at any time

Note: It should be stressed we only have conclusive test observations for the field types stated in the article above. No conclusive test observations was made for other field types such as an address - neither confirming or disconfirming whether users perceive their address as a single entity or multiple related entities (street, zip, state).

Article series

  1. Mobile Form Usability: Avoid Splitting Single Input Entities
  2. Mobile Form Usability: Place Labels Above the Field
  3. Mobile Product Pages: Always Offer a List of Compatible Products
  4. Mobile: Never Use Native Drop-Downs for Navigation
  5. How should your mobile and desktop sites differ?
  6. Mobile Product Lists Need Very Distinct Hit Areas
  7. Mobile Form Usability: Never Use Inline Labels
  8. 5 High-Level Mobile Commerce Design Considerations

Related Articles

See all 66Mobile Web articles

More E-Commerce Research

Free Research Content:

Products & Services:


At the end of the day, it seems that keeping it simple wins out. Great breakdown!

Yes, some of those forms are really poorly designed.

One important ergonomic aspects to consider is to have the user AUTOMATICALLY go to next text/number fields.

If you split a phone number in 3 parts, then there should be no NEXT/Previous button but simply user moving automatically from one field to the other.

Antoine @Datafieldapp

Another great article. I’d like to comment on your third point about single coherent entities.

In my opinion, the “name” field issue is a tricky one. I agree that many users — in many, but not all, contexts — think of their “name” as a single entity, so it would be ideal to collect it via a single field.

However, for a number of form owners, it is imperative that the database hold the name as two separate fields (e.g. given name(s) and family name). Often two separate names are needed because the data has to be checked against other sources (e.g. identification, financial or historical databases). Also, in many cases there is a legacy system, which may have been set up poorly but can’t be changed.

If the name has been collected via a single field, as far as I know it is not possible to computationally parse it into two fields without a high degree of error. One of the many reasons for this is that in some cultures family name comes first where in others it comes last. And just think about names like “de Bruin” or “Mac Donald”. Consequently, you often need two separate name fields.

Given all this, I think the recommendation to form designers should be to:
- identify what the single entities actually are, for your users, in your specific context;
- if you can use a single field for each of these, and still meet your business requirements, great;
- be aware that in some cases, one field for one entity may not be possible, so there may be a (hopefully minor) decrease in overall usability.

Hi Jessica,

Once again, great clarifications.

As with most of our articles, we write them for an e-commerce context. And for most traditional e-commerce a single name field will be feasible, as:
- credit card holder name verification use full name,
- shipping couriers will deliver when full name is used,
- and most address validators dosen’t use name but just the address itself.

But, yes there are a number of form owners with a more advanced context/requirements (banking, insurance, subscriptions, e-gov, comes to mind) where a 100% verifiable last name is needed, and the name entity needs to be split across two (or more) fields.

Very glad Smashing Mag shared this article. We’re in the middle of a responsive store build so getting this perspective is remarkably valuable; thanks so much for sharing your results.

I want to tack on a question following up on Jessica’s excellent observation and your response to it. I tend to look at all the data being gathered here from a strategic marketing lens, so collecting the name is (in the long run) most important to continued communication with our users. And at least in my mind, few things are as important as timely, relevant, desired and personal communication to our users.

If it becomes difficult to parse out first and last names accurately, that makes addressing a challenge in email comms. Any thoughts on balancing usability versus that particular business goal?


Hi Jeff, thanks glad you liked it. This observation is an excerpt from our upcoming report we a launching next week, which will include 149 additional design guidelines specifically on Mobile e-Commerce. Be sure to email me an url when your responsive store is ready, I’d love to see it.

I regards to your question, then a specific need for addressing customers by last or first name in email marketing communication 100% correctly, will be a limitation to this “single name” method. Do you have data indicating that addressing customers by “first name” only (as opposed to “full name”) works better? Do share if possible.

Christian, I think you proved Jeff and Jessica’s points by addressing them by their first names rather than their full names.

Great points all around. Business logic might dictate that last name be a separate entity for search purposes for example. No problem, you say, just regex out the last string! What happens if the user has a complex name with prefixes and suffixes? Suddenly you’ll have a database with hundreds of people that have the last name Jr.! Ok so you regex out Jr… By creating a full name field you are creating an dataset that less robust.

Hi Tyler, to the extend possible I’d suggest avoid splitting the name entity into separate cells in the database as well. Again, for most traditional e-commerce a single name as a single data entity will be feasible, as:
- credit card holder name verification use full name,
- shipping couriers will deliver when full name is used,
- and most address validators dosen’t use name but just the address itself.

Searching your database for a specific customers last name would then “just” require you to search the full name entity cells “containing” (a partial match for) the last name (as opposed to search all last name cells for a “=” match).

Agree, agree, agree. But one of the biggest fights I get with data and business models. No one ever seems able to tell /why/ we need to be able to search for the data like this, but it’s just assumed. I loose the fight a lot, so will totally steal your article as more best practice.

Another is thinking of internationalization. Phones are not all in the same format, and some put the family name first. Labeling split fields can also be an issue then, resulting in your data being inconsistent, so the worst result.

Thanks for sharing this.

Particularly interesting the case of those ‘previuos/next’ buttons not being used. I think it’s a very good point to highlight how mixed interactions (tap the field or use the GUI elements) do not work – finally too many options only create confusion.

I would expect those prev/next to move to a previous/next field (group) as a mobile phone number, for instance. I guess tapping directly on the field is the result of this uncertainty over the role of those buttons. And possibly the fear of losing the already filled fields < and this is something that has huge role of form filling esp. on mobile where the task might prove particularly painful, and/or of vital importance.

I can see the point in a single field for the name, but I’d say this is a ‘minor crime’, and we also really have to consider the payoff and cost of normalising the name on the back end… (you know, back end users deserve their own fair amount of, at least, decent user experience).

I can think of quite a few reasons not to have a single attribute for the name in a relation based on a relational model, though. Legacy issues, 3rd party compatibility being two of those.

Not to mention some foreign nationals do not share the same concept of first names and last names. Take an application form for a post graduate student program for example. You should see how many people from Asia tried to split their names. Worse, how do you search for such students in the database?

A very useful article – thanks! I’m interested in the ‘Note’ at the end though. Although I can see many practical reasons for wanting to break up the address field – much as I can for splitting up the name field – is it true that people view elements of their address as independent entries? Is there data on this?

My personal view on my address is that it’s a single thing (“where I live”), so I’d be interested in the evidence that the majority of people think differently.

I also find this suspicious. I have successfully built some (big) products with single address fields, and it seemed to work fine. Additionally, it saves much tedious interaction if you want to be able to deal with corporate/international addresses, which can go to SEVEN lines, easily.

Lately, I am more sure of it, especially in some contexts like not entering your address, since online maps use address as a single line. We have to concatenate it anyway to send to the map service, and there are small but increasing use cases where users can simply copy or link addresses between these services instead of typing.

The purpose of the “note” text was to state that we only have conclusive observations in regards to the single entity examples stated in the article. For other cases (such as an address) the test data was inconclusive (neither qualifying or disqualifying it).
I’ll edit the note text to be more clear, sorry.

With that being said, you might be right in users considering an address as single entity – we (currently) just doesn’t have enough test data on it.

Regarding the keyboard auto-closing: iOS does not allow scripts to focus a new field except within the context of a touch event. A keyboard event is not good enough: iOS will blur the old field but refuse to focus the new one, resulting in no field focus; and so the keyboard is closed.

I imagine what Macy’s is trying to do here is automatically set the focus on the second field once you’ve entered three digits in the first field, which is a common approach to resolving the navigation issues of split fields. It works to some degree on the desktop or mobile browser without this restriction (though plenty of additional issues arise once you begin backspacing!), but fails terribly on iOS.

Regarding a first name / last name / full name dilemma, if you plan to go international this is somewhat more problematic. For example, while Americans and Scandinavians feel comfortable with marketing emails starting with “Hi {First Name}”, Germans and Austrians in general expect a “{Title Surname}” -approach.

clearly if it says First Name then you put your first name not your full name.. But I do agree with the phone number with the 3 fields instead of one. Also keep in mind, maybe users have an extension in their phone number that doesnt go into the last field if your phone number has three fields…

Premium Research

Get full access to Baymard’s 78,000+ hours of research and empower your UX team and decisions.

Audit Service

Get Baymard to audit your site’s UX performance, compare it to competitors, and identify 40 areas of improvements.