I am entertaining the notion of a single field for name entry on our scheduling web app. I think this is an excellent case for a "forgiving format" to make it easy to enter their names quickly. I would label it and possibly put additional placeholder text guiding the user. Like this:

Either raw or with placeholder text.

It's important to catch first and last name correctly because it gets saved in our contact database that we provide to our users. However, people could enter "Joe De Maggio" or "Dr. Chopra" or "Ms Sally Ann Mc Dumont". The possibilities are many.

Is this choice wise? Is the engineering worth the UX? Does anyone know a plugin that tackles this?

  • 1
    I think the UX would be pleasant but I think your data will quickly become dirty, more so than if you had the data fields separated. It is unfortunately impossible to deduce what someone wants to be referred to when they list their name as Joe De Maggio. Commented Jan 5, 2012 at 21:53
  • Who are the users: co-workers/customers/both?
    – dnbrv
    Commented Jan 5, 2012 at 23:20
  • 3
    Does the scheduling tool have to notify the people that have their name inputted? If so, how do you deal with duplicate names? If that's not an issue, then that field is really just a free text field, and I think it's perfectly acceptable to leave it as one field...let people enter the name any way they wish to.
    – DA01
    Commented Jan 6, 2012 at 1:33
  • Yes it does notify them. Emails are sent out when people book saying Dear [name]. It also accepts imports of data from CSVs and we are making the customer table map to CRM API's. I wish it were just a name field.
    – Itumac
    Commented Jan 6, 2012 at 13:40
  • 1
    @Da01 Using a name as a unique identifier is a horrible idea and that thought should be banned from human consciousness. Commented Apr 20, 2015 at 1:47

12 Answers 12


There are a great many assumptions people make about names (also: W3C: Personal names around the world.)

Thankfully the W3C have some excellent advice on field design for names, of which the simplest is to use two fields (but not for first/last):

  • Full name
  • What should we call you? (for example, when we send you mail?)
  • 1
    Thank you for pointing this out (it saved me looking up the links :-) (Though I would change the "should" to "may" for the second field, but that's just one of my pet peeves). Commented Jan 6, 2012 at 7:41
  • 2
    IMO no answer could be better.
    – m-smith
    Commented Jan 6, 2012 at 13:04
  • 3
    +1 It's worth noting that GMail (Google Contacts) provides only an "Add name" field as well.
    – msanford
    Commented Jan 6, 2012 at 17:26
  • 5
    This is great, but what do I do for the simple case of a user like myself "Matt Johnson" when I need to run a report showing names as "Johnson, Matt"? Do I add yet another field for that? Commented Apr 3, 2013 at 0:59
  • 2
    @MattJohnson why would you need to do that?
    – Eric Bloch
    Commented Jun 14, 2017 at 21:28

Here's a scenario where it might work to your advantage:

  1. The user enters their full name in one field.
  2. The system reverse concatenates the name as best it can.
  3. The field shows the split apart name so the user can verify it.

If it's correct, no further action needed. If it's wrong, a little edit button lets them go to the complex form (two fields) and correct their name.

But is all the development required to create a smart enough algorithm worth the saved microseconds of user time? I think not. I would spend more time on properly cueing the user to what your form expects, i.e. use standard, best practices.

Here's how I think it actually works for most people:

Name Fields Cartoon

  • 9
    I love your pens Commented Jan 5, 2012 at 22:50
  • 5
    Each is an arrow in my quiver.
    – Taj Moore
    Commented Jan 5, 2012 at 22:52
  • 6
    We have a scanner that sends files right to the server. Easy as pie. These are my standard drawing tools: ux.stackexchange.com/a/14818/4695
    – Taj Moore
    Commented Jan 5, 2012 at 23:10
  • 4
    +1 for the visual. I don't care if I agree with your answer or not, it's the visual that wins it for me. ;)
    – DA01
    Commented Jan 6, 2012 at 1:33
  • 3
    This entire case makes the (often incorrect) assumption that the user has precisely two names, and that their personal name comes first. Commented Jun 4, 2014 at 16:14

