Custom icons in UI-kit: principles of developing product iconography
Why an icon is not a file, but a system of solutions
Articles about icons usually teach how to draw one icon well. But product iconography is not a set of images, but an infrastructure through which dozens of people pass: designers, developers, content managers. If you do not lay out the architecture from the beginning — sizes, styles, naming rules, logic of modifiers — the system will scatter on its own, simply due to the number of local solutions like "here a bit differently, it's more convenient".
Before opening Figma, you should answer three questions: what is the final size of icons in the product, how many styles are really needed by the business, and in what formats will developers be retrieving them. Answers to these questions determine everything else — naming, file structure, testing process. Skipping this step means guaranteeing a system redesign within a year.
What breaks with simple scaling
Stretching an icon 24×24 to 32×32 in two clicks — a temptation that kills readability. When scaling, not only the dimensions visually change, but three parameters that the eye instantly reads:
- line thickness — a thin line looks weak and 'cheap' when magnified, and merges into a spot when reduced;
- rounding radii — a large radius on a small icon eats up the shape, a small radius on a large icon looks sloppy;
- form saturation — the density of details readable at 32px turns into a mess at 16px.
Therefore, the correct approach is not scaling, but redrawing for each key size while preserving the semantic form. At 16px, details are simplified or removed entirely; at 32px, nuances can be added that would be lost at a small size.
| Size | What happens | What needs to be adjusted |
|---|---|---|
| 16×16 | Details merge, thin lines disappear | Thicken the stroke, remove small elements |
| 24×24 | Base working size for most UI | Main version from which others are built |
| 32×32 | Air appears, the form looks loose | Add detail, adjust thickness proportions |
Optical balance: why the center is not the center
Play icon — a classic example of a problem that cannot be solved with a ruler. A triangle in a circle, aligned strictly to the geometric center, visually 'shifts' to the left. The reason is that the optical center of the object is located slightly above the geometric one — this is a feature of perception, not an error of the designer's eye.
For accurate correction, barycenter formulas are used: a circle for visual balance should occupy 112,84% of the square's area if comparing with a shape perceived as 'equal' in weight. For a triangle, reference is made to the centroid — the point of intersection of the medians, not the geometric center of the figure. The difference is small — a couple of pixels — but it is exactly this that separates an icon that 'sits crookedly' from one that looks perfectly centered. By eye, this is hard to detect unless you know where to look.
Naming: object, not function
One of the most frequent causes of chaos in a growing library — icons are named by the meaning of the action, not by the object depicted. 'Idea' instead of 'Lamp', 'Speed' instead of 'Stopwatch' — an error that seems convenient at the start and turns into a nightmare at a scale of 500+ icons.
The problem is that functional names are polysemous: 'Speed' can mean internet speed, delivery speed, animation acceleration — different teams will start creating duplicates with the same semantic meaning but different visuals inside. Object names are unambiguous: 'Stopwatch' is always a stopwatch, regardless of where a product uses it. Additionally, synonyms should be added to the description of the component — this way, searches in the library find the icon for any logical request, not just an exact word match.
Subglyphs and modular architecture: how to grow without an explosion
When the system approaches hundreds of icons, the question arises: should we draw a separate icon for 'Add document', 'Delete document', 'Document with an arrow', 'Document with a cross' — or find a way not to proliferate entities? The answer is subglyphs, micro-icons-modifiers (plus, cross, arrow, notification dot), which are combined with the base form through component assembly.
Instead of 500 individual icons, the team draws 50 base objects and 10–15 modifiers, and the required combinations are assembled on the fly through component variants in Figma. This not only saves the designer's time — it is the only way to keep the system manageable when the business asks for a new icon every week. Without a modular architecture, growth inevitably turns into the spread of chaos across the entire interface: each team gets its own version of the 'plus', and after a year nobody knows which one is canonical.
File organization and the process that will not fall apart in a year
Technically correct organization starts with a simple rule: all frames are square and the same size (24×24px), even if the icon itself is smaller than the frame. This makes it easier for developers to work with SVG and CSS — they don't need to calculate offset for each specific icon every time.
The second rule concerns the internal structure of the component — all vector layers inside must be named the same, for example simply 'f'. This may seem like a minor detail, but it's precisely this that allows changing one icon for another through Instance in Figma without losing the assigned color — with different layer naming, the color is lost during replacement, and the designer spends time manually fixing it.
The process of developing a large system usually looks like this:
- The pack goal is defined: sizes, styles, export formats — before drawing the first icon.
- A draft file is assembled where forms are tested on the grid, optical balance and line thickness are checked at all target sizes.
- Base objects and subglyphs are drawn separately, then assembled into components with variants.
- Testing is conducted in a real interface — not in isolation on a white background, but next to text and brand color.
- The icon is published in the library with a description, synonyms, and a version for developers.
A system with 100+ people in an organization cannot be maintained without a single source of truth — dispersion almost always begins with local exceptions: one team decided that 'it's more convenient another way', the old version of the icon remained in the code, a third version lives in the layouts. A guideline for 50 pages with checklists and flowcharts is not bureaucracy for the sake of it, but the only working tool against such dispersion. It must explicitly describe what to do when rules conflict: for example, optical balance is more important than strict geometry, and consistent nomenclature is more important than local convenience for one team. The connection with the rest of the design system — typography, color, overall visual density of the brand — is also fixed in the guide, otherwise icons begin to live separate lives from the interface they are in.
Why an icon is not a file, but a system of solutions
Articles about icons usually teach how to draw one icon well. But product iconography is not a set of images, but an infrastructure through which dozens of people pass: designers, developers, content managers. If you do not lay out the architecture from the beginning — sizes, styles, naming rules, logic of modifiers — the system will scatter on its own, simply due to the number of local solutions like "here a bit differently, it's more convenient".
Before opening Figma, you should answer three questions: what is the final size of icons in the product, how many styles are really needed by the business, and in what formats will developers be retrieving them. Answers to these questions determine everything else — naming, file structure, testing process. Skipping this step means guaranteeing a system redesign within a year.
What breaks with simple scaling
Stretching an icon 24×24 to 32×32 in two clicks — a temptation that kills readability. When scaling, not only the dimensions visually change, but three parameters that the eye instantly reads:
- line thickness — a thin line looks weak and 'cheap' when magnified, and merges into a spot when reduced;
- rounding radii — a large radius on a small icon eats up the shape, a small radius on a large icon looks sloppy;
- form saturation — the density of details readable at 32px turns into a mess at 16px.
Therefore, the correct approach is not scaling, but redrawing for each key size while preserving the semantic form. At 16px, details are simplified or removed entirely; at 32px, nuances can be added that would be lost at a small size.
| Size | What happens | What needs to be adjusted |
|---|---|---|
| 16×16 | Details merge, thin lines disappear | Thicken the stroke, remove small elements |
| 24×24 | Base working size for most UI | Main version from which others are built |
| 32×32 | Air appears, the form looks loose | Add detail, adjust thickness proportions |
Optical balance: why the center is not the center
Play icon — a classic example of a problem that cannot be solved with a ruler. A triangle in a circle, aligned strictly to the geometric center, visually 'shifts' to the left. The reason is that the optical center of the object is located slightly above the geometric one — this is a feature of perception, not an error of the designer's eye.
For accurate correction, barycenter formulas are used: a circle for visual balance should occupy 112,84% of the square's area if comparing with a shape perceived as 'equal' in weight. For a triangle, reference is made to the centroid — the point of intersection of the medians, not the geometric center of the figure. The difference is small — a couple of pixels — but it is exactly this that separates an icon that 'sits crookedly' from one that looks perfectly centered. By eye, this is hard to detect unless you know where to look.
Naming: object, not function
One of the most frequent causes of chaos in a growing library — icons are named by the meaning of the action, not by the object depicted. 'Idea' instead of 'Lamp', 'Speed' instead of 'Stopwatch' — an error that seems convenient at the start and turns into a nightmare at a scale of 500+ icons.
The problem is that functional names are polysemous: 'Speed' can mean internet speed, delivery speed, animation acceleration — different teams will start creating duplicates with the same semantic meaning but different visuals inside. Object names are unambiguous: 'Stopwatch' is always a stopwatch, regardless of where a product uses it. Additionally, synonyms should be added to the description of the component — this way, searches in the library find the icon for any logical request, not just an exact word match.
Subglyphs and modular architecture: how to grow without an explosion
When the system approaches hundreds of icons, the question arises: should we draw a separate icon for 'Add document', 'Delete document', 'Document with an arrow', 'Document with a cross' — or find a way not to proliferate entities? The answer is subglyphs, micro-icons-modifiers (plus, cross, arrow, notification dot), which are combined with the base form through component assembly.
Instead of 500 individual icons, the team draws 50 base objects and 10–15 modifiers, and the required combinations are assembled on the fly through component variants in Figma. This not only saves the designer's time — it is the only way to keep the system manageable when the business asks for a new icon every week. Without a modular architecture, growth inevitably turns into the spread of chaos across the entire interface: each team gets its own version of the 'plus', and after a year nobody knows which one is canonical.
File organization and the process that will not fall apart in a year
Technically correct organization starts with a simple rule: all frames are square and the same size (24×24px), even if the icon itself is smaller than the frame. This makes it easier for developers to work with SVG and CSS — they don't need to calculate offset for each specific icon every time.
The second rule concerns the internal structure of the component — all vector layers inside must be named the same, for example simply 'f'. This may seem like a minor detail, but it's precisely this that allows changing one icon for another through Instance in Figma without losing the assigned color — with different layer naming, the color is lost during replacement, and the designer spends time manually fixing it.
The process of developing a large system usually looks like this:
- The pack goal is defined: sizes, styles, export formats — before drawing the first icon.
- A draft file is assembled where forms are tested on the grid, optical balance and line thickness are checked at all target sizes.
- Base objects and subglyphs are drawn separately, then assembled into components with variants.
- Testing is conducted in a real interface — not in isolation on a white background, but next to text and brand color.
- The icon is published in the library with a description, synonyms, and a version for developers.
A system with 100+ people in an organization cannot be maintained without a single source of truth — dispersion almost always begins with local exceptions: one team decided that 'it's more convenient another way', the old version of the icon remained in the code, a third version lives in the layouts. A guideline for 50 pages with checklists and flowcharts is not bureaucracy for the sake of it, but the only working tool against such dispersion. It must explicitly describe what to do when rules conflict: for example, optical balance is more important than strict geometry, and consistent nomenclature is more important than local convenience for one team. The connection with the rest of the design system — typography, color, overall visual density of the brand — is also fixed in the guide, otherwise icons begin to live separate lives from the interface they are in.
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
