In a design system's icon set, which drawing attributes must stay fixed across every icon so the set reads as one family, and why?

## What 'style' means for an icon set An **icon set** is a family of small pictograms drawn to one shared specification. Its **style** is everything about *how* an icon is drawn as opposed to *what* it depicts: the thickness of its lines, how those lines end and meet, how round its corners are, whether shapes are hollow or solid, and from which angle objects are seen. Two icons can depict completely different things, a calendar and a bell, and still look like siblings because they share those drawing decisions. Two icons of the same object drawn to different specifications look like strangers. A design system fixes these decisions in an **icon style guide** so that the set stays coherent as it grows past what one illustrator can hold in their head. ## The attributes a style spec fixes | Attribute | What the spec decides | What drift looks like | |---|---|---| | **Stroke weight** | One line thickness at the reference canvas size | One icon looks bold or faint next to its neighbours | | **Terminals** | How open line ends are capped: flat, square or rounded | Some arrows end blunt, others soft | | **Joins** | How lines meet at corners: mitred, bevelled or rounded | Mixed pointed and soft inner corners | | **Corner radius** | The rounding applied to the outer corners of shapes | A square-cornered folder beside a rounded document | | **Fill treatment** | Outlined, filled, or both as named variants | A solid icon in a row of hollow ones | | **Perspective** | Flat, front-on or simple side views, no vanishing points | One isometric cube among flat shapes | | **Metaphor** | One picture per concept | Two different pictures for export | Some style guides add further rules, such as the angle for diagonal lines, the minimum gap between shapes, or how much interior detail an icon may carry, but the attributes above are the core. ## Why consistency matters in a dense interface Take a **B2B analytics dashboard**. One screen can show a sidebar with a dozen section icons, a toolbar above a chart (filter, date range, compare, export, share), and a table where every row ends in three action icons. Users do not read icons one at a time; they **scan a row** of them. In that setting: - An icon with a heavier stroke **reads as emphasised**, as if it were the primary or active action, even when it is not. - A mix of sharp and rounded corners makes the product look **assembled from several sources**, which erodes trust in a tool people rely on for numbers. - A perspective drawing among flat ones adds **depth detail** that turns to visual noise at small sizes and pulls the eye. - Inconsistent terminals and joins are barely visible on one icon but **accumulate** across a row into a vague sense that something is off. Consistency is therefore functional, not decorative: it keeps visual weight, and with it attention, where the interface intends it. ## Why flat, front-on drawing is the usual default Most interface icon sets draw objects **flat and front-on** (or in a simple side view), without vanishing points or three-dimensional shading. The reasons are practical: 1. At common interface sizes there are very few pixels to work with, and perspective spends them on depth cues instead of the silhouette that makes an icon recognisable. 2. Flat shapes share one visual plane, so they align cleanly on a shared canvas and sit comfortably beside text. 3. A flat, single-colour drawing recolours cleanly when a theme changes the icon colour; shading baked into a perspective drawing usually does not. Perspective is not wrong everywhere. Larger illustrative drawings on empty states or onboarding screens sometimes use it, but a system keeps those as a separate illustration family rather than mixing them into the interface icon set. ## Harmonising icons with the rest of the language Icons rarely stand alone; they sit next to labels. A common practice is to choose the icon stroke so it **optically matches the weight of the text** it usually accompanies, because a regular-weight label beside a heavy icon looks unbalanced. Likewise, many systems let the icon corner radius echo the interface's general shape language, softer icons for a rounded interface and crisper ones for a sharp one, so the icons feel part of the same product. These are conventions with a reason (optical harmony), not rules any standard mandates. ## Writing it down A style rule nobody can measure is a rule nobody follows. A useful icon style guide: 1. States each value **numerically** at the reference canvas, for example the stroke width and outer corner radius in canvas units. 2. Shows **do and don't pairs** for each attribute. 3. Provides a **starter template** with stroke, caps and joins pre-set, so a new contributor starts on-spec. 4. Lists the approved **metaphor for each concept**, so contributors reuse rather than reinvent. With these in place, the set can grow from fifty icons to several hundred and still read as one family, whether it ships to a web product, a native mobile app or a design editor library.