Why Infield Top Aligned Form Labels Are Quickest to Scan

How easy is it for users to scan your form? If your form is hard to scan, it could take longer than expected for users to complete it. This leads to form abandonment and loss of potential sign ups. The way to avoid this is to make your fields quick to scan when users first see them and after they fill them out.

Scanning Pre-fill & Post-fill

When users first see a form, they scan it to size up the amount of time and effort it’ll take to fill it out. If they can’t scan it quickly, they’ll feel like it’s going to take too much time and effort and move on.

After filling out a form, users will scan it again to check if their input is correct. If your fields aren’t easy to check, users could fear submitting the wrong information and abandon the form.

To prevent form abandonment, you have to make your fields quick to scan pre-fill and post-fill. The quicker they are to scan, the less overwhelming your form will feel. The less overwhelming your form feels, the more it motivates users to complete it.

Problem with Most Forms Today

Most designers today align their form field labels in a way that takes time and effort to scan.

The two most common ways are:

  1. Top aligned labels
  2. Infield labels

While both are quicker to scan than left aligned labels, users still experience scanning issues.

Top Aligned Labels

Many Visual Fixations


In the top aligned form above, there are only 4 fields. But when you scan the form, it feels like there’s more to fill out. This is because there are 8 distinct elements that users have to scan.

The labels and fields are individual elements separated by whitespace. As a result, users process these elements with 8 separate visual fixations. The extra visual fixations give users more scanning to do, and makes them feel like there’s a lot to fill out.

Rows of Whitespace


Top aligned labels require rows of whitespace to group labels and fields. But these rows of whitespace act as invisible barriers that interrupt the user’s scanning flow. Users won’t fixate on them for a long time, but they’ll still get short unnecessary fixations.

The more fields you add, the more the form length grows. But with top aligned labels, the form length can grow a lot faster. Not only do the fields take up space, but the rows of whitespace add to the length even more.

Slow Checking Flow


When users finish filling out the fields, checking their input isn’t quick to do either. Users have to sweep their eyes up and down from label to input to see if they match up. The whitespace row and field border gets in the way of their visual path and slows their flow down.

Infield Labels

Fairly Quick Pre-fill Scan

The other common way designers align form labels is by placing them inside the field. The upside of this method is that users won’t feel like there are more fields than expected to fill out. This is because the field and label are one element. When users fixate on a label, they also fixate on the field, leaving no extra visual fixations.

Sometimes the color contrast on infield labels can look too faint. Infield forms that use light gray text for their labels can make them harder to read and slower to scan.


Infield labels can also have rows of whitespace that create unnecessary visual fixations. But you can prevent this by aligning the fields edge-to-edge with each other, whereas on top aligned forms you cannot.

Slow and Painful Checking

The downside of infield labels is that it makes it impossible for users to scan and check their input before they submit the form. This is because the label disappears when the field contains user input. 


Users have to delete their input to see the label again. But if they do, they can’t even compare because their input is gone. This forces them to have to use their memory to recall the labels for each field.

Infield labels not only create unnecessary physical work, but also unnecessary cognitive work. This can cause user frustration that leads to form abandonment.

Introducing Infield Top Aligned Labels

The ideal form is quick to scan before and after the user fills it out. Users need to feel that the form won’t take much of their time and effort. They also need to feel certain that they’re submitting the correct information. When your form meets both these needs, the chances of users completing it are high.


Minimal Visual Fixations

It’s clear that top aligned and infield labels aren’t the quickest and easiest to scan, but what’s a better approach? The better approach is infield top aligned labels.


Infield top aligned labels require as few visual fixations as possible when scanning. Each field contains both the label and user input. When users scan a field, their fixations hit the label and input at the same time. The close proximity and lack of visual barriers allow users to process each field quicker.

Lean and Compact

Infield top aligned forms take up as little space as possible. The fields align flush to each other in a grid, removing the rows of whitespace that cause extra fixations. This creates a lean and compact form that focuses the user’s eye movements in a concentrated area.