It does look like good UX but if the DB has different fields it's highly improbable that you are going to make it right 100% of the time.

Here is what I would do: implement a very smart parser, but, before commiting, ask for confirmation from the user. Chances are that the parser made it right (then the user would only have to confirm), and if it made it wrong, then provide two inputs or a reasonable amount of alternatives.

Let's say she enters Lalita Angie Singh:

Is this correct?

  • Name: Lalita Angie
  • Surname: Singh

No! Edit manually or continue with the form...

...in all, it does seem too much for a simple an imput as Name and Surname are, but craftily executed can be quite a novelty.

  • 1
    Ha! I saw your answer after I posted mine. Great minds think alike.
    – Taj Moore
    Commented Jan 5, 2012 at 22:51
  • 1
    That's an extra step in the workflow. I'm not sure whether it's necessary.
    – dnbrv
    Commented Jan 5, 2012 at 23:13
  • @dnbrv yeah, I deleted the continue button because it wasn't necessary. In fact it's the same idea tajmo wrote, but not so well explained. Commented Jan 5, 2012 at 23:34

It makes for a great idea if the DB is also dealing with it as a single string. (Usually with a follow up field requesting how the user would preferred to be referred to in "short" form. e.g. Full Name: Dr Nicholas Riveria Short Name: Dr Nick)

