Large forms design guidelines and rules

Question

I am working on a web gui of inner corporate CRM system which has a lot of pages with large forms, that contain 10-60 different types of fields: mainly inputs, also selects, radios and checkboxes. And of course lots of labels, small pieces of text and buttons - now it all looks as a complete mess..

In the first place i want to formulate a list of rules, like brand-book - what can be done and what can't - in the new forms and how the existing ones must be redesigned. My target now is a clean transparent and univocal set or rules for designers and css/html-coders.

If anyone could provide me advice on how this can be done? Any approaches - columns, color-schemes, styles and so on are applicable.

Answer 1

The flexibility of the system makes the needs overwhelming. We could come up with some design rules, but it would be too general and too long.

The system you describe is generally about arranging a lot of data in different forms and relations, in a usable, editable, and visually attractive way. For inspiration, there are tons of systems online that does this, from nimble to facebook.

I would sit down with interaction or graphic designers and start drawing mockups with pen and paper. And then perhaps post a question about certain pin-pointed conundrums on your way, instead of the overall design.

Answer 2

I think you should break your form in small chunks. I mean to say different blocks or category like 1) Personal Information 2) Contact information or Product information(weight, height, material..etc..)

& more. Fill each block with a alternative background color(not more two background colors).

Keep labels at the top of all input field, text-area & other form fields.

Here is a great article about form Usability: http://uxdesign.smashingmagazine.com/2011/11/08/extensive-guide-web-form-usability/

Answer 3

This is exactly what we are currently doing in the Department of Labor with our UX Framework. Our UX team dictates style guidelines being used by over 20 application development teams working on both internal and external facing applications.

By using our frontend framework we provide developers with a default grid system (960.gs), basic color schemes/styles, basic JavaScript starting libs (jQuery for example) with the ability to lazy load additionally supported library (DataTables, Sugar, jQuery UI, etc...). As dev teams require extra functionality we add new features and styles as they request them. Dev teams are also now starting the wire framing process which they share with the UX team before they start coding.

Development teams using our framework benefit from basic accessibility, usability being baked directly into our template and components, consistent look and feel, and much more. We have also giving guidance concerning content and soon to release information regarding web design patterns principles and procedures.

Feel free to look over our materials and pull information that you find helpful.

Answer 4

To answer your question about styles, I use a style guide that helps new devs/analysts make sure they follow the standard convention. The style guide would contain guidance on:

• Font Size
• Menu Style
• Date/Time format
• Hyperlinks
• Form Standards: Label size/orientation, Required Fields, Tab order,
• Standard Table Layouts: Heading style, Cell style, Cell justification for value type, coloring of rows (watermelon stripe?),
• Common widgets to be used throughout the application
• Alt Text
• Button/Image Guides: Font to use, color, gradients, etc.
• Icons to use
• Hover style/delay
• Usage of Breadcrumbs
• Tree Style
• Use of Popups
• Error Message Styles (Error, Informational, Warning, Custom)

I use the term 'guide', because it's just that: a guide. It's not a requirement, since different situations warrant different solutions. However, any deviations should be discussed with the team, to make sure it's the right approach. Perhaps a new style needs to be added to the guide.

As for the applications ....I have a similar situation. One of the applications I work has been built for EVERYONE, and now it pleases NO ONE. Making the system pretty may not make it more functional. And I can't make any changes that adversely impact my advanced users which know where every field is that they need to use.

I'm sure that if you analyzed the data, you would see only 20% of the fields used constantly, and the other 80% of the fields used only in certain cases.