The grid’s efficient spacing also creates stronger association between relevant fields. The side by side placement of relevant fields (e.g. first & last name) allow users to focus on filling out the form row by row. Users don’t need to sweep their eyes in different directions because it’s the same pattern throughout the form.

Easy Input Checking


Checking user input is quick and easy. The labels don’t disappear like on infield forms, and there are no visual barriers like on top aligned forms. Instead, one visual fixation per field is all it takes to compare label and input.

The text styling also helps users check their input quicker. By making the input text bold and larger, and the label text smaller, users can distinguish them at a glance. 

Stronger Field Focus

When users select a field on top aligned forms, the field highlights, but not the text label. When users select a field on infield forms, the field highlights, but the text label can disappear or turn faint.


Infield top aligned labels give users the strongest field focus. The highlight border surrounds the field, label and input altogether. Users get a clear view on what field they’re on, and what they’re typing at all times.

The strong field focus is even more important on mobile where users look at the keypad when they type. After they’re done typing, they’ll look back up to the form to check if they typed their input right. The field and input are quick to spot because they’re highlighted together.

Guiding Form Grid

Grids are often used in design to guide element placement. Infield top aligned forms offer a form grid that help guide field placement. Since the width of the your fields will dictate the width of your form, it’s easy to figure out which fields belong next to each other.


The form grid creates itself when you stack and align fields into equidistant rows. This gives the form its compact and uniform look. Each field should have enough height to fit both the label and input text. You can divide a row into as many fields as needed, as long as the row’s width is equal to the others.


The field should not only be able to hold text, but other form elements as well. Your fields should have enough space to fit radio buttons, checkboxes and select menus if needed. All form elements become apart of the grid.

Paper Form Metaphor

Most tech-savvy users can recognize form fields when they see them. But older, less tech-savvy aren’t used to interacting with online forms. Infield top aligned forms resemble the look of paper forms. This can help those users feel more comfortable filling them out.


Infield Top Aligned Form Examples

Facebook’s sign up form looks overwhelming at first glance. It doesn’t encourage users to fill it out and it’s a pain to check your input. Turning it into an infield top aligned label form makes it easier to look at and more inviting to fill out.


Even with only 4 fields, Square’s sign up form takes work to scan. Turning it into an infield top aligned form makes it quicker to scan and encourages users to fill it out.


Infield top aligned labels don’t just work on short, simple forms. It also works on complex forms with multiple sections. Treehouse’s long sign up form has multiple sections and many elements. Turning it into an infield top aligned form not only makes the form lean and compact, but it also makes each section clearer.


When Top Aligned or Infield Labels Might Work Better

Not every form needs quick scanning for better conversion. Top aligned and infield forms still have a place in certain situations. Sometimes you need a form that’s simple to implement. Top aligned labels would suit you better in this case because you don’t have to worry as much about field sizing or label aligning.


Sometimes you’re working with a form that has very few fields, such as logins and newsletter boxes. Infield labels work best in these situations because there aren’t a lot of labels the user needs to recall. These forms almost always have the same field pattern that users can expect (e.g. username & password).

Different situations call for different methods. But when scanning speed and conversion are most important, choose infield top aligned labels.

Final Thoughts

Most websites today either use top aligned or infield form labels because they aren’t aware of a better way. But now there is one. With infield top aligned labels, users won’t feel discouraged or overwhelmed when they first see your form. Nor will they have trouble checking their input.

You meet user expectations and decrease form abandonment when your form is as quick as possible to scan. A successful form doesn’t just reduce the work users have to do with their fingers, but also the work they have to do with their eyes.

UI Design Kit


elegant wordpress themes

