When validating form fields (such as a number field) - what is considered best practice when it comes to validations that potentially encapsulate another validation?

Example: An Age field on a form. The form requires that the age is entered and that the value is between 18 and 30.

Our team is torn between two modes of thought when the fields are empty since it is thought that one of the requirements implicit implies the other.

Camp A Errors:

  • Age is required
  • Age must be between 18 and 30

The thought here is that it is best to be as descriptive as possible to the audience that we have, as our audience is typically not consisting of the most technically-savvy users, therefore be specific/explicit in telling them that a value IS required and that it must fall within the range.

Camp B Errors:

  • Age must be between 18 and 30

The thought here is that the rule basically implies that the value is required since you're stating that the value MUST be between two numbers. The other thought is that it is friendlier/less scary to the user to see fewer errors.

I know the general idea in validation design is to be descriptive as to the situation, however, there's also a principle of keeping the design simple and as straight forward as possible. I have tried searching for other sentiments/input as to this question, but I'm apparently not using the right keywords.

  • Why do you need to screen people based on their age? Advertising the valid range in an error message will lead to users lying on their age to get in. If it's a problem (due for example to legal requirements), then I would only display "Age is required" and redirect users whose age is outside of the valid range to a another page. Commented Feb 21, 2019 at 13:13
  • @celinelenoble We're not screening people based on their age. The example given above was meant to just be a non-specific example - not even in our industry. The exact same idea exists in this sample though - required vs. range. I just felt it was easier to give a good parallel that may be easily understood vs. a concept specific to our industry that is not. Commented Feb 21, 2019 at 15:40

2 Answers 2


I would recommend to produce an error message most of the time the same way:

  1. What is wrong
  2. How to solve the problem properly

If the validation like it is in your example would be for 2 error messages you should still stick to this issue and try to summarize them.

Because telling the User that the age is a mandatory field could end up in a second error message, which would be really annoying for the user. So for your example I would write an error message like this:

Required Field: Please enter an age between 18 and 30.

Also possible:

Your age is required. Please enter an age between 18 and 30.

Also the micro-interactions validations are very usefull but I think, they are not possible in every context.


Using Camp B reasoning means that you implie that your users will understand directly that they need to enter the "age". This can lead to misunderstanding with your user base, since some of them could not understand it (I mean, yeah the age has to be between 18 and 30, but if I did nothing, what does it mean? Does it mean that the system says that this is mandatory?).

I would say that the Camp A logic is the best one to use : You're sure that your users will understand what to do (Fill it within the range).

BONUS : You could use a kind of "inline validation" to provide feedback to your users about what they already did or not. They entered a number? The "Age is required" has a "ok" symbol to show that it fits They entered a number AND this number is between 18 and 30? Both of the recommandation has a "ok" symbol to show that the box is fully completed as it needs to be.

I saw people using it on websites that asks for a password that needs 8 characters, a symbol, a upper-case, a lower-case etc..., showing "ok" each time a condition was fullfilled. This way, you use the most of "micro-interactions" validations to show your users what they still need to do and what they already did.

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.