Simple question, is an required field indicator (ex. *) necessary when presenting a set of a radio buttons in a form?

Caveat, one radio button will be already pre-selected.

enter image description here

Technically the field question is indeed required, but does the fact that one selection is always selected negate the need to visually indicate that it is required?

  • I can’t recall even the last time I saw an * to denote a mandatory field ..
    – David
    Aug 19, 2019 at 21:52
  • 48
    @David How many digital forms do you fill out? I suspect the answer is not many... Aug 20, 2019 at 8:16
  • 53
    @David Are you suggesting that users should not know which fields are mandatory until they press submit? That is totally bad user experience. If you don't like asterisks and want to use something else, that's fine, but the user has to be aware what's the minimum amount of information they need to provide.
    – TomTsagk
    Aug 20, 2019 at 8:54
  • 9
    @TomTsagk I think the current best practice is to indicate optional rather than marking each field required with an asterisk. This should be coupled with asking the the least amount of information required for user to achieve their goal. Aug 20, 2019 at 10:20
  • 3
    @David I think what underscore_d is getting at is that these are still absolutely everywhere, so, regardless of your opinions on design, if you're not seeing them, you must not be filling out many digital forms. Aug 21, 2019 at 15:20

4 Answers 4


The problem at hand does not seem to be a question of correct asterisk marking rules, or a literal interpretation of metaphor behind the radio button control.

Rather, the conflict from your description appears to be this: While the two radio button selection instances are marked as required, the requirement is already fulfilled by pre-populated selection. However the true requirement seems to me that your user should make a meaningful choice, not just any.

So let's first ensure that that actually happens, and then think about appropriate UI presentation.

Pre-populated but required selections can be problematic because a momentarily inattentive user may consent to 'canned' choices that aren't what they would actually choose. The design problem is less a case of "You must make any old choice in order to proceed", and conformity with hard conventions for required selections, but more of "Make sure the radio button selection we pre-populated for your convenience is actually what you wish".

Yes, the asterisk to indicate required is technically redundant, as others have written. But if it is critical that your users provide accurate information on this page (and that's what required implies), present all choices in an indeterminate start state, including radio buttons. Do not pre-populate anything.

That would ensure that as your first-time user encounters the set of forms each and every one must be filled, checked, and selected ("signed, sealed, delivered...") before the calls to action 'Cancel' and 'Save' become available to them.

It is perfectly okay to my mind to present a set of radio button type controls in an initial none-selected state, even though the physical metaphor of radio button controls implies a type of 'whack-a-mole' behaviour ('one pops in, all other ones pop out' kind of thing). But remember that this is just a metaphor. If you're working within a development kit of sorts, or even a prototype application like Axure RP, UI controls like that usually come as a library 'widget' with black-box behaviour at first. That is an unfortunate constraint, but more often than not it can be overridden. If you have some progressive disclosure going on - i.e. a set of choices presented further down-page depend on an earlier radio button setting, you could even add a 'clear' function to return the radio button set to a nil state.

Looking at your UI example, it occurs to me that all forms are mandatory.

The effect of marking them as such repeatedly (*) gets washed out because the constraint seems universal to all of them - unless your actual form is longer and you're just presenting an excerpt for simplicity, or the form consists of several further pages on which compulsory selections are interspersed with optional ones.

I would therefore guard-rail the user by two things:

  1. A collective headline sub-caption "All selections are required". If all selections are truly required, say so in no uncertain terms.

  2. Disable 'Save', until all selections have been made, up to the very last one. Keep 'Cancel' active; this is how your user can safely exit the form.

By the above an explicit verbal instruction tells your user why the calls to action are blocked. If in addition, present all possible selections initially in an indeterminate state and thus force your user - appropriately - to provide the necessary information with intent and purpose, rather than have them inadvertently accept canned selections in auto-pilot mode.

Note I said initially. The above describes the carte-blanche state in which a first time user should find the form. If there is a function by which the user can instruct the application to remember my settings, all selections become sticky and can be edited (as needed, or simply left as they are) on subsequent visits.

I hope that helps. Best of success!

  • 5
    "However the true requirement seems to me that your user should make a meaningful choice, not just any." Yes, you found what I was trying to allude to in the OP. Aug 19, 2019 at 20:25
  • 15
    @ArnoldPalmer, then don't pre-select an option
    – mowwwalker
    Aug 19, 2019 at 23:56
  • 1
    Yes - if there's a clear, valuable default then pre-set that one, and leave the other option for exceptions. If there's no good reason to prefer an option, have it start out unset.
    – Riking
    Aug 20, 2019 at 5:07
  • If your toolkit doesn't allow you to leave a group of radio buttons with no selection, you might be able to add a radio button that is preselected but invisible, so the user can't select it on their own. If that radio button is selected (which can only be done by the program, without interaction from the user), any progress should be blocked.
    – Clearer
    Aug 20, 2019 at 6:35
  • It seems obvious that all controls are required. Instead of disabling Save, make invalid forms scroll to the first invalid control and show feedback. See Google's sign-up process Aug 20, 2019 at 6:46

You should only mark the field as required if the user must inform something in that field. In your example, since the user is not required to change the value of the fields, you don't need to mark them.


There is a potential problem with interpreting the requirements from the user's point of view when you make a pre-selection or default choice in a mandatory field. If none of the choices are suitable to the user and the field is mandatory then you have not allowed the user to indicate that this is the case.

Normal practice would be to make mandatory only those fields that are absolutely required, and with radio buttons to ensure that all potential possibilities are covered (e.g. by using 'others') if the field is mandatory.

Pre-filling information works best when you have some information from the users to provide a strong indication of a preference, otherwise it is possible for people to skip fields that have data entered already when you actually want a confirmation from users that they have read and filled in the details.


From what I have been reading, it is easier on the user to only mark the optional fields. From what you have shown all are required, so why add the noise of the *? By switching to that model, the question becomes solved.

If you need to keep it, you might place it at the end of the label and change the color to a grey.

  • 2
    There is an article from nngroup about this: nngroup.com/articles/required-fields . I used to think marking optional fields was better, but in this article they have some good points on why you should always mark them. The most important, I think, is the one about the user having to scroll down to know which fields are mandatory.
    – Aline
    Aug 19, 2019 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.