Why do some design-system icon sets redraw each icon per size instead of scaling one master drawing to every size?

## What scaling does to an icon An icon is usually drawn as a **vector**: shapes and strokes described mathematically, so it can be rendered at any size without jagged edges. That flexibility hides a problem. When a vector drawing is scaled, **everything scales proportionally**: outlines, gaps, interior details and the stroke itself. Take a master drawn on a 24-unit canvas with a 2-unit stroke: | Rendered size | Scale factor | Resulting stroke | Typical effect | |---|---|---|---| | 16 units | 0.67 | about 1.33 units | Lines look faint; fine details merge | | 24 units | 1.0 | 2 units | As designed | | 48 units | 2.0 | 4 units | Lines look heavy; the drawing looks simplistic | At the small end the problems compound. There are simply fewer pixels, so a detail that was a clear gap at 24 units becomes a smudge at 16, and a thin stroke landing between device pixels renders soft. How the drawing snaps to the pixel grid is its own discipline, but the root cause here is that the master was drawn for a different size. ## What an optical size variant is An **optical size variant** is a separate drawing of the same icon, made for one size in the set. It keeps the **same metaphor and silhouette** so users recognise it as the same icon, but adjusts the drawing to what that size can carry: - **Small variants** drop or merge interior detail, widen gaps between shapes, and keep strokes at an absolute width that stays legible rather than shrinking proportionally. - **Large variants** may add detail that a small canvas could not hold, or keep strokes relatively lighter so the icon does not look clumsy. Typography has the same idea: some typefaces are cut in separate **optical sizes** for captions and for display, because letters drawn for one size do not simply scale to another. In a smart-home control app, the 16-unit status icons for signal strength and battery level in a device row are exactly the ones that fail when scaled from a 24-unit master: the bars and segments crowd together. A redrawn 16-unit variant with fewer, wider segments reads at a glance. ## The cost, and how systems manage it Redrawing multiplies work: a set of 300 icons in five sizes is 1,500 drawings to create, review and keep consistent. Systems manage this in a few ways: 1. **Redraw only where scaling fails worst**, usually the smallest one or two sizes, and scale the master for the rest. 2. **Limit the size set**, since every extra size is potentially another variant for every icon. 3. **Prioritise by use**, redrawing small variants first for the icons that actually appear at small sizes, such as status indicators. ## How consumers get the right drawing Variants only help if the right one is used. The usual contract is that consuming code **asks the icon component for a size from the set**, and the component chooses the drawing: - if a variant exists for that size, it uses it; - otherwise it scales the nearest available drawing, following one documented rule, so every screen resolves sizes the same way. This keeps the choice out of product teams' hands, on the web and on native mobile alike, and means adding a new variant later improves every screen without a code change. ## When scaling one master is fine Not every system needs variants. A set with simple, low-detail icons and a narrow range of sizes can scale one master acceptably, and a system whose icons only appear at one or two sizes may never feel the problem. Optical variants are an answer to a measurable symptom (faint strokes and clogged details at small sizes), not a requirement every set must meet.