User friendly interface
Let's talk about the most important part: the form.
That is, text fields, checkboxes, drop-down lists and other fun. I will not say a word about their design, I will share my thoughts on the scenario of the form for receiving data (registration, for example).
To make a cool registration procedure, you need to put yourself in the place of a visitor to the passport office or some other authority working in exchange for the waste paper deposited in it.
Situation 1.
You collected 20 certificates and 30 extracts, put an angry aunt in the window, come in 2 weeks - and you are told that one of the certificates made a mistake - bring a new one.
Rule: data verification must be before sending data to the server (correctness of email, password length, required fields).
')
Why this happens: the programmer is inconvenient to do 2 checks at once (client & server-side), in two languages, but according to the same rules. It can be understood - changing the rules (today we accept passwords from 4 letters, tomorrow only from 7) can lead to destructive mis-synchronization of checks.
Situation 2.
You corrected the certificate and brought back the package of documents. Evil auntie says that you have a photograph 10mm more than the norm.
Rules:
1) Inform the user initially in what format you will accurately receive the data (resizing a userpic is your task if the user is dear to you).
2) Make all checks immediately and show him all the mistakes (today is a certificate, tomorrow is a photo, the day after tomorrow Kalash and there is no evil aunt)
3) Save the data entered early.
This includes checking for “isn’t it a robot?” - remember (in cookies, sessions, elsewhere) - that this user has already entered numbers from the image and has already entered the password 2 times in the process of this registration. Ask him to simply correct the errors and click OK.
Situation 3.
You come for a certificate from the housing department, and there an evil aunt starts asking you about your son's level of education, contact details, his wife's illnesses, and so on.
Rule: request only the data you need at this stage. Usually there is enough Login, Password, confirmation that it is not a robot. Email is needed at all forever, and besides, its confirmation must be post-registration (the user has the right to know all the delights of the site where he registered). All personal data, additional data can be politely asked to fill out after registration.
And finally: the highest stupidity immediately after registration to ask the user to enter the username and password already entered a minute ago.
That is, text fields, checkboxes, drop-down lists and other fun. I will not say a word about their design, I will share my thoughts on the scenario of the form for receiving data (registration, for example).
To make a cool registration procedure, you need to put yourself in the place of a visitor to the passport office or some other authority working in exchange for the waste paper deposited in it.
Situation 1.
You collected 20 certificates and 30 extracts, put an angry aunt in the window, come in 2 weeks - and you are told that one of the certificates made a mistake - bring a new one.
Rule: data verification must be before sending data to the server (correctness of email, password length, required fields).
')
Why this happens: the programmer is inconvenient to do 2 checks at once (client & server-side), in two languages, but according to the same rules. It can be understood - changing the rules (today we accept passwords from 4 letters, tomorrow only from 7) can lead to destructive mis-synchronization of checks.
Situation 2.
You corrected the certificate and brought back the package of documents. Evil auntie says that you have a photograph 10mm more than the norm.
Rules:
1) Inform the user initially in what format you will accurately receive the data (resizing a userpic is your task if the user is dear to you).
2) Make all checks immediately and show him all the mistakes (today is a certificate, tomorrow is a photo, the day after tomorrow Kalash and there is no evil aunt)
3) Save the data entered early.
This includes checking for “isn’t it a robot?” - remember (in cookies, sessions, elsewhere) - that this user has already entered numbers from the image and has already entered the password 2 times in the process of this registration. Ask him to simply correct the errors and click OK.
Situation 3.
You come for a certificate from the housing department, and there an evil aunt starts asking you about your son's level of education, contact details, his wife's illnesses, and so on.
Rule: request only the data you need at this stage. Usually there is enough Login, Password, confirmation that it is not a robot. Email is needed at all forever, and besides, its confirmation must be post-registration (the user has the right to know all the delights of the site where he registered). All personal data, additional data can be politely asked to fill out after registration.
And finally: the highest stupidity immediately after registration to ask the user to enter the username and password already entered a minute ago.
Source: https://habr.com/ru/post/7263/
All Articles