What are good examples of print forms


The important first impression - the visual design

When it comes to forms, too, the first impression is crucial. The success of an individual form or an entire form-based application depends heavily on this first impression. If you hit your users with a multitude of confusing options, you won't see them again anytime soon. The form should be intuitive to use and score well in the classic usability metrics of effectiveness, efficiency and satisfaction. On the one hand, this increases the incentive to fill out the form completely, on the other hand, there will be fewer breaks and incorrect entries.

The first impression is primarily visual: are the color scheme and font consistent, is the form clear and does the design support you when filling it out? Many practical examples show that even complex forms do not have to look like a tax return - let yourself be inspired. The more important the form is for the website, the more time should be invested in optimizing it. An expert can also be called in for this.

The general design laws such as conciseness, proximity, similarity, continuity, cohesion also apply to the design of forms. Elements that belong together in terms of content should be grouped together. Logically separated units should also be separated optically.

Stable axles

Axes are used to design forms visually. Axes are created by aligning the labels and input fields with one another. Users can use these visual axes to determine information about the individual form components:

  • What exactly is required?
  • Is this a required field?
  • Are options mutually exclusive or does one field complement the entries in another field?
  • Where are the error messages?

Axes are created by spaces between or before and after each part of the form. These empty spaces or whitespaces can and should be generously dimensioned. The axes are designed uniformly so that there is no uneasy impression. Labels and input fields should be aligned uniformly and have a comparable length.

In the following screenshot you can see a form with five different widths of the input fields. Since users in our culture move through a form line by line from top left to bottom right, the different line lengths create an extremely restless impression.

What to do with the labels

The labeling of input fields should always be carried out, because the labeling and input field are clearly linked. The positioning of the labeling of the control and input elements has a major impact on the usability of your offer. Whether labels should be arranged line by line next to the form elements or in multiple lines above the form elements is the subject of long debates. According to the findings from user tests, the variant of the side lettering has proven itself for longer forms, while the multi-line variant seems to be more suitable for short, less complex forms.

The best way to arrange the elements depends on the purpose of the form. There are few general recommendations.

The Human Interface Guidelines for the Windows, Mac OS and Linux operating systems provide important reference points.

The operating systems themselves are structured according to these guidelines and users are used to the fact that applications on the web are also based on these guidelines. Despite all the differences between the individual guidelines, they all agree on the following points:

  • Labels of text fields and selection fields are always to the left of or above the field,
  • Labeling of radio buttons and checkboxes is always to the right of the control elements.

If you stick to these conventions, you will help users fill out the form because the placement is based on viewing habits, making it predictable.

Variant 1: Labeling on the side, left-justified

  • The texts of the labels are easy to grasp here because they are left-justified. However, the design appears restless because of the additional optical axis. This variant is best suited for forms with unusual entries, because the users have to deal more with the labels.
  • For this form layout you have to use a very stable float environment such as YAML, YUI CSS Grids or a specialized form framework such as Formee. Developers often still rely on layout tables in this area because many browsers do not adequately support the necessary CSS properties
  • One advantage is that this variant requires less vertical space. It is in line with the trend that monitors are getting wider (16: 9 instead of 4: 3).
  • One disadvantage is the poor internationalizability. With longer labels or enlarged text, unwanted breaks quickly occur, which means that all elements are shifted.

With short labels, there are large gaps between the labels and input fields. Especially for the visually impaired, it becomes difficult to correctly assign elements that belong together, as can be seen in the following image:

In the next picture you can see a design example with striped label / control pairs, which restore this association, but is still very tiring for the eye of the user due to the enormous horizontal distances:

Variant 2: Labels on the side, aligned right

  • This variant links the label and the associated field by being close to each other. This allows the user to orientate himself quickly in the form. This may be one of the reasons why right justification is recommended in standards such as ISO 9241-17.
  • This variant requires less vertical, but more horizontal space - this becomes problematic with multi-column forms, for example, next to.
  • As described in example 1, this variant is difficult to implement in CSS.
  • Due to the orientation on the central axis, there is no uniform line beginning. As a result, optics and breaks are hardly controllable. The labels are therefore more difficult for users to skim because they "flutter" on the left.
  • However, the quick skimming for orientation is a subordinate problem with forms (in contrast to continuous texts): we want the users to deal with the field labels and process the entries sequentially in the order in which they appear.
  • This variant is problematic in terms of accessibility for severely visually impaired users with a usable visual remnant who can orientate themselves visually using magnifying glass programs. With the sometimes enormous enlargement factors, it can happen that the user only perceives a large white area under the legend (here: "Heading") and cannot find the first form field.

