In a design system's form pattern, should forms mark the required fields or the optional ones, and what decides the choice?
answer
- mark the exception, not the rule
- one convention everywhere
- a word, not only a colour
- explain any symbol once
- question every optional field
basics
~20 sMark whichever kind is the exception so the marker carries information, and use one convention across the whole system. Many systems write '(optional)' in the label when most fields are required, and no marker relies on colour alone.
solid answer
~50 sThe goal is that nobody has to guess and the marker means something. If nearly every field is required, marking all of them is noise, so the few optional ones get the word '(optional)' in their label; if a form is mostly optional, marking the required ones says more. A design system then picks **one default convention** and applies it on every form, because users learn a marker once and trust it everywhere; a form where the default produces noise is usually a form asking for too much. Whatever the marker, it is text or a symbol explained at the top of the form, never colour alone — WCAG 2.2 success criterion 1.4.1 Use of Color (Level A). The visible marker serves sighted users; the field's required state must also be exposed programmatically so assistive technology announces it.
go deeper
Recall the two conventions, the reason to mark the exception, and that colour alone never marks a field. Know that any symbol needs a one-line explanation.
Explain why the marker belongs in the label, why the required state must also be exposed programmatically, and why the system chooses one convention for every form.
Show how you would build the convention into the field component and treat a form full of optional fields as a content problem rather than a marking problem.
Weigh a single system-wide convention against domain needs, such as regulated forms that mark both, and decide who may grant an exception.
## The problem a marker solves A form has fields the user must fill and fields they may skip. If the form does not say which is which, people either fill everything — slower, and they invent answers to fields that did not matter — or skip something required and discover the rule only when submission fails. WCAG 2.2 success criterion **3.3.2 Labels or Instructions** (Level A) asks that labels or instructions are provided when content requires user input, and telling users what they must provide is part of those instructions in practice. The design question is not whether to mark, but **what** to mark. ## The two conventions | Convention | Works best when | Cost | |---|---|---| | Mark **required** fields (usually an asterisk plus a note explaining it) | Most fields are optional | Where most fields are required, a column of asterisks becomes noise and the symbol needs explaining | | Mark **optional** fields (the word '(optional)' in the label) | Most fields are required | Where many fields are optional, the word repeats and the form is probably asking for too much | | Mark **both** explicitly | Mixed forms in high-stakes domains | Every label carries a marker; clear, but visually heavier | The underlying principle is information: a marker that appears on nine fields out of ten tells the user less than one that appears on the single exception. That is why many public-sector and product systems default to marking the optional fields and keeping them rare. It is a **convention with a reason**, not a standard — both approaches can be accessible and both are in wide use. ## Rules that hold whichever convention you pick - **Not colour alone.** A red label, or a red dot with no text, fails WCAG 2.2 **1.4.1 Use of Color** (Level A), which forbids colour as the only visual means of conveying information. Colour may reinforce a word or a symbol. - **Explain any symbol.** An asterisk is familiar to many users but not to all; a short line at the top of the form ('Fields marked * are required') removes the guess. - **Put the marker inside the label.** Text next to the label, not floating at the far edge of the input, stays attached when the layout reflows and becomes part of what is read out with the field's name. - **Expose the state programmatically.** The visible marker serves sighted users; the field must also be flagged as required to assistive technology on each platform, so it is announced with the field. How each platform spells that is the platform layer's concern. - **Keep it in words users understand.** 'Optional' is plain; abbreviations and icons are not. ## Why a design system picks one convention If one product team marks required fields with an asterisk and the next marks optional fields in words, a user moving between screens of the same product must relearn the rule — and some will misread an unmarked field on the second screen as optional. The system's job is to make the choice once: 1. Choose the default convention, with its reason written on the form-pattern page. 2. Build it into the field component so teams get it by setting a single option, not by hand-typing markers. 3. Say what to do when a form fights the default: usually, remove or defer optional fields rather than switch conventions. 4. Show the explanatory note as part of the form pattern when a symbol is used. ## Example: the menu-item editor on a restaurant tablet A restaurant point-of-sale back office has a 'new menu item' form: name, price, course and kitchen station are required; a description, a photo and a calorie note are optional. The team marked required fields with a small red asterisk and no note. Staff editing menus on the tablet in a bright dining room could not see the red marks, and a new manager assumed unmarked fields were required and wrote filler descriptions. Meanwhile the staff-record form elsewhere in the same app marked optional fields in words. The fix was system-level: the field component gained a single optional/required setting rendering '(optional)' in the label, the default convention was written down, and the menu form moved its three optional fields into a final 'Extras' group. ## Common mistakes - Marking nothing and letting validation teach the rules after a failed submit. - Relying on a colour change or a coloured dot. - Using an asterisk with no explanation anywhere on the form. - Letting each team choose, so the same product uses both conventions. - Treating 'optional' as permission to add fields nobody will use.
- If a form ends up with many optional fields, what does that tell you?That the form is probably asking for more than it needs. Challenge each optional field: who uses the data, and could it be collected later or derived? Often the fix is removing fields or moving them into a clearly optional final group, after which the default marking convention works again.
- Is the visible marker enough on its own for screen-reader users?No. The visible marker is for sighted users; the field's required state must also be set programmatically so assistive technology announces it with the field's name. Placing the marker text inside the label helps because it becomes part of what is read, but the programmatic state is what reliably reaches every user.
saying these in an interview costs you the question
- An asterisk is universally understood, so no explanation on the form is needed.
- A red label colour on its own is enough to mark a field as required.
- Leave fields unmarked; users learn what is required when submission fails.
- Each product team should choose its own marking convention per form.
- Optional fields cost nothing, so it is fine to keep adding them.