Forms

Why Users Fill Out Forms Faster with Unified Text Fields

Nothing turns users off more than a long and complicated form. There are many ways designers can simplify their forms to make them faster and easier to fill out. Using top aligned labels on your form fields is one way. Replacing your text field CAPTCHA with a lighter one is another. Even cutting the number of optional fields can help.

But an innovative way to make your forms faster and easier to fill out is to use unified text fields to gather the information that normally takes multiple fields to gather. This dramatically reduces the number of text fields and dropdown boxes on your form. And the fewer text fields and dropdown boxes there are, the faster and easier it is to fill out your form.

This is because users don’t have to tab as much. With too many text fields, users have to constantly type-tab and type-tab, hopping from one field to the next. This slows users down because it puts them in a stop and go rhythm while mentally preparing what to type for each field. Also, think about novice users who use their mouse to move between fields. That’s a lot of hand movement between the mouse and keyboard that can make filling out forms difficult.

What’s more is that unified text fields mean fewer dropdown boxes for the user. Users don’t need to take their hands off the keyboard to click and scroll through a dropdown box. Keyboard users also don’t need to fiddle with the arrow keys to select from a dropdown box. The time and effort it takes for users to give their information are less than before.

When you use unified text fields with top aligned labels, the user’s visual fixations are less and move in a single, vertical direction. When the form fields are not unified, the user’s visual fixations are more and move in various directions horizontally and vertically. This means that users are not only doing more work with their hands, but they’re also doing more work with their eyes, slowing them down even further.

Another benefit to unified text fields is getting the user’s information in the format that you want without mistakes. Many forms force users into a format by breaking their input into separate fields. Unified text fields combine user input into one field that specifies the correct format. By using placeholder hint text inside the field, users can see what format you want before they type.

Unify the Fields You Can

There are many benefits to unified text fields. It’s important to note that you can’t unify all types of fields. The example above shows a few common fields you can unify without a hitch. If the goal of your form is efficiency and ease of use, unified text fields can give your users the boost they need.

As innovative as the technique is, it’s wise to test it on your users so that you can get the best results possible. Every situation is different, but make no mistake about it, the unified text field is definitely a new technique that designers should use more often.


Book

Affiliate

elegant wordpress themes