Variant 3: Labeling above, left-justified

  • This variant clearly links the labeling and the input field. In our experience, it is particularly suitable for very simple queries if the data collected is familiar to the user. These are, for example, simple forms with the usual combination of first name, last name, e-mail, zip code, city, etc. or username / password.
  • Sufficient distances and contrasts are particularly important here to enable the labels to be scanned efficiently.
  • This variant is the most flexible solution for internationalization and varying arrangements, as it leaves a lot of horizontal space for the labels and therefore longer texts are possible. However, it requires more vertical space.
  • In many studies (e.g. by Matteo Penzo, who examines the efficiency of the arrangement, or cxpartner's "Web forms design guidelines: an eyetracking study", where user satisfaction was examined), this version comes off best when it comes to the minimum It takes time to fill out. As in the article "Why Users Fill Out Forms Faster with Top Aligned Labels" is conclusively argued, the advantage here lies in the significantly lower number of points that the human eye has to jump to, since the visual orientation along the natural reading flow from top to bottom runs along a single axis.
  • The only disadvantage: the form requires more space in height and does not use the width that is usually available on desktop monitors.

No variant: Labels in the input field

You definitely shouldn't use the labels in write the input field. There are a number of scripts that hide labels and write the text of the labels as placeholder text in the or fields.

What happens when the user approaches and focuses on such a field? Either the text disappears and with it the only indication of what this field is about. Or the text remains and the user has to overwrite it. It will happen that many users send the placeholder text, as studies show. In order for this placeholder text to be distinguishable from real input, the designer has to make it so bright that the visually impaired can no longer see it.

Predictable placements

It is a bad habit to present form fields next to one another for reasons of space, even if they are not related to one another in terms of content. There are justified exceptions for natural combinations such as zip code / city, street / house number or first name / surname; however, you should allow all other data to have a separate line. When looking at a form for the first time, users learn its structure and orientate themselves on what they have learned. If you then suddenly deviate from this axis in the middle of the form and present additional fields on the far right, they are easily overlooked by the user. If these are also mandatory fields, this also leads to an error message and frustration for the users.

Especially for users of screen magnifiers, such form fields, depending on the magnification factor, placed far outside the visible area are hardly to be found, since no one will scroll to the right "on suspicion" to see whether there is anything else.

The horizontal arrangement of entries also harbors further dangers: the sequence of »label / input field, label / input field, label / input field ...« makes it practically impossible to correctly assign the label and the associated input field, as the following screenshot shows.

The supposed gain in space is bought here by less clarity. Users are forced to use "Trial and Error" find out which option belongs to which label text. Here, too, the better solution would have been to present the options line by line.

Conventions for labeling texts

Most modern web browsers now offer the function of saving recurring entries such as first and last name or address or accessing the user's local address book. The user can then automatically fill in the relevant fields at the push of a button, saving himself repeated entries - certainly a great help for users with motor disabilities.

For this to work, the labels in the forms must adhere to certain conventions. You should therefore text the labels like the corresponding entries in address books such as Outlook and the like. The division into first name, surname, company, street, house number, zip code (or zip code), town (or city) and country has proven itself in addresses. If you use "email" or "Elektropost" as the caption text instead of "E-Mail", it might be funny, but no browser will be able to fill this field correctly.

There is even a DIN standard (DIN 5008) for the spelling and the order in which address details are given - so the postcode always comes before the location. Applications from the English or American region that have been Germanized in particular place the zip code after the location and thus violate the expectations of the users.

There is also no clear answer to whether texts in forms and especially in labels should be set in bold: There are serious indications that users prefer bold text because it is easier to scan; However, there are also indications that bold text is more difficult to read:

“In their test, Penzo concluded that bold labels should be avoided if possible, as they are more difficult to read. However, our findings show a contradictory result. It conforms to Luke's recommendations where bold fonts can emphasize the labels from the foreground of the layout. Our participants found forms with bold labels easier to fill in. "

As is so often the case, the decision about this depends on the specific individual case, in which other aspects such as the selection of the character set, the color scheme or the spacing must also be taken into account.

Conventions for mandatory fields

The question of whether optional or mandatory fields should be marked can be answered with a simple rule: the fields with the lower number are marked. If you have mostly required fields, you should mark the few optional fields. The reverse is also true: in the case of a large number of fields or complex forms in which only a few mandatory fields are required, it is preferable to mark the mandatory fields. This prevents visual noise, does not overload your form with a lot of individual information and makes the content easier for the user to grasp.

None of the variants make sense, though all Fields are mandatory. You should mention this fact at the beginning of the form; in no case at the end of the form or even after the "send" button. There is no reverse case here - at least we have not yet come across a form in which all fields are optional.

It is of course tempting for providers to simply make all fields mandatory in order to get as much data as possible. On the other hand, there are the demands of users and data protection to disclose as little data as possible in order to achieve a goal, be it a registration, a purchase or an expression of opinion via comment. Therefore, one could demand that all optional fields be completely omitted.

However, as is so often the case, the reality lies between these two extremes: from the perspective of a provider, it can make sense to find out certain data about the user (e.g. how he got to the website), but certainly not all users are willing to provide such information close. Defining it as a mandatory field would certainly provoke unnecessary terminations. In order not to unnecessarily lose customers here, such non-essential fields should be optional.

A very specific problem affects deaf users: they usually do not know what to do with a phone call, but prefer written communication via e-mail or SMS. Therefore, telephone numbers should not be stored as mandatory fields, or at least provided with an additional checkbox where the user can indicate that he prefers to contact us via SMS.

The explanation that it contains mandatory fields that must be filled out includes an explanation of how they are marked. The asterisks (*) that are often used for this have the problem that they are treated as punctuation marks by screen readers and not read out, depending on the user's settings. In order to be on the safe side, we use graphics with an asterisk for »Easy for Everyone«, in which the alternative text is stored. You can also add a title attribute to the asterisk - you don't have to worry about unnecessary Doppler here, screen readers just read eitheror before (test file):

What is not possible?

A mistake that is often made is to mark mandatory fields only optically, e.g. using colored markings using CSS (background colors, borders, etc.). In HTML code like the following there is nothing for alternative output forms, but really nothing at all in terms of usable information:

Here the user of a voice output has no choice but to give it a try on luck.

What to do with the label?

The marking of the mandatory fields should in any case be linked to the labels or be within the label element. In the age of CSS, whether you optically place the identification on the left or right of the control and input elements no longer matters: with the necessary skill, you can pull the identification out of a label on the left and place it on the right next to the fields. It is only important that the labels are consistently always on a common recognizable axis and in a predictable position and can therefore be recorded more quickly.

Conventions for buttons

There are also conventions for buttons that your form design should be based on.The most important one: the primary action, in most cases "save" or "send", is always in the most prominent position - it is directly responsible for completing the process and the presentation should correspond to its importance. Secondary actions like »Cancel«, »Delete« and »Back« are rarely useful because they usually run counter to the goals of the form. If you use them anyway, the visual weighting should correspond to their (potentially destructive) function, as is generally the case in applications beyond the browser:

Even if the goal of a good form design should be to guide the user through the process as quickly as possible - the user should be slowed down here. He should deal with the labeling of the buttons before he randomly presses something that looks more or less like a button. As Luke Wroblewski proves in the article "Primary & Secondary Actions in Web Forms" based on user tests, a similar form of presentation of "save" () and "delete" () leads to unacceptably high error rates and, as a result, to frustration among users who carry out this confusion will lose all entries. One possibility to prevent this is to design the potentially destructive actions differently and, for example, to present them in the form of links instead of buttons and not to place them side by side, as in the following screenshot of a webmail application:

A good summary of the discussion about the correct placement and appearance of primary and secondary actions can be found in the articles "The use of buttons in web forms" by Gabriel Svennerberg and "Buttons on Forms - where to put them, and what to call them." «By Caroline Jarrett. As with the vast majority of experts, it is recommended that the primary action be placed on the left-hand side, while the secondary actions should be right-justified.

Play catch?

Just as important as the naming and placement, especially from the point of view of accessibility, is the size of interface elements such as buttons, but also icons and thus the click area that a user can hit. One of the fundamental laws of interaction design is Fitts's Law, named after its discoverer:

t = a + b log2 (D / B + 1)

- where t is the time it takes to hit the target, D is the distance from the starting point of the cursor, and B is the width of the target. Or to put it more casually: the bigger a barn door is and the closer you stand in front of it, the faster you can hit the barn door with a shotgun. You can find an excellent introduction to these laws in the article "Visualizing Fitts's Law" by Kevin Hale.

This law is becoming more relevant, especially with the currently rapidly increasing mobile use with touchscreens: an interface element that is not at least 40-50px in size cannot be reliably hit by the human index finger - especially if there are other equally small elements in the immediate vicinity.

Results count

When designing your forms, you should also pay appropriate attention to the final confirmation or results pages. Especially with sales-oriented pages, there is potential here to complete the process for the customer with a pleasant experience. This also includes the creation of a version of the page that has been optimized for printing with a summary of the transmitted data.