In a component spec, why are variants and states documented separately, and is error a variant or a state?
answer
- chosen at placement or entered at runtime
- size and emphasis versus hover and focus
- a grid of combinations
- impossible combinations marked
- error arrives from user input
basics
~20 sVariants are options chosen when placing a component, such as size or emphasis; states are conditions it enters at runtime, such as hover, focus, disabled or error. Keeping them separate makes every variant-by-state combination specifiable. Error is a state.
solid answer
~40 sA **variant** is a choice made when the component is placed on a screen: size, emphasis, layout, with or without an icon. A **state** is a condition the component moves into while people use it: hover, focus, pressed, selected, disabled, loading, error. They answer different questions, so a spec lists them separately and then shows a **matrix** of variants against states, marking impossible combinations and showing combinable ones like selected plus focus. Error is a state: it arrives from user input or data, can combine with focus and hover, and disappears when fixed. Listing error as a variant hides those combinations, so nobody designs error-with-focus, and it invites teams to hard-code a permanently red component.
go deeper
Recall the split: variants are chosen when placing a component, states are entered while it is used, and error is a state.
Explain why the matrix of variants against states exposes missing designs, and which states combine and which exclude each other.
Spot where a spec's variant list is really hiding states, and what that does to the code API and to consistency across platforms.
Decide how many variants the system allows per component, since each one multiplies the state matrix every platform must build and test.
## Two different questions Every shared component answers two questions: 1. **Which version did the designer or developer choose?** That is a **variant**. 2. **What is happening to it right now?** That is a **state**. A spec that mixes them into one list loses the fact that every variant must work in every applicable state. ## Variants Variants are **chosen at placement** and usually fixed for that instance: - size (standard, compact); - emphasis (filled, outlined, subtle); - layout (icon leading, icon trailing, text only); - optional parts shown or hidden (with or without a description). ## States States are **entered at runtime**, from user action, focus or data: - rest (the default look); - hover and pressed, for pointer input; - focus, for keyboard and assistive technology users; - selected or checked; - disabled and read-only; - loading; - error, and sometimes success or warning. ## Why separate them: the matrix Once they are separate, a spec can show a **matrix** with variants as rows and states as columns. In a utility company's billing portal, a selectable payment-method tile might look like this: | Variant \ State | Rest | Hover | Focus | Selected | Selected + focus | Disabled | Error | |---|---|---|---|---|---|---|---| | Standard | designed | designed | designed | designed | combined look | designed, no hover | designed | | Compact | designed | designed | designed | designed | combined look | designed, no hover | designed | The exercise surfaces the questions a mockup of the default never asks: what does an expired card (error) look like when focused? Does disabled suppress hover? Can selected and error appear together? ## Why error is a state Error has every property of a state: - it is **entered at runtime**, from input or data, not chosen when the tile is placed; - it **combines** with other states (an errored tile can still be focused or hovered); - it **goes away** when the problem is fixed. If a spec lists error as a variant, three things go wrong. The error-with-focus and error-with-hover looks are never designed, because variants are not crossed with themselves. Product teams start placing a permanently red tile as a variant to signal something else. And the component's code API tends to follow the spec, so error becomes a design-time option instead of a condition driven by data. ## Common confusions | Confusion | Consequence | |---|---| | Disabled listed as a variant | disabled plus focus behaviour undefined | | Destructive emphasis listed as a state | teams toggle it at runtime to show warnings | | Only rest state specified | every other state improvised per platform | | States assumed mutually exclusive | selected plus focus renders one or the other | ## What interviewers are checking A junior candidate is expected to know the two words and place common examples correctly. The deeper signal is recognising that the distinction exists to make the **combinations** designable, because the combinations are where inconsistent and inaccessible builds come from.
- Can two states apply at once, and how should a spec show it?Yes. Selected and focused, or error and focused, commonly apply together, so the spec shows the combined look explicitly rather than letting one state silently override the other. It also marks combinations that cannot occur, such as hover on a disabled control, so nobody designs them.
- Why does the focus state matter even if designers rarely see it?Keyboard and assistive technology users navigate by focus, so an undesigned focus look is often an invisible one. The spec should show focus on every variant and in combination with selected and error, so the indicator is visible and consistent everywhere.
Variants are the model of car you bought: hatchback or saloon. States are what the car is doing: braking, indicating, parked. You would never list braking as a model, and every model still needs brake lights.
saying these in an interview costs you the question
- Error is a variant because it changes the component's colors.
- Only the rest state needs a mockup; the others are obvious.
- Variants and states can share one list without losing anything.
- Disabled is a size-like option chosen when the component is placed.
- The focus state only matters for designers, not for users.