(I'm not 100% sure this is the place I should be posting this but I do need help on the UI part of the problem)

We have an ASP.Net MVC5 application. It has one page for profile information and that page has 52 fields on it.

I've had the form separated in tabs before but it led to validation problems when the form was submitted so I took out the tabs and made it one single long form to help with the validation routine.

The sections (for the tabs) were:

Name, Email, Username & Password (13 fields)
Phone Numbers                    (10 fields)
Addresses                        (17 fields)
Business Profile                 (12 fields)

Now, when the form is broken up into tabs, some of the fields aren't visible and the validation doesn't occur on them. This breaks our validation because there are some fields that are required on each tab and if the tab isn't showing, the fields don't get validated. We are using jQuery ValidationEngine

The form posts to a single MVC action that updates the object that the form loads from and then sends the info to our database.

What would be the best way to tackle this dilemma? Should I put a submit button on each tab and make a new action for each tab to save to the object?

If so, then when would I send the object to the DB? When would I do the validation of the tabs that weren't showing and how to notify the user that those fields also needed completion?

  • This is a great question. Settings panels can be a brutal combination of system and user requirements. If I get a chance, I'll dig up some past work and offer ideas. Commented May 5, 2015 at 19:18
  • I had decided to change validation plugins. The one I am using now does not support tabbed, accordion, or wizard interfaces. This one does: formvalidation.io
    – MB34
    Commented May 6, 2015 at 15:45
  • There are ways to build it that make your validator irrelevant. You'd need a qualified front end dev to tell you exactly how that's done. Commented May 6, 2015 at 16:00

5 Answers 5


Separate the UX from the implementation concerns

This will help simplify the problem by clarifying priorities and through decomposition.

  1. Usually, the first priority with a complex form is to design the optimal user experience. UX makes a huge difference with long forms, so that's why it helps to separate the concern and focus on creating a clear user flow first.

    • 50+ fields is a really long and exhausting form for users. UX designers will typically do their best to convince you not to attempt something like this.
    • There are many resources available for help with designing long forms this search should get you started.
    • Typically you want at minimum section the form, and good/better practice is to chunk it into a wizard/tab type navigation. There is also plenty out there on how to design good wizards.
    • A modern approach to forms is to figure out whether you can defer some fields until after the account is created. This can be very effective for reducing signup friction and abandonment.
    • Just focus on designing the experience without regard to implementation constraints. You can work out the tradeoffs later.
  2. Then figure out implementation.

    • Implementation is really beyond the scope of UX StackExchange, but approaches like loading an entire form and show/hiding wizard panels can help if you want to keep the form state client-side.
    • Obviously, there are lots of options if you are open to saving partial/interim states server-side.
    • jQuery validation also has lots of event hooks and configuration options to help with custom validation behavior.

The problem sounds complicated because you are conflating two concerns (implementation constraints<->UX goals) and this leads to confusion over where to start and what is important. A little formal separation here can really help decompose the problem to make it more solvable.

  • figure out whether you can defer some fields until after the account is created The accounts are already created, this is similar to a profile page. The users are in the insurance industry and the Business Profile section is insurance related, such as License number, etc. There are 4 telephone numbers on Phone Numbers section with a Country code, number and optional extension. There are 2 addresses with 3 lines, city, state, country and zip and a mailing preference on the Addresses section. I'm not sure if I could "defer" some fields.
    – MB34
    Commented May 6, 2015 at 14:26
  • Let me give you an idea of one of the validation issues. In the Addresses section, we have a mailing preference radio group. One of them MUST be selected and it depeneds upon whether the user has either their Business or Home address filled in. If the address isn't filled in, they cannot select it. However, if they already had a selection and the address is cleared, then the radio has to be cleared and the user MUST select the other one. One must always be selected before the data can be submitted.
    – MB34
    Commented May 6, 2015 at 14:31
  • OK that additional detail is very helpful. If the 50+ fields must be filled in for hard business reasons then good analogs are university application forms and tax forms. I highly recommend looking specifically, but the approach they use is to break up the form into separate pages/panels, provide clear section and progress indicators, and clear indicators of which sections are complete, incomplete, or complete but with errors. This is really the best practice I'm aware of because the sections help calm users but the navigability provides clarity and orientation for a long process.
    – tohster
    Commented May 6, 2015 at 16:07

To make long form simpler and faster:

  1. Get rid of every single filed that is not crucial for the process (and ask stakeholders also to validate if each field is a must-have, because usually they put all they think is a nice-to-have to the form)
  2. Separate it into steps, give progress bar with steps
  3. Use autocomplete as much as possible - there is finite number of male/female names or countries: http://baymard.com/labs/country-selector. City can be set upon zip code or also with autocomplete.
  4. Use inline validation as often as possible (not one showing errors after hitting "submit").
  5. Use mask fields. Phone numbers for instance: http://jackocnr.com/intl-tel-input.html
  6. Set proper input types and ids with common values - it will allow browser to use past entries in your form, for example for "First name" set id="first-name". For year of birth use type="number" or type="date" for birthday with commonly used id="birthday".
  7. Save each step and give an access to previous steps.
  8. Use labels wisely: http://www.smashingmagazine.com/2011/11/08/extensive-guide-web-form-usability/
  9. Use placeholders in input to give entry examples.
  • Many of these suggestions are already being implemented.
    – MB34
    Commented May 6, 2015 at 14:28

Your best bet is to use a control similar to the AJAX Accordion instead of the tabs. That way all the fields will be validated within a single page although they will not be all visible (unless all headers are expanded). In the past, I worked on a web application with a similar number of fields, we didn't find any other way to display and validate all the fields other than with the Accordion.

  • From a front end dev perspective, an accordion or tab presentation can both use the same DOM (and be validatable). From a user perspective, what's the advantage? I'd argue that mobile experiences have training people to look for tabs or button groups as much or more. Commented May 5, 2015 at 19:20
  • Using an accordion ALSO has parts of the code that are not visible at times and thus the validation functions will not fire for those fields.
    – MB34
    Commented May 5, 2015 at 20:17

What I use for this kind of scenarios is a simple multi-steps form, where I ask for some specific data, do a quick validation, if correct, enable the continue button and so on until getting to the last screen with the SUBMIT button. Using AJAX, this is a pretty simple task.

As for when to send info to database, it depends. For example, since I work with many marketing companies, I do capture all the info and send to DB anyways, then use it to track behaviors and eventually set cookie based content. So, the final SUBMIT only adds a boolean field (opt-in:yes/no). Of course you may not need this, but just to give you an idea of when to write info to DB.

Also, while it's a bit tricky, it's very useful to track AJAX-loaded screens, so I strongly recommend to do it so and compare results against non-AJAX screens. In my experience, user interaction with AJAX loaded content is very different to user interaction with no-AJAX, so it would be good to test that for your users as well

  • The fields are loaded at once using Razor code from a passed object to the ViewBag, they are not loaded via AJAX. However, I think I see your point in putting the submit only on the last form. But if I'm filling in the form and only need to change one field on the last page, why would I need to go through the entire multi-step setup?
    – MB34
    Commented May 5, 2015 at 20:18
  • The multi-step approach can work when you know what order things need to be accessed. This is not the case with settings screens. A user may come to the page to change any one of those 50 points in any order they choose. Commented May 5, 2015 at 20:19
  • Yes, as I pointed out, they may only want to modify one field on the last portion of the form.
    – MB34
    Commented May 5, 2015 at 20:20
  • then if you're changing pre-filled forms, you may enable all "continue" buttons (since they're filled and already validated) and simply use the submit button as a "confirm" action. If you need more control, if the form is already filled (entirely or in part) you can present the user with all disabled fields at first, then a "Modify" button which will make the fields enabled for modification, and finally add a message on the submit/confirm button like "this will modify your current information, are you sure?" --> CONFIRM MODIFICATIONS / CANCEL
    – Devin
    Commented May 5, 2015 at 22:42

Firstly, Always categorize form fields in groups, group similar type of fields first, because categorization reduces cognitive load of user who is filling form.

Secondly provide the wizards and break the process into smaller steps.

Third, always provide 'Save as draft' feature for such a big forms because if a user is not able to fill form in one sitting he/she can fill it later after saving it till he completes.

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.