This Post Has 60 Comments

  1. TMik Reply

    Love the idea and would love to do this. I see a problem with getting useful data in a database. For example, how would your sort data by state?

    • Ryan Doherty Reply

      You need to validate the state entered. Or use some AJAX-style helper to autocomplete the state name to normalize users’ input.

    • Udit Reply

      If you enforce the format in which the user enters the data, then its easily parseable on the backend.

      eg.: City, State : San Francisco, CA
      enforces the comma separator.

      In addition to thinking about the question…..do you really give a shit what state they come from?

      • Mark Holmes Reply

        If you don’t care what state they come from, why collect that data at all?

      • Berin Reply

        If you’re collecting it then it stands to reason that you do care about it, e.g. for mail outs or delivery.

        To the author: I like the ideas in this article. The only issue that springs to mind is battling the current status quo with forms.. people are more familiar with seperating out [prefix] and [number] for phones, vs the [prefix]-[number] type format. The gains in usability may be lost if the user submits incorrectly formatted data.

    • Alex Reply

      You split up the data before you store it. The field unification is in the front-end only.

    • Oscar Reply

      Validate & Normalize it on submit.

      • Jon C Reply

        Definitely split up city and state at the comma or space (if the user omits the coma) on submission. The last two character string is the state. Look to validate the state on the state table and same goes for the city name.

        Alternately, if the user’s location is unimportant, just omit this field altogether.

        I have a solution for performing the validations for you if this is not your expertise. It’s called http://www.SiteBrains.com and I’d be happy to help you set it up. It’s a SaaS solution for performing custom field validations without having to write a line of code or mess with your DB.
        It also performs other validations such as checking for spam, e.g. comment spam, profanity, etc. as well as username validations, strong password validation, email validations, etc.

        • coderjoe Reply

          The sitebrains.com online demo fails to allow valid e-mail addresses which include a plus in the e-mail.

          i.e. joe.user+string@example.com

          This instantly reduces my confidence in that solution.
          I’ll be sending them an e-mail asking why this is the case.

  2. Nev Stokes Reply

    I agree with most points, however I fail to see how a unified text field can possibly get the users information in the format that you want. Sure, it can *suggest* how to do it but once they focus on the field the formatting suggestion placeholder is lost. It’s something the user has to remember and even they there is no obligation for them to adhere to it.

    If you want to guarantee that your data is in the format you need it to be then I’m afraid that unified fields just don’t cut the mustard.

    • Udit Reply

      Instead of putting the suggested format as a placeholder text, you could put it as a part of the label:

      City, State (eg. San Francisco, CA)

      Phone Number (eg. 641-678-9876)

      The example part could be in a lighter font to as to be helpfully distinguishable from the actual label.
      That way the user still gets the advantage of seeing the suggested format when they’re focused on the field itself.

  3. Eddie Edison Reply

    In certain cases this is not appropriate though!

    Users might tab to the ‘Date of Birth’ field without reading the help text (which would have now disappeared) and proceed to enter their information. But the only two countries in the world to use the date format ‘mm/dd/yyyy’ are USA and Belize, meaning the rest of the world have a large possibility of entering this date incorrectly (dd/mm/yyyy)! If a company then used my date of birth for verification if I phoned them up or maybe to reset my password online the information would be incorrect, locking me out of my account!

    Also, the only reason I’d provide a company with my address online is if they were going to send me something. In this case, I’d much rather have extra text fields that I could leave blank than try to squeeze my address into one text field and risk the package not being sent to the correct address.

    Finally, if a user is proficient enough to navigate text fields in a form with their keyboard, they would be proficient enough not to have to use the mouse when using dropdown boxes!

    Sources:
    http://en.wikipedia.org/wiki/Date_format_by_country

    • Brandtley McMinn Reply

      You can use a js library plugin (or roll your own) like meioMask to format the data as it’s input by the user using predefined mask formats. This way, you can define a sequence of characters that only input with valid characters (ie: numbers for a credit card num field). Using inline form validation shown above, you could notify a user of an invalid character as they’re typing it in, thus simplifying the need for unifying your field input for storage in a database.

      As for tabbing through a form and handling select lists with the keyboard, not all users are created equal 😛

      Cheers

      • Mike McNally Reply

        So if you get “03/10/2001”, is that “10 Mar 2001” or “03 Oct 2001”?

  4. Andy Baker Reply

    Give me a reliable algorithm for extracting firstname and lastname from a unified name field and I’ll give it a shot.

    • Jiang Reply

      Try this nifty little module. http://code.google.com/p/python-nameparser/

      But… why not just treat it as a name?

    • davidbitter Reply

      This is pretty reliable for me:

      function nameToArray($oldName) {
      $name = array(
      ‘first’=>”,
      ‘middle’=>”,
      ‘last’=>”,
      );
      if ($oldName) {
      $oldName = trim($oldName);
      $nameArray = explode(‘ ‘, $oldName);
      if (count($nameArray)==1) {
      $name[‘first’] = trim($nameArray[0]);
      } elseif (count($nameArray)==2) {
      $name[‘first’] = trim($nameArray[0]);
      $name[‘last’] = trim($nameArray[1]);
      } elseif (count($nameArray)==3) {
      $name[‘first’] = trim($nameArray[0]);
      $name[‘middle’] = trim($nameArray[1]);
      $name[‘last’] = trim($nameArray[2]);
      } else {
      $name[‘first’] = trim($nameArray[0]);
      $name[‘last’] = trim(end($nameArray));

      }
      }
      return $name;
      }

      Sure, you can get some weird results if someone enters “Dr. James P. Cunningham Jr. Phd”. But for the vast majority of people (especially if ask for First and Last Name as the field title) will enter just want you’re looking for.

      • Jeff Reply

        This is not a good method of parsing names. Many people have spaces in their last name, such as “Van Dyke” or “Van Buren”. Your code will treat “Van” as a middle name if none is entered, or will treat the Middle and Last Name portions as one single long Last Name if the middle name is entered.

        Sincerely,
        Someone who has a space in their last name and is tired of being neglected by programmers.

        • Toon Van de Putte Reply

          As a European who often fills out forms on US websites, i completely agree. There is no way you can automatically parse a unified name field, or a date field for that matter.

          As for addresses, this can also be problematic in Europe, where different countries often have different ways of writing an address. Postal codes are often completely different and don’t follow a single pattern. The concept ‘state or province’ is pointless in many smaller European countries.

          So, this form layout might work for a very specific US-only audience, but would break down very fast in an international setting. And you’d only realise that once wrongly parsed data has been stored in the database. In the case of dates, you might never realise it until somewhone starts investigating all those support tickets about incorrect birthdates.

          Frankly, I’d take the approach to ask for the absolute minimum of information, to compensate for the extra cognitive load of a slightly more complex load. I’d only ask for the address if and when I absolutely need it (to send something via mail).

    • christophe HERMIER Reply

      +1.
      That’s just an impossible task !
      I know it I had to import some “unified” data in a database with two fields and can tell you there will always be situations where you just can’t decide which is which or even where one starts and the other ends.

    • Hutch Reply

      @andy baker: is that even possible, i’ve seen two people with names like this, joe bob smith, in one case they’d want the algorithm to pull ‘joe bob’ as the first name and smith as the last name. in the other case, they’d want ‘joe’ for the first name, and ‘bob smith’ as the last name.

      while both are unusual cases, at internet scale these things come up.

    • Anonymous Reply

      You don’t ever need to split someone’s name into components, and you shouldn’t try. Always accept someone’s full name and treat it as a unit. Remember, not all cultures (and not all humans) have exactly two names divided by personal and family; don’t try to make that assumption. Some people have one name, some people have three or more.

      • user Reply

        pretty much all of health care and insurance with dependents and insured

        mary smith

        bob smith

        sally smith

        one is the insured; the other two are dependents

        • Daniel Rose Reply

          So what do you do if Mary Smith is married to Bob Porter, with the child Sally Jones? Married people don’t have to have the same last name, and the child might have another last name again (ex. from an earlier marriage).

  5. tomelders Reply

    The issues regarding data integrity are fairly easy to fix.

    For date formats, ip detection would indicate which date to use, which could be added as a hidden form field so the backend can figure out what the user intended. Also, any month value greater than 12 would indicate that the user is using an alternate format. I might also suggest adding a confirmation panel which updates as the user is entering their data, or at the end of the process.

    For things like city & state in one text field, It’s certainly possible to compare the inputed values (split by spaces) against a table of states and cities.

    I think the point to remember is that this approach will always require much more behind the scenes work, but it’s worth it if it gets more people to complete a process.

    • Jon C Reply

      @Tom – great idea to detect the user’s IP address to determine the appropriate date or telephone number format. I also agree that real-time feedback to validate each field and provide the user a confirmation is the only way to go!

      And I totally agree with your take on city and state. But I disagree that this has to take a lot of behind the scenes work. I developed a product (and service) that provides software as a service to handle your field validations. It uses ajax to provide field by field validations and issues confirmations to the user as input is entered. It even tracks the user’s ip address and determines their approximate location, which it passes to you as hidden fields. Then it validates each entry, such as state name, city name, etc.

      This is all turn-key. No coding required. we are in beta and I’m looking for beta users and feedback. The service is free, at least for now. Please check it out and let me know what you think — http://www.SiteBrains.com

      • Gary B Reply

        Yeah, figure it out by IP because people NEVER travel to where the IP would place them in a country with the opposing date format being the norm, right?

        BTW, using the comments section to advertise is rather lame.

  6. tomelders Reply

    @andy baker: I’d question wether people really need the users first name and surname for most projects. Having “Welcome back Tom” on every page hardly seems worth the effort. Username probably makes more sense in most cases.

  7. Lance Kidwell Reply

    Regarding the unified name field – I’ve found for most applications there is no need to store the name parts separately.

    The most obvious use case would be customizing emails with “Dear {first-name},”

    But for account information, CRM, credit card authorization and others in that vein there isn’t really a need for the database to know what part of the name is what.

  8. Court Reply

    While there are certainly situations where less user-friendly forms are required in order to ensure without a shadow of a doubt that the user information is absolutely pristine, the vast majority of forms on web apps simply do not require such extremes.

    Through the use of javascript and validation/filters on the backend, you can go a long way in ensuring that users enter correct information in the six fields above.

    You could use an autocomplete mechanism for city/state to ensure that they are entered in the expected format so you can parse the string to store in a more “sortable” format in your database.

    You could use javascript to guide the user through filling out there birthday (and inserting the slashes automatically) and render the entered date in a human-readable format next to the field so that if they do something such as swapping the month and day, then they have a visual guide in realtime that brings it to their attention.

    You could provide similar visual cues with javascript for the first name/last name parsing as well, and perhaps even provide a mechanism (like allowing them to enter in “last, first” format if necessary or the ability to split the fields into individual first and last) in a situation where someone’s name really can’t be parsed by a simple parsing mechanism.

    I am not a user-interface expert, so I’m not sure how usable these ideas actually are in practice. That said, I think the problems described in these comments (for the vast majority of cases, but obviously not all) smell a lot like software developers not wanting to spend much more time to get creative in how they handle user input in order to make filling out web forms as easy as possible for most of their users.

  9. davidbitter Reply

    This Unified Text Fields approach really works. You have to put some more effort into your programming– and it some cases the data is not 100% perfect. But 99% of the time it is (if you do it right).

    Combine it with some good validation and you’re set.

    It’s pretty easy to extra first and last name from a single name field. Couple of lines of code in php or ruby. You can do it with great accuracy for the vast majority of names.

    Combining City and State– I wouldn’t do that (unless I know I’ll never need to sort/filter by those).

    But dates, that’s no problem too. Format the date on the server side based on what the user submits. If you find you can’t format it– let the user know in validation. But try first. php makes it really easy to take almost anything someone enters and turn it into a ready-for-db date.

    There are tons of great ways to format data even as the user is typing. You can format it for them like magic and they can just keep moving on their merry way.

    It’s not absolutely perfect so maybe you can’t use it if you’re writing Tax software– but for most applications it is the right solution.

    Yes… it takes a little more work on your end, but anthony is right. Go unified!

  10. Will Grant Reply

    “This is because users don’t have to tab as much.”

    I’m afraid I disagree – ‘average’, non-technical users simply don’t tab between fields. They mouse and click, mouse and click, etc.

    In fact, I can’t remember ever seeing a user in a field test (we do UI testing) use tab to traverse a form.

    I think the “orderly” nature helps, but maybe only with mouse alignment to move between fields?

  11. Ian Reply

    In terms of UX, this is a good idea and it makes sense. Unfortunately it doesn’t from a development and database point of view. So I guess this would be entirely situational.

  12. G Reply

    good article…completely agree, too many text fields and validation fields initimidate users

    @andy baker
    first you have to decide if you really need first name and last name. If your biz requires first name and last name fields specifically, then i guess its better to have 2 fields.

    @eddie
    what if the placeholder gets displayed right below the text field when you start typing and disappears when you leave the text field. Displaying the tips text next or below the text field makes the form look very cluttered.

  13. Chris Reply

    Andy: Agreed. It does make me wonder how often I could do without the distinct first name and last name, though.

  14. AnonGrammar Reply

    You might make fewer mistakes using “less” and “fewer” if you used “less” less, and “fewer” a few more times.

    What’s more is that unified text fields mean less dropdown boxes for the user. -> What’s more is that unified text fields mean *fewer* dropdown boxes for the user.

  15. Brendan Reply

    >less text fields and dropdown boxes
    >less dropdown boxes for the user
    >user’s visual fixations are less

    This was a pretty good article, with some useful tips, but for the love of god, FEWER!!!

    Unless you have so many text fields that they are uncountable, then reducing their number will give you FEWER fields: http://grammar.quickanddirtytips.com/less-versus-fewer.aspx

    Apologies for grammar nitpicking.

  16. Stacia Reply

    Sorry to add to the negativity, but why assume all users tab between fields all the time? I highly doubt that no one ever uses their mouse to click into the next field.

  17. Allen Reply

    To get unified fields to work requires a good amount of client + server-side validations. You may be able to coerce the right format (e.g., automatically inserting -‘s after 3 and 5 numbers in a SSN field), or show an error when the format isn’t what you expect (e.g., phone number not in a xxx-xxx-xxxx format), but getting field interactions right does require a good bit of work.

    The reality is, there will be a set of power users that’ll tab through fields and blast through the form, and the majority of users will click each field and slowly type out the field in their preferred format. Being more accepting of a variety of formatting for the latter group of users (e.g., SSN is ok if they don’t include dashes, as long as it’s 9 digits) is probably the best you can do.

  18. JL Reply

    Why don’t you use unified text fields to “Leave a Reply”? Seems appropriate doesn’t it?

  19. anon Reply

    Uh, k.

    There isn’t a hollistic approach you can take here. There’s some data analysis you have to do for each value.

    You seem to have ignored the most important thing of ux – THE USER’S DATA IS SACRED.

    You’ve just sacrificed speed for quality. Every piece of information you’re not checking or enforcing in the UI is one more step closer to having incorrect information.

    Of course, you should be also doing data validation. Your UX is the first line of defense, however.

    Names are so complicated that I would never recommend separating them. “Full name” is appropriate. If you need to search this data, let regex do the hard work.

    Social Security is one value. Your UI should be automatically filling in hyphens and overtyping hyphens if the user decides to type it. A single box is appropriate here.

    Phone number is one value. See Social Security.

    Date of Birth needs to be enforced with separate fields. Yes, it sucks that the USA uses MM/DD/YYYY. No, you can’t do anything about it. These are known values for each month/date combination.

    City and State should be separated. State is a known value, city is not.

  20. starpause Reply

    a lot of the comments here dismiss the potential for immediate feedback through AJAX (or whatever you kids are calling it these days). which leads to my next comment …

    i’m exhausted seeing static comps and explaining the subtext timelines. i DEMAND every designer in every discipline grab one of these muji notebooks (cheap and efficient).

  21. musthafa Reply

    It was Very refreshing post with attractive ideas. I am looking forward to read your next great article.keep continue your post .i like your writing style.thanks for sharing

  22. Ben Clifford Reply

    Two other things that spring to mind:

    When using multiple fields, I’ve often seen “helpful” code that advances your cursor to the next field automatically when you’ve entered enough so as to give something of the experience of a unified field. Except if you’re the kind of typing that types fast and wrong and deletes a lot, that fails because backspace doesn’t go back a step.

    Having “unified fields” and not trying to parse more structure is much more accepting of the fact that you probably chose a mechanism that was too specific: eg parse +443331122456 into NNN-NNN-NNNN (or even 0333 1122456)

    (ps autogenerating addressing titles from input data sucks: nothing speaks impersonal robot writing more to me than DEAR BENJAMIN)

  23. JB Reply

    I agree with the OP about simplifying forms but not only for the reasons they listed. Every poster here, including the OP, should
    read this list of things that most programmers get wrong about
    names:

    http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

    In the real world you just can’t structure names and addresses.
    e.g. It is pointless to separate first and last names.
    Just ask for an optional preferred abbreviated name and be
    done with it. This applies in every country because every
    country has a variety of nationalities represented.

    I’ve also lost count of the number of forms that don’t allow me
    to enter my own address correctly. e.g. Zip code required when
    it’s not a US address or street address required when it’s a PO Box.
    In addition many localities have completely different
    addressing conventions that don’t fit into the form you are
    probably familiar with e.g. putting the street and flat number
    after the street name and separated by spaces.
    “Structuring” addresses gives you little to nothing and just aggravates your customers.

    Also, key tabbing? The complete mess that is forms on the web
    means that most users usually don’t use the tab key unless
    they are very familiar with with the particular form and can be
    confident it will even work.

  24. Sandy Reply

    Just curious if you’ve tested this with the appropriate validation (especially city/state) and tested speed after the user deals with issues like “Anytown ST” instead of “Anytown, ST” if you’re using a simple enforced comma split as suggested above, including correcting for typos in state names if they choose to spell it out.

  25. Steve High Reply

    I think this approach is great, provided you have someone who can code a comprehensive client-side validation. This does add a bit of work on the server-side of things, so web developers should be extremely familiar with regular expressions and whitelisting. If the server catches an error that the client missed, there should be mitigating steps to alert the user without forcing them to refill all of the fields (unless it is something like a password or god forbid credit card data).

    That said, back-end web developers that dont sanitize user data shouldn’t be in this business to begin with.

  26. vordan Reply

    And yet, nobody sees the real problem: this works just for small forms, with few fields.
    Tell me how to use the technique when there are 40 or 50 fields?
    This is not really a programmer’s problem, just designer’s, and only for small contact forms. We really can’t talk (or need) about speed here. It’s just six lousy fields!

  27. Jonathan Gale Reply

    Good stuff, common sense really!

  28. aggregate Reply

    I’ve always hated those drop-down ‘state’ menus. It’s so much faster to type the two-letter postal abbreviation than to go hunting through the six states beginning with ‘N’ and repeatedly overshooting because you think it’s further away than it is. And can’t state be determined from zip code anyway?

    I think the underlying problem is that too many people produce forms on autopilot. Every instantiation should be a design decision — maybe keep it the ‘traditional’ way if there’s a reason to do so, but at least let there be a conscious evaluation before that decision is made.

  29. Paul Trumble Reply

    Not to state the obvious, but a big premise of this article is that somehow swapping a tab key for a space/hyphen/slash key is somehow more efficient. I’d argue that at best it’s a wash.

    You could argue that conceptually it’s easier for users to remember some of these items as a single entity than it is for them to parse out the month of their birth. But you didn’t.

  30. Joe Reply

    Interesting idea. Have you actually proved it works?

    It’s a nice idea but could be taken as the best way of doing it by less experienced designers. Evidence is needed that it is actually better.

    You’d need to track:
    -Completion time
    -Error rate (I’d suspect this will be higher with the suggest approach)
    -Conversion

    Suggesting Ideas with little experiment evidence that it will work can be dangerous.

    The assumption that all users tab between fields is also wrong. Many of the user tests I’ve seen users take the mouse and move it to the next field. Tech types, sure we tab. Regular people less so.

  31. antarctic74 Reply

    Replacing dropdown boxes with text fields might backfire on mobile users. I prefer using the spinner on iPhone to scroll through a list, especially if the options are long words that take time to type on virtual keys.

    Detect a mobile user agent and switch back to dropdowns?

  32. Ronald Thompson Reply

    good article and discussion – I completely agree, too many of your arguments … and I like to point out this article about forms, input fields and fault tolerant systems/planning:
    http://ux4dotcom.blogspot.com/2009/06/form-of-forms-we-need-them-but-also.html

  33. lablucy Reply

    How about the fold? Placing labels above textfields makes the form double in height. That can’t be good for conversion.

  34. shareen Reply

    You are using inline text for instructions on how to use these fields which is NOT good practice. What happens to the text when the user clicks into the field? It will disappear so they could easily forgot the inline text (in this case used for formatting)

  35. Nikola Radulaski (radulle) Reply

    I agree to some extent, but on mobile devices when you have on screen keyboard I prefer to keep all of the fields at the top so that user doesn’t have to scroll down. For this I can do two solutions:
    1. Have only a few of the same width and than swipe to the right as the user is filling the form
    2. Try to fit all on one screen above the keyboard, but than have to put several fields in one line.

  36. Jitin Mishra Reply

    Unified text fields are best if you want someone to get done with CTA, as it is not time-consuming and is best for it. However, nonunified ones can be used in other essential portions, like when someone has to fill in their addresses.

Leave a Reply to Gary B Cancel reply

Your email address will not be published. Required fields are marked *