Forms. Complex guide on how to create a better design. Part 1.
With a hand on my heart, I can say that I didn’t think I would ever write an article about the forms. Everything has changed in the last year of work. Regular applications in my work have been replaced by enterprise clients, where a fair amount of work is done with forms. Before that, I had only encountered them on the registration flow, password recovery, profile, settings, and pavements. Now I often have to work with interfaces that work on the input-output principle, hence the forms in most cases.
Could there be a problem with the forms? It really depends on a lot of factors. Is there anything easier than creating an input with a title and combining them into a group?
There are basic concepts of working with forms, principles, following which you can improve your work, in my case, improving the forms creation can pump the product, I hope that my experience will also be useful to you.
Where to start
Nothing new here — your users, the context of using the forms — I really think these things should be paramount and come before understanding the fields themselves and what information you’re going to collect. Understanding these things will help you understand a number of factors, like the format of the input fields, accessibility, navigation, validation, and tips, etc. Your users can be kids, they can be old people, they can use the product in labs, being special wearables, they can be inclusive, they can use screen readers, be in a car, and even “in a really good mood.” From this you can define a number of conclusions, how to arrange elements, navigation through the keyboard, or screen reader checks, whether tooltips are needed, the size of the form, what type of placeholders should be, what type of validation will be and whether it will be in general.
I’ll leave out the part with recommendations for user research, I hope you don’t have a problem with that, I can give you a couple of personal recommendations from my experience. Interviews have always proved to be better than other types of research, qualitative information gave insights about the context of use, what experience with the forms users already have and what users expect to see. So in terms of my experience, I can say that qualitative data provided more insights, I can for sure recommend this for your work as well. Do not be squeamish about secondary research. On the Internet there are a lot of materials on the study of a particular group of users, if your project does not have the budget for interviews, try to find the information yourself, they are not always aimed specifically at forms, but even this follow-up will allow you to understand the portrait of the user and build your assumptions or hypotesis better.
Laws
The topic of psychology and behaviours is one of the key factors in our work, so studying global laws and understanding them can help you. They are useful when designing. Speaking of forms, I highly recommend learning the three most relevant laws:
- Law of Common Region
- Fitts’s Law
- Zeigarnik Effect
Law of Common Region
Elements tend to be perceived into groups if they are sharing an area with a clearly defined boundary.
Create groups of elements, or separate them by structure and logic, if you decide to add a peerole in addition to the form, make sure the users understand why they need to enter data in this place. It’s not always necessary to use graphic separators or frames to describe groups; negative space or headings can help you with this as well.
Fitt’s Law
The time to acquire a target is a function of the distance to and size of the target.
Consider your audience, but know that trying to hit a cursor on an instep that is marked with a 1px line is not that easy, it looks pretty minimalistic and in some cases stylish, but it’s not always necessary. Also, do not forget about the sufficient distance between objects; it should be enough, but do not overdo it. Users should understand that they are in the same group; see rule #1.
Zeigarnik Effect
People remember uncompleted or interrupted tasks better than completed tasks.
Provide a clear indication of progress or hints in order to motivate users to complete tasks. Sometimes it is worth thinking about the breakdown of the form in a few steps. You agree to see that about 20 input fields may have a negative impact on the motivation of the user to fill them. If you decide to break the form into groups, give a clear idea of where the user is now and what awaits him next; do not let him get lost.
Form layout
After learning about users and understanding what information you need to collect, either right away or after a few other integrations, you’ll probably start laying out the form’s layout.
I don’t think there are any problems here, but let’s look at the most common mistakes that can worsen usability.
I will skip the simple cases, hope you’ll be able to manage them. Let’s dive into most interesting ones: fields can be many and can be very many. Several potential solutions that could arise are: create a multi-column layout, divide the form into logical steps, or give out a canvas length of 10–15 scrolls. Is it worth choosing the lesser of all evils?
A multi-column layout can have problems with people picking up information in a Z pattern, and it’s not clear where the beginning and end of the form are. But is it critical? I’ve met projects with this kind of form, and they were more than tolerable; how come? There was a conventionally clear path and sequence, so they have a place, but I can’t recommend them to everyone. You should definitely understand why you do that.
Dividing into steps can confuse the user; there may be a desire to save the progress and return to fill it in later, and this is already an additional burden on the development. Very often, users don’t know what to expect at the next steps, because quite often there are no prompts or descriptions of how many forms to fill out, so it’s easier to close this kind of form. Using this kind of layout to guide the users, guide them, let them know how many remaining steps or fields there are, and praise for the passage of the step, if you have the opportunity to think about the possibility of saving the progress, would not be superfluous, but it is very contextual.
Very long forms are tiring and very pressuring to the user; they literally make you spend “a lot” of time and not let go any further until you are done. Although this is the most understandable kind, it has a number of factors that users can literally hate. I can’t give you the maximum number of fields because it can be individual instances, large free text areas, or even a combination of both, but by testing such options, I have determined that no one most likely will do more than two full-screen scrolls. It all depends on the size of your fields, but please do not overload the user; think about the possible reduction or options above.
Form view and edit modes
The next step is important to understand, and the next in the hierarchy of form creation is type. Forms do not always have only input fields, but quite often it is common practise to see a “read only” state with a possible transition to the change state. I’ve often seen the approach where people separate these two types of forms, switch to another tab, or open a modal window to make changes. A popular approach is inline modification, i.e., the row goes from the read-only state to the edit state. Plan for this ahead of time, because it can be quite an effort on the development side. I won’t highlight the “best approach” here because everything is hyper-contextual and depends on the number of instances, context of use, etc. Try to talk it through with the development team; this is the stage where most difficulties happen. In all likelihood, they can give you a technical solution, but don’t forget to overlay it with the user experience and ideally test usability.
Validation
Validation is checking the values specified by the user and displaying the errors. There are three types of validations: instant, by loss of focus, and by form submission.
Instant
Starts checking values as soon as the user starts entering data. Normally, it is in a “permanent error” state until the user enters the correct data. Often used on cases with a static amount of data or numbers: mobile number, card number, country code, etc. It may look aggressive in some cases, but the user gets an instant response regarding the data entered.
Loss of focus
Loss of focus, or simply saying switching to another input. This is considered a basic and desirable type of validation. Because user receives feedback after data was entered into instance and state changes from focused to filled, after validation user sees tooltip or error message which tells him to go back and correct data if something wrong. It’s not as aggressive as the previous one, but it informs the user of the problem rather quickly. Recommendations — don’t validate empty fields and don’t return focus states to field with error.
Form submission
Validation occurs when the form is submitted; a common use case is to check if all the required fields are filled in. This is also a commonly used type of validation. But be careful here with the submit button; the user must understand why it is active or not active and whether you need this kind of validation in this case or not.
Ending of the Part 1
In the first part of the guide, I tried to describe the basic principles and approaches to forms, basic rules, how to choose a layout, and how to validate. The second part is already in development, and in it we will talk in detail about the elements of forms: headers, errors, hints, messages, types of feedback, and more personal recommendations. So subscribe so you won’t miss it.
