In a design system that ships filled and outlined icon variants, how should the two be used, for example to mark the selected navigation item?
answer
- one default register, one meaning
- solid reads as emphasised
- sidebar: current section stands out
- redraw details as knockouts
- drawn state is not exposed state
basics
~20 sPick one variant as the default look and give the other exactly one meaning, commonly filled for selected or on. Draw both from one silhouette, and expose the state programmatically rather than relying on the fill alone.
solid answer
~40 sA system picks one variant as the **default** (outlined keeps a dense dashboard light; filled gives stronger silhouettes) and never mixes them arbitrarily in one group, because a solid icon among hollow ones reads as **selected or emphasised**. The other variant then carries **one meaning**, most commonly *selected* or *on*: the current section in a sidebar, a pinned report, a followed metric. A good filled variant is **redrawn**, with interior details cut out as negative space, and shares the outline's **silhouette and footprint** so switching does not shift layout. The fill is a visual cue only, so the component must also expose the state programmatically (WCAG 2.2 4.1.2 Name, Role, Value, Level A), and many systems add a second cue such as a label or indicator change.
go deeper
Recall the common convention: one variant is the default, and the filled form marks a selected or on state such as the current sidebar section.
Explain why the swap works (a solid shape carries more visual weight) and why it must carry exactly one meaning, drawn from a shared silhouette with redrawn knockouts.
Show that you treat the fill as one cue among several: state exposed programmatically, a second visual cue where fills are small, and rules written so new icons ship both variants.
Weigh outlined against filled as the default register for a dense product, knowing the choice fixes what the swap can mean across every surface.
## Two variants, one set Many icon sets ship each icon in two **variants** drawn from the same skeleton: an **outlined** form (hollow shapes built from strokes) and a **filled** form (solid shapes). They are not two styles to pick between icon by icon; they are one family with two registers. The design system's job is to say which register is the default and what the other one *means*. ## Choosing the default A system usually picks one variant as the **default look** for the interface: - **Outlined by default** keeps a dense screen light. In a B2B analytics dashboard, where a table may show three action icons on each of fifty rows, hollow icons add less visual weight than solid ones. - **Filled by default** gives stronger silhouettes that stay legible at small sizes and on busy backgrounds. Either is defensible. What is not defensible is mixing them arbitrarily within one group, because the eye reads a solid icon in a row of hollow ones as **emphasised** (selected, active or primary) whether or not that was intended. ## Using the contrast between variants for state Because a filled icon carries more visual weight, the swap from outlined to filled is a natural way to show a **binary state**. Common conventions: | Where | Outlined | Filled | |---|---|---| | Navigation sidebar or tab bar | Other sections | The current section | | Pin or favourite toggle on a report | Off | On | | Follow toggle on a metric | Not following | Following | The rule that makes this work is **one meaning for the swap**. If filled means 'selected' in the sidebar, it should not mean 'has unread items' somewhere else, and a team should not use a filled icon in a toolbar simply because it looked better there. ## Drawing a good filled variant A filled variant is not the outline flooded with colour. Flooding erases every interior line, such as the hands of a clock, the bars inside a chart icon or the lines of text on a document, so the filled form must be **redrawn** with those details cut out of the solid shape as **knockouts** (negative space). Both variants should keep the **same outer silhouette and footprint**, so switching state does not shift neighbouring elements, change the icon's apparent size, or make users think a different icon appeared. ## Fill is a cue, not the whole signal A state carried only by the fill change has two limits: 1. **It is visual only.** Assistive technologies do not see a fill. WCAG 2.2 success criterion **4.1.2 Name, Role, Value** (Level A) requires that states which users can set be programmatically determinable, so the component must expose its selected or on state, not just draw it. On the web that is a state attribute on the control; on native mobile it is the platform's selected trait or state, both set by the component rather than inferred from the drawing. 2. **It can be subtle.** At small sizes, and for users with low vision, the difference between a thin outline and a solid shape may be easy to miss. Many systems therefore pair the fill change with a second cue: a bolder or differently coloured label, an indicator bar beside the current navigation item, or a changed tooltip wording. A fill change alters shape and the amount of ink, so on its own it is not a *colour-only* cue in the sense of **1.4.1 Use of Color** (Level A). If the only difference between two states were the icon's hue, grey versus blue with the same drawing, 1.4.1 would come into play. ## Writing the rule down A style guide entry for variants typically states: - which variant is the **default** for each context (interface chrome, dense tables, larger promotional surfaces), - the **one meaning** the swap to the other variant carries, - that both variants are drawn from the same skeleton with the **same footprint**, - that state is **also exposed programmatically** and, where it matters, backed by a second visual cue. With that written down, a contributor adding a new sidebar section knows to deliver both variants, and a team adding a new toggle knows that filled means on, without guessing from existing screens.
- Does swapping an icon from outlined to filled satisfy WCAG 1.4.1 Use of Color on its own?1.4.1 (Level A) forbids colour as the only visual means of conveying information. A fill swap changes shape and amount of ink, so it is not a colour-only cue. If two states differed only in hue with the same drawing, that would rely on colour alone. Either way the state must also be exposed programmatically under 4.1.2.
- Why should the filled and outlined variants share one silhouette?So switching state neither moves neighbouring items nor changes apparent size, and users read it as the same icon in a new state rather than a different icon. A shared skeleton also means one shape to review and maintain, with two treatments derived from it.
saying these in an interview costs you the question
- Filled or outlined can be chosen per icon, whichever looks better.
- A filled variant is just the outline flooded with colour.
- A fill swap is enough; the state needs no programmatic exposure.
- Filled can mean selected in one place and unread in another.
- Filled icons are always more accessible, so outlined sets are a mistake.