If the DB is expecting the name as seperate fields then attempting to create a automated system to split the full name into its component parts is an almost impossible task... mainly because even humans tend to get it wrong (and if a human can't do it, what chance do they have in getting a machine to do it).

The classic examples of automated systems (and humans) failing at this is when it comes to dealing with users from cultures where it's normal to cite one's family name first. e.g. A lot of Asia and the Middle East.

My suggestion would be to change the DB instead... but failing that keep the fields in the UI in line with the DB and try one's best to indicate to the user which name should go in which field.

  • 3
    If the DB is expecting the name as seperate fields then attempting to create a automated system to split the full name into its component parts Splitting a string is trivial. Getting accurate, useful data from a string of dynamic lengths and assigning a type to each portion is the difficult part. Commented Jan 5, 2012 at 21:55
  • 1
    The DB is not changeable and doesn't map to a single string. I can stab at the algorithm but I know it will never be perfect. I am letting go of the idea.
    – Itumac
    Commented Jan 5, 2012 at 23:19

The viability of splitting a single field into name and surnames depends on:

  • The desired success ratio. You can apply some heuristics such as consider a list of common names and surnames or adopting rules depending on the country to increase the ratio but 100% success is not possible*.

  • The impact of a mistake. How bad are the consequences of splitting a name the wrong way? You may consider using two fields when users edit their name later. This way they can prevent a mistake.

I would label the field as "full name" instead of just "name".

*An example of a name that is impossible to split correctly is the full name of Pablo Picasso( http://en.m.wikipedia.org/wiki/Picasso) : Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso

  • 1
    Trying to split a full name into parts is fraught with risks - not only are there many ambiguities and odd cases and exceptions, if you happen to get it wrong then (a) it's something most people tend to care about, (b) most other places will have also gotten it wrong so the person brings a good deal of pent up frustration with them, and (c) often they are the very type of people that are likely to make a big stink about their special snowflake of a name..
    – Erics
    Commented Jan 6, 2012 at 2:05
  • I agree on most of your ponts but I wanted to note in my answer that point (b) is an assumption that depends on the specific application. For example, an application that displays the full name most of the time is not heavily affected by a mistake in the splitting process.
    – Pau Giner
    Commented Jan 6, 2012 at 8:35

Although I particularly like https://ux.stackexchange.com/a/15778/40116 the business requirement as stated by the OP.

It's important to catch first and last name correctly because it gets saved in our contact database that we provide to our users.

Would override any engineering or UX alterations. For the OP, they shouldn't change the way the input is done unless the business would agree to the change as this would also have downstream effects on their existing legacy infrastructure which may also require a proper split of first name and last name.

The closest thing I would recommend is to just trim the names for extra spaces at the end and in between and prevent numbers in the name.

The answer https://ux.stackexchange.com/a/15778/40116 would make better sense for self registration, but for administrative data entry for government or banking applications it is best to keep it separate especially for sorting.


The benefit to unifying the name field is that it's faster for users to fill out. This is due to less tabbing,flexible formatting and fewer eye fixations.

But it's not always good to unify the fields. What if you need to parse the last name from the first? Sometimes it's unclear which is the last name if you have a name with many word strings like Ludwig Van Beethoven. If you need to parse the last name for your app, you should use separate name fields.


If you need specific information - be specific:

  • State you require BOTH a first name and surname.
  • It's very possible to automatically split the two strings into their required components.
  • It's also possible to apply validation routine to the input to ensure that two strings (no more / less) are entered separated by a space.

This would provide you with the same result as two separate inputs.

The main problem would the extra cost in terms of development time / complexity. You'd need to work out if the benefit justifies the increased cost.

  • 1
    Splitting a string is not a reliable solution. Spaces live in unpredictable places in names. "John Jacob Smith". "Ian Van Der Zahn". "Li Chiu".
    – ghoti
    Commented Jan 10, 2012 at 18:38
  • It's a possible solution - the validation routine would obviously need to tackle the problem of separating the names. Commented Jan 12, 2012 at 14:32
  • 1
    It may be possible, but just not practical in the general case. See stackoverflow.com/questions/1122328/… for a real-world example. Commented Oct 12, 2013 at 14:26

I think this idea has merit, but I also agree that parsing it correctly in the general case is going to take a lot of work and you may never get it 100% right. If this isn't entered as if it were a mailing addressee, and thus subject to some pretty strict conventions, I think you are asking for trouble (and by "trouble" I mean corrupted/dirty data).

In addition to a high level of exercise with unit tests, maybe a hybrid approach would work? Have a single field as you want, whose contents are parsed out into additional fields that can be hidden behind a collapsible section of the UI. If the user wants to make sure you parsed it out right, they can expand the div (or you can do it for them when they tab out of the textbox) and they can see the split-out name. If it didn't work right, they could edit the individual name fields.

I think overall this would give your users the convenience you're after in the normal case, while keeping the form usable in exceptional cases.


For me the basic principle should be: make things as simple for user as they can be, but then give them the choice to go advanced path.

In this case i would use single field with something like "First name, Last name" as watermark suggesting that user should use a comma to split first and last name. However, if he doesn't do it, you should split it automatically.

Then user should be able to edit it in his profile in more advanced way.

The perfect example is the Gmail contacts app. There is one field for name. the first word you enter is by default considered as first name, and the rest of the string is last name (didn't try with prefixes like Mrs. or Mr.). However, then you can click on three dots icon and a popup form with details comes when you have ability to enter first name, last name, company, etc separately.

In my opinion this is the best approach.

  • It looks to me gmail has name as one field mapping to the db.
    – Itumac
    Commented Jan 5, 2012 at 23:12
  • @Itumac gmail has 2 fields, and it messes all my Contacts because we use two surnames. Really nasty. Commented Jan 5, 2012 at 23:30

One field is always more favorable to fill in than two, but there are two things at play here.

1.Being inclusive and trying to cope with any name in a culturally sensitive way.

2.Formatting it to how much of the western world does.

Some cultures who don't even have family names but do have two or three names. If we are trying to format a name so it is correct for everyone then the only possible way is to have a single field and expect the user to know how their name is written.

However most places you are trying to send this data, CRM etc. wants a name to be formatted as First and Last. I would like to think that maybe sometime in the future a single field will be more the norm.

These two concepts will never work for everyone. Is it culturally insensitive to allow or force it to be formatted for most of your customers whatever that be? I'm not even sure how that would work in multi cultural societies (where I live)


The user won't always have a last name because it is culturally dependent. So even if you wanted to provide the user specific info from your database you wouldn't be able to do that for every user.

What you can provide users is their full name because everyone has a name no matter what culture they're from.

I was on the fence about using one or two name fields but this article convinced be to go with one: http://uxmovement.com/forms/why-your-form-only-needs-one-name-field/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.