This Post Has 76 Comments

  1. Rob Reply


    A couple of things jump to mind though. How do you handle validation and errors? Without the white space its hard to put meaningful messages near to the fields that have errors.

    Also, there is often a need to put additional qualifying copy adjacent to fields as to why they are needed. Again there isn’t much space for these.


    • Alper Ortac Reply

      This. I really like the visuals and UX of the infield approach, but showing validation and errors would be an important addition to this article. Maybe that’s something for a follow-up?

      Coloring the border and adding a warning icon (infield, right-aligned) would be a possibility, but showing the error message could only be done by using a popout on focus.

    • anthony Reply

      For error messages, I would suggest inline tooltips placed above the field.

      For additional copy, I would suggest placing an information or question mark icon next to the label that shows the hint text in a tooltip.

      • Steve C Reply

        As a survey designer, I’ve done many tests on such ‘hint’ icons, containing additional copy.

        In our tests, respondents almost never see them, and of those that do very few access them. We concluded to never use them for anything we actually want a user to see.

        Granted this is in survey design where the ‘label’ (question) is somewhat longer and descriptive than standard form fields, so it may behave differently… but it’s one empirical datapoint about this.

        • Jens Martsch Reply

          If you only use colors and/or icons the user does not know what exactly he did wrong in the corresponding field.

          If you show validation errors only on hover it requires an additional action by the user.

          Showing the error message when focussing the field, could be one solution and thats how it´s done in modern HTML5 forms. The downside of this approach is, that you can´t style the tooltip.

          I think the best solution is to print the error message for each field after the label and before the input (because of screen readers). Because the length is not always the same (think of long messages or other languages) the fields/rows can´t be fixed height. So you have to deal with that if you got two or more columns.

    • Lewis Cowles Reply

      I Have to disagree with the premise of the article that scanning relates to difficulty filling out forms or preference; I also think the solution of in-field top-aligned is ugly and scarier for the user as it looked quite densely packed (everything was edge-to-edge), and would like to know how the design affects other elements such as auto-fills, diverse ranges of elements such as radio, checkbox, slider elements, multi-line text etc.

      One of the other things it is missing is the visual cue that this is an input field, and not some picture of a form some public-sector secretary cooked up; that you have to download, fill in and scan. Without guiding the users, just letting the pages speak for themselves, did you only check scanning? Or did you also check anonymous usage of the form for usability and ease of visual feedback? Did you see if your results were only for first time visitors? (I build apps, so a secondary concern for me is the work-flow order or forms and how easy they are for people who have to use them day-after-day).

      UX is absolutely not about isolated facts is the reason I ask these probing questions, and I really think when everything is put together left aligned labels work best for medium – large screens, and top aligned labels work for small screens; simply due to a lack of screen real-estate (i.e. top aligned labels are crap, but allow the form to display so we accept them).

      Thanks for the article, it certainly got the cogs turning

    • rizbaloch Reply

      Very well briefed and quite impressive approach to make complex forms look user friendly … error messages can be handled while placing it under the label & question mark icon can suggest additional information on hover … I have got what i was looking for,

      Thanks for sharing !!!

  2. Tim Cross Reply

    Ok, so great in theory. But how would you go about building this?

    This isn’t default form behaviour. Do you have any examples of the css/html (js) involved? I would be interested to see.

    I would argue that the forms aren’t any shorter and are actually more complicated to scan. The facebook before/after example is about the same height, apart from moving the submit button.

    • anthony Reply

      What makes it faster to scan isn’t the shortness of form, it’s the specific placement of the field and label. You should reread that article section.

    • Will Reply

      The basic ‘trick’ here is that what looks like the form field is an HTML container (say a list item) with a border added via CSS. Within that container is the label and an HTML input *with it’s borders removed* via css which makes it sort of invisible.

      I put together an example here:

      • Mike Donahue Reply

        Nice pen. I like that you used the list element to put it together. I also like additional attention to detail with the active field highlight.

      • Max Avedisian Reply

        Thanks for putting this together, was struggling until I found it! Props!

      • CStumph Reply

        You should be wrapping your inputs in the labels with the text contained within a span element that is a sibling to the actual input.
        This gives you the benefit of enlarging the click/touch target by default and the label passes along the click/focus to the input.

    • Drew Reply

      Here’s another example of what this might look like in HTML/CSS. I borrowed terminology from Bootstrap for some of the classes:

      Definitely do-able in a cross browser fashion.

      • Peter Reply

        I like that this is all in HTML, no CSS, but if I click in the top part of the box, nothing happens. (I have to click in the actual field.)
        Contrast w the two other examples that both highlight the field and move the focus to the start of the text field when I click the label.
        (I’m NOT fluent in HTML- my perspective is an advanced user >60.),css,output

        The high contrast, smaller font is perfectly readable, and IMPO, more readable than grey text. I also like that you DIDN’T make the label all UPPER, which is more readable your way.

        Thanks for sharing your code!

  3. Pablo Carrau Reply

    Great idea! It’s always driven me nuts checking inline fields which is why I always avoided coding them that way. I’ll definitely try this style out on my next project and see how it compares to previous ones.


  4. Sven Uilhoorn Reply

    One of the best posts I’ve seen so far on UXmovement. Finally a lengthier and more in-depth article with great examples!

  5. Larry Willis Reply

    Thank you for this article. I have discussed this very issue with my coworkers who don’t feel as strongly as I do about making forms quickly scannable.

    I hope this article will change that.

  6. Clayton Reply

    Hi Anthony,

    I like the look of this visually, but I didn’t see any reference in here to user studies or eye tracking research. Where did your insights for this new layout come from?

    • anthony Reply

      The hypothesis and reasoning came first and then I tested it. I encourage others to test it on their own if they are skeptical.

  7. Morgan Reply

    I like this, but one issue I see is how you would do error validation with this model.

  8. Martin Reply

    Just curious. This seems largely opinon, did you test / measure in order to come to your conclusions?

    • anthony Reply

      Hypothesis came first, then I tested it to verify. The reasoning is laid out. If you don’t trust it, I recommend testing it on your own.

      • Nick Reply

        Hi anthony, I am intrigued by the thinking and the article. If you do have testing and verification, would you mind sharing? I am curious to the methodology and the results you gathered. If you included it, would be a nice rounding out of the overall article.

        • anthony Reply

          I’m not allowed to share that under contractual obligations.

        • Grant Reply

          It’s odd that you would be allowed to share hypotheses and conclusions, but not be allowed to share method of testing and data. You’re making claims that, quite frankly, need to be substantiated by data. And by saying we can just test it ourselves, how can we do so—and expect to have similar conditions—without knowing anything about how YOU tested them? I’m calling your bluff and going to surmise that you haven’t actually tested this stuff.

          • anthony

            Then don’t believe anything I’ve written and test it yourself. Problem solved.

  9. Mithun John Jacob Reply

    An eyeopener article.

  10. Asgeir Hoem Reply

    I find it curious that you claim that your proposed solution is quicker to scan than inline labels, which are only “Fairly quick”, when the size of the individual labels are halved (see the Facebook-example). What supports that claim?

    I understand the issue with disappearing labels once the field contains input, but in a 4-5 field signup form this is hardly an issue.

    Also, the analogy to paper forms is in my opinion a drawback rather than a benefit. Has anybody ever had a great experience filling in a paper form?

    This is an interesting idea, but I would have liked to see some numbers. I really doubt that this approach will have any positive impact on most smaller forms.

    • Chris Reply

      From an accessibility perspective, people with cognitive deficits have trouble remembering 1 or 2 fields with disappearing labels, let alone 4, 5 or 10, so this solution is far superior.

    • Richard Reply

      I agree with your thoughts on reduction of the label size in the Facebook signup example. This is opinion, but it felt harder to scan. I too feel like this is something that is not quite being addressed properly. Not only that, the micro copy label just doesn’t have the same approachability or friendly appearance as the large, inline type labels. Which I think bolsters your arguments against paper forms.

      Overall, very intrigued by the strategy, and I do feel its much cleaner overall when it comes to simple, single-column forms. To be honest though, I really found it harder to scan the more complex, multi-column form examples being shown. I think you can safely adopt a lot of the principles here but you still need a bit of brainpower to find just the right balance of visual spacing and sizing for each form you’re dealing with.

      • Lawrence Reply

        What about the empty field being Infield, and the completed field being Infield-Top-Aligned?

  11. Erwin Reply

    Interesting. Keen to code and test a form like this.

  12. Asbjørn Reply

    Nice idea, and I like the concept of inline top-aligned labels as you suggest here.

    However, while you do point out the resemblance of old-fashioned paper forms and hold that as an argument for older people to recognize “the form”, you don’t mention the fact that small text size renders poor and potentially unreadable on displays with low resolution, which may hold as an opposing argument.

    In other words, inline top-aligned labels may be a good thing, but in my opinion they require very high display resolution (I’d say 250 ppi and above, in order to mimic paper) for the form to “look good”, i.e. not have immensely large input boxes (as a result of larger type). And while most top-of-the-line mobile phones and some tablets have this, very few laptops and desktops do.

    As you say; different situations call for different methods.

  13. John Reply

    An AMAZING solution. So obvious now. Thank you anthony 🙂

  14. Pablo Carrau Reply

    I’ve seen it done in a couple of mobile apps which looked great and makes total sense. Was curious if anyone has seen any CSS examples of it anywhere for web?

      • Mike Reply

        Since this example doesn’t wrap each label/input pair in a box, it essentially boils down to a top aligned approach, doesn’t it? Without the bounding box, you have to insert that row of white space to ensure proper visual pairing of label to input, which brings you back to the original problem.

        Also, interestingly, I haven’t seen anyone comment on the format of this ‘reply’ form that I’m typing into right now (input to the left of the label, horizontally aligned), which is yet an entirely different option. I don’t think it’s effective at all, which makes one wonder why it’s the method used on a UX site.

  15. Mario Fink Reply

    Interesting idea. I see some potential but also some pitfalls.

    Anyway, I created a small example of how this could be done with HTML/CSS:,css,output

  16. César Reply

    I like the general idea of mimicking the look of the old paper forms, but I’m not sure if it fits correctly in a screen. I mean, are you sure the user will recognize the cells as input fields? When the input field has the focus it’s more or less obvious, but when it’s not selected, it could be confusing. I just see empty space, not a place to write.

    Look at your treehouse signup mock. It makes me think that there’s nothing to click there. Looks kinda “disabled” to me.

    Anyway, it could be of great use in some cases. Thank you for sharing your ideas!!

  17. Scot Copeland Reply

    What consideration was given to font size regarding usability? My first thought about this is that yes, you’ve tightened up the distance between each field, but at a cost of making the text labels approximately 50% smaller in your Facebook example. Have you really made scanning the form easier?

    Yes, there may be something to connecting the label to the field by containing one within the other, but if there’s one thing I’ve learned from screen-based design, it’s that font size is important, especially to older visually impaired users, and there are still plenty of websites that make fonts too small for them.

    • anthony Reply

      Of course, label readability is just as important as scannability. The labels are a smaller size in the example, but they’re still readable. If you wanted to increase the font size further, you would just increase the field height to allow for more room.

  18. Alex Reply

    Even better. Use the “floating label” method that was introduced in Google Polymer Web Components:

    Best of both worlds!

    • anthony Reply

      Although Google’s example is similar, there are many usability issues with their approach.

      – The label becomes unreadable when it shrinks to such a tiny font size.
      – The animated movement is unexpected and unnecessary. The sudden change can cause confusion, the playfulness can cause distraction.
      – The field is denoted by a single line, which can be mistaken for dividers. A field is easiest to recognize with a box affordance.

    • Joshua Pinter Reply

      Moving labels and text, in general, is difficult to follow and mentally parse in forms. It looks good but loses it’s appeal under real-world scenarios.

      • Gary Coker Reply

        I disagree. Animation is becoming a crucial affordance in Mobile First design, and forms can benefit as well. Thanks to native apps, users are not only accustomed to animation but fully expect it and appreciate it, especially when it’s functional. I asser that the floating label technique in Polymer is highly functional and very easy to grok.

  19. Gopal Juneja Reply

    infield top aligned labels – Quite interesting, While reading about top aligned and infield. I was keen to read the solution, first I thought you will write about material design where label moves up while typing. But that is also not easy to check the input data.

    It’s a good solution for complex forms. Thanks for sharing this idea.

  20. Melissa Judson Reply

    With this approach, how would you handle labeling for compound forms such as price minimum and maximum. Infield top AND bottom aligned labels seems too clunky.

  21. Marcus Reply

    Excited to see this article because I mocked up something very similar a few months back inspired by floating labels – and not wanting the label to move. Here you can see my solution to error messages.

  22. Matt Green Reply

    I noticed your examples of non-text form elements show them centered in their fields. Why aren’t they left aligned, below their labels?

    • anthony Reply

      It’s center aligned to make use of the available space for better visibility. You can left align them too, but sometimes that leaves a lot of unused space to the right.

      • e Reply

        on the other hand your users are trained by the other labels to look hard left for what the field is (+ to enter text) and by centering it you confuse them with “hey what is this space for?” also causing them to scan white space which you are trying to avoid

        another thing is while you have a point about the white space in the other types of forms, they do serve a purpose of separating each field so you can easily see what it is, and while a lot of white space might make the scanning harder a few px would make it easier to see without being confronted with a bunch of fields one on top of the other (take tax forms…)

  23. Thor Sarup Reply

    I think it is a nice idea. But I recognize the first (regular) Facebook sign-up better than the suggested inline one.

    Perhaps as a digital designer I am too used that?

    I would prefer the label to be animated from a regular placeholder text to a label above once the field gains focus.

  24. Anne Gibson Reply

    Curious about your thoughts on accessibility.

    When the form field is highlighted, would it still have a border to indicate it’s the active field?

    If this is built by a HTML container that holds the label tag and the text field tag, and I need to click back into the text field, how do I know if I’ve missed?

    How well does it work on a screen reader, or in a 200% zoomed situation?

    Does this require Javascript?

    • anthony Reply

      Yes it would have a highlight border when it’s active. Clicking either the label or field tag should highlight the entire field, so you’ll know if you missed it.

  25. Joshua Pinter Reply

    Kumail (@kumailht) has been all over this for some time. He even created a nice library to generate these types of form called GridForms. Have a look:

    Would love to see this style come into Bootstrap.


    • Nikita Dedik Reply

      Thanks for the link! I’ve been looking for a ready to use implementation.

  26. LaRetta Reply

    I’ve previously used right-align left-side labels but I prefer this method you’ve presented. Thanks for the great example! 🙂

  27. pierrox Reply

    Please, show us an example how you would handle error message with this layout.

  28. Ann Reply

    A great article, thank you for sharing. This would indeed work wonders for forms that require about 4 to 8 fields. Curious also to see this in action on longer-form text input.

  29. Kristof Bernaert Reply

    Codepen example to achieve with Gravity Forms:

  30. Emma Reply

    Thanks for a great article! Great to see some new fresh ideas which can then be tested by others. If anyone has any test data to share… please share 🙂

    I think the paper form argument posts some interesting questions;

    1. Paper forms don’t give me a good feeling and is this something to strive towards? (could more be because paper forms are terrible hard to understand – not because they are hard to read or fill out)

    2. They might be more suitable for a more traditional user group, but not for future proofing our solutions. When will paper forms become extinct? 🙂

    3. In your example of the paper form the labels are in all Caps, which is bad for readability because of the letters creating the same shape (boxes) (since the brain scans words as images and not as individual letters. Could this principle also be applicable for these infield top aligned fields? That it might take the user longer time to “read” boxes?


  31. Björn A Reply

    Thanks for an inspiring article!
    Regarding coding solutions; why not use the ‘label’ as intended by W3C, as a caption, and wrap the ‘input’ with it and then style the label to the desired effect? Thereby there is no need for the ‘id’ and ‘for’ attributes, nor for an extra wrapper used in most examples? Of course this is no major problem in a login form, but in large forms it’s more important to keep the mark up structure as clean as possible, for numerous reasons.

    In some examples the input and label is wrapped in a ‘div’, which is wrapped in a ‘li’, which is wrapped in a ‘ul’, which is wrapped in a new ‘div’, which probably plays some structural role inside the form. This does not provide good readability for the developers and thereby increases the cost and time for changes.

    Why not use the intended elements; form – fieldset – label – input/select/textarea/progress/meter?

  32. Francis Kim Reply

    Excellent information about eye movement – thank you 🙂 <3

  33. Jayakrishnan G Reply

    Nice and informative post.

    How about single column forms? E.g., Google’s signup form ( Won’t it look like a tall rack?

  34. Rashmi Reply

    Good to see new ideas such as this. However, I see this could be challenging to deal with error messages or validation indicators, because of lack of space.

    I think this works better for small forms rather than big forms because users could get overwhelmed by the amount of input fields which are all seen at once – this is context specific…it might work for a retail environment where they routinely have to fill lots of info all the time.

    I’m not sure if users will save any significant amount of time if they’re checking a small filled form, but they might be able to save time on longer forms (like in a retail environment)

    Anything that can be debated is worth trying it out and testing. Thanks for posting 🙂

  35. Monique Reply

    Nice Sharing. I am agree on it’s quickest to scan.
    However, I have couple questions for you.

    Your design seems like have to have “border”, (in your Facebook sample) I like original Facebook idea more, because it doesn’t match the target audience. Border and square frame, it gives out a formal and mature look. I don’t think that’s what Mark Zuckerberg was looking for when he was 20.

    1) How you design the form for “fresh and creative” look?
    2) Is that “Paper Form Metaphor Design” is the best idea for marketing and sales?

  36. Lourenço Reply

    Some concerns with infield forms:

    1) the infield doesn’t fully reassemble to the standard input fields that users are used to see on the web (like user César mentioned)

    2) the amount of white color concentration, specially in grid forms. I wonder if my attention shouldn’t focus field by field easily rather that a big box or column full of squares inside.

    3) User attention to the in-focus field. If not done right with design and with all fields boxes with no white space between them, it probably will be harder for the user to quickly identify the field being used (example: eyes switching between keyboard and screen).

  37. Vadim Reply


    In my opinion this solution unites visual appeal and described method above quite well.

    Thanks author for article.

    • Lee Mac Reply

      I have a few issues with Material design, but I love how they built those forms.

  38. Wifeo Reply

    Great article ! I’ve seen those “top aligned label forms” many times on android, but could never find the accurate name.

    One of our dev built this versoin :

    Hope it helps !

  39. Felipe Reply

    I really liked the facebook example, really compact and clear.

  40. Stephen Goudie Reply

    This is a great reference and I found it very useful recently when customising UX for a checkout, thank you!

  41. Char Reply

    I have to disagree with this article. The inline labels make it more difficult for me to read what inputs are required from me, as well as making the form look more cumbersome because I have to try to discern the labels from my inputs since the label is inside the input field.

    I much prefer the top aligned label outside the input field. It just looks cleaner and is easier to read the form, in my opinion. The example of the revised Facebook sign up form was non-convincing to me. The revised form with the top aligned in-line labeling looked awful, and even more cumbersome than the original FB form. It reminds me of awful government forms that you have to fill out. They’re difficult to read and they do it to save space because you know that form is going to be long and cumbersome.

    I’d rather fill out a long form with top aligned labels with individual input fields. Looks cleaner, and makes it easier to go back and check my inputs, as well as provide validation/error messages on the form if need be.

  42. Che de Bruin Reply

    Char brings up a very valid point in this whole conversation, and that is that you are mimicking paper (government) forms. The reason why these forms where initially designed this way was to save space and to fit as many data point onto a single sheet of paper. The more pages a form was, the more it would cost the individual agency to print them, so their goal was to reduce the number of pages a form would take up, thus reducing the cost to produce that form. With the web and digital media, the need to save “that” much space it no long valid, so give the user a little more breathable space when consuming a form.

    Im also curious what the impact of this would be on those LONG government type forms. Quite often web apps for government require long and lengthy online forms, which, I feel, would be extremely difficult to accomplish cleanly with your method. Also, how would the translate to mobile when creating those forms initially for desktop.

    There is another inherent issue with the design as well and it pertains to older generation of users. Many times, older paper forms would utilize labels below the line that need to be completed, which your method can now potentially cause confusion in that area. With top aligned labels and proper spacing, the extra affordance of that white space can help clear up any potential confusion.

    Finally, and I think this has been addressed in much of the conversation above, the field level validation on such an approach would be extremely poor and limiting. There is simply no space to produce a message that would be meaningful to the end user.

Leave a Reply

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