Кастомные иконки в UI-kit: принципы разработки продуктовой иконографии
Почему иконка — это не файл, а система решений
Статьи про иконки обычно учат рисовать одну иконку хорошо. Но продуктовая иконография — это не набор картинок, а инфраструктура, через которую проходят десятки людей: дизайнеры, разработчики, менеджеры контента. Если в начале не заложить архитектуру — размеры, стили, правила именования, логику модификаторов — система расползётся сама, просто из-за количества локальных решений «здесь чуть по-другому, так удобнее».
Прежде чем открывать Figma, стоит ответить на три вопроса: какой конечный размер иконок в продукте, сколько стилей реально нужно бизнесу, и в каких форматах их будут забирать разработчики. Ответы на эти вопросы определяют всё остальное — нейминг, структуру файлов, процесс тестирования. Пропустить этот шаг — значит гарантированно переделывать систему через год.
Что ломается при простом масштабировании
Растянуть иконку 24×24 до 32×32 в два клика — соблазн, который убивает читаемость. При масштабировании визуально меняются не только габариты, но и три параметра, которые глаз считывает мгновенно:
- толщина линии — тонкая линия при увеличении выглядит слабой и «дешёвой», при уменьшении сливается в пятно;
- радиусы скруглений — крупный радиус на маленькой иконке съедает форму, мелкий на крупной иконке выглядит неряшливо;
- насыщенность формы — плотность деталей, которая читается на 32px, превращается в кашу на 16px.
Поэтому правильный подход — не масштабирование, а перерисовка под каждый ключевой размер с сохранением смысловой формы. На 16px детали упрощаются или убираются вовсе, на 32px можно добавить нюансы, которые на маленьком размере всё равно потеряются.
| Размер | Что происходит | Что нужно скорректировать |
|---|---|---|
| 16×16 | Детали слипаются, тонкие линии пропадают | Утолщить штрих, убрать мелкие элементы |
| 24×24 | Базовый рабочий размер большинства UI | Основная версия, от которой строятся остальные |
| 32×32 | Появляется «воздух», форма выглядит рыхлой | Добавить деталь, скорректировать пропорции толщины |
Оптический баланс: почему центр — это не центр
Иконка Play — классический пример проблемы, которую не решить линейкой. Треугольник в круге, выровненный строго по геометрическому центру, визуально «съезжает» влево. Дело в том, что оптический центр объекта расположен чуть выше геометрического — это особенность восприятия, а не ошибка глаза дизайнера.
Для точной коррекции используют формулы барицентра: круг для визуального баланса должен занимать 112,84% от площади квадрата, если сравнивать с формой, воспринимаемой как «равная» по весу. Для треугольника ориентируются на центроид — точку пересечения медиан, а не на геометрический центр фигуры. Разница небольшая — пара пикселей, — но именно она отделяет иконку, которая «сидит криво», от той, что выглядит идеально отцентрованной. На глаз это не поймать, если не знать, куда смотреть.
Нейминг: объект, а не функция
Одна из самых частых причин хаоса в растущей библиотеке — иконки называют по смыслу действия, а не по изображённому объекту. «Idea» вместо «Lamp», «Speed» вместо «Stopwatch» — ошибка, которая кажется удобной на старте и превращается в кошмар при масштабе 500+ иконок.
Проблема в том, что функциональные названия многозначны: «Speed» может означать скорость интернета, скорость доставки, ускорение анимации — разные команды начнут плодить дубли с одинаковым смыслом имени, но разной картинкой внутри. Объектное название однозначно: «Stopwatch» — это всегда секундомер, независимо от того, где его использует продукт. Дополнительно к названию нужно добавлять синонимы в описании компонента — так поиск в библиотеке находит иконку по любому логичному запросу, а не только по точному совпадению слова.
Сабглифы и модульная архитектура: как расти без взрыва
Когда система приближается к сотням иконок, встаёт вопрос: рисовать ли отдельную иконку «Добавить документ», «Удалить документ», «Документ со стрелкой», «Документ с крестом» — или найти способ не плодить сущности. Ответ — сабглифы, микроиконки-модификаторы (плюс, крест, стрелка, точка уведомления), которые комбинируются с базовой формой через компонентную сборку.
Вместо 500 отдельных иконок команда рисует 50 базовых объектов и 10–15 модификаторов, а нужные комбинации собираются на лету через варианты компонента в Figma. Это не только экономит время дизайнера — это единственный способ удержать систему управляемой, когда бизнес просит новую иконку каждую неделю. Без модульной архитектуры рост неизбежно превращается в распространение хаоса на весь интерфейс: у каждой команды появляется своя версия «плюсика», и через год никто не знает, какая из них каноническая.
Организация файлов и процесс, который не развалится через год
Технически правильная организация начинается с простого правила: все фреймы квадратные и одинакового размера (24×24px), даже если сама пиктограмма меньше рамки. Разработчикам так проще работать с SVG и CSS — не нужно каждый раз высчитывать смещение под конкретную иконку.
Второе правило касается внутренней структуры компонента — все векторные слои внутри должны называться одинаково, например просто «f». Это выглядит мелочью, но именно это позволяет менять одну иконку на другую через Instance в Figma без потери заданного цвета — при другом нейминге слоёв цвет слетает при замене, и дизайнер тратит время на ручную правку.
Процесс разработки крупной системы обычно выглядит так:
- Фиксируется цель пака: размеры, стили, форматы выгрузки — до отрисовки первой иконки.
- Собирается драфт-файл, где тестируются формы на сетке, проверяется оптический баланс и толщина линии на всех целевых размерах.
- Отрисовываются базовые объекты и сабглифы отдельно, затем собираются в компоненты с вариантами.
- Проводится тестирование в реальном интерфейсе — не в изоляции на белом фоне, а рядом с текстом и цветом бренда.
- Иконка публикуется в библиотеку с описанием, синонимами и версией для разработчиков.
Систему на 100+ человек в организации без единого источника правды удержать невозможно — расползание почти всегда начинается с локальных исключений: одна команда решила, что у неё «удобнее по-другому», старая версия иконки осталась в коде, в макетах живёт третья версия. Гайдлайн на 50 страниц с чек-листами и блок-схемами — это не бюрократия для галочки, а единственный работающий инструмент против такого распада. Он должен явно описывать, что делать, когда правила конфликтуют: например, оптический баланс важнее строгой геометрии, а единообразие нейминга важнее локального удобства одной команды. Связь с остальной дизайн-системой — типографикой, цветом, общей визуальной плотностью бренда — тоже фиксируется в гайде, иначе иконки начинают жить отдельной жизнью от интерфейса, в котором находятся.
Почему иконка — это не файл, а система решений
Статьи про иконки обычно учат рисовать одну иконку хорошо. Но продуктовая иконография — это не набор картинок, а инфраструктура, через которую проходят десятки людей: дизайнеры, разработчики, менеджеры контента. Если в начале не заложить архитектуру — размеры, стили, правила именования, логику модификаторов — система расползётся сама, просто из-за количества локальных решений «здесь чуть по-другому, так удобнее».
Прежде чем открывать Figma, стоит ответить на три вопроса: какой конечный размер иконок в продукте, сколько стилей реально нужно бизнесу, и в каких форматах их будут забирать разработчики. Ответы на эти вопросы определяют всё остальное — нейминг, структуру файлов, процесс тестирования. Пропустить этот шаг — значит гарантированно переделывать систему через год.
Что ломается при простом масштабировании
Растянуть иконку 24×24 до 32×32 в два клика — соблазн, который убивает читаемость. При масштабировании визуально меняются не только габариты, но и три параметра, которые глаз считывает мгновенно:
- толщина линии — тонкая линия при увеличении выглядит слабой и «дешёвой», при уменьшении сливается в пятно;
- радиусы скруглений — крупный радиус на маленькой иконке съедает форму, мелкий на крупной иконке выглядит неряшливо;
- насыщенность формы — плотность деталей, которая читается на 32px, превращается в кашу на 16px.
Поэтому правильный подход — не масштабирование, а перерисовка под каждый ключевой размер с сохранением смысловой формы. На 16px детали упрощаются или убираются вовсе, на 32px можно добавить нюансы, которые на маленьком размере всё равно потеряются.
| Размер | Что происходит | Что нужно скорректировать |
|---|---|---|
| 16×16 | Детали слипаются, тонкие линии пропадают | Утолщить штрих, убрать мелкие элементы |
| 24×24 | Базовый рабочий размер большинства UI | Основная версия, от которой строятся остальные |
| 32×32 | Появляется «воздух», форма выглядит рыхлой | Добавить деталь, скорректировать пропорции толщины |
Оптический баланс: почему центр — это не центр
Иконка Play — классический пример проблемы, которую не решить линейкой. Треугольник в круге, выровненный строго по геометрическому центру, визуально «съезжает» влево. Дело в том, что оптический центр объекта расположен чуть выше геометрического — это особенность восприятия, а не ошибка глаза дизайнера.
Для точной коррекции используют формулы барицентра: круг для визуального баланса должен занимать 112,84% от площади квадрата, если сравнивать с формой, воспринимаемой как «равная» по весу. Для треугольника ориентируются на центроид — точку пересечения медиан, а не на геометрический центр фигуры. Разница небольшая — пара пикселей, — но именно она отделяет иконку, которая «сидит криво», от той, что выглядит идеально отцентрованной. На глаз это не поймать, если не знать, куда смотреть.
Нейминг: объект, а не функция
Одна из самых частых причин хаоса в растущей библиотеке — иконки называют по смыслу действия, а не по изображённому объекту. «Idea» вместо «Lamp», «Speed» вместо «Stopwatch» — ошибка, которая кажется удобной на старте и превращается в кошмар при масштабе 500+ иконок.
Проблема в том, что функциональные названия многозначны: «Speed» может означать скорость интернета, скорость доставки, ускорение анимации — разные команды начнут плодить дубли с одинаковым смыслом имени, но разной картинкой внутри. Объектное название однозначно: «Stopwatch» — это всегда секундомер, независимо от того, где его использует продукт. Дополнительно к названию нужно добавлять синонимы в описании компонента — так поиск в библиотеке находит иконку по любому логичному запросу, а не только по точному совпадению слова.
Сабглифы и модульная архитектура: как расти без взрыва
Когда система приближается к сотням иконок, встаёт вопрос: рисовать ли отдельную иконку «Добавить документ», «Удалить документ», «Документ со стрелкой», «Документ с крестом» — или найти способ не плодить сущности. Ответ — сабглифы, микроиконки-модификаторы (плюс, крест, стрелка, точка уведомления), которые комбинируются с базовой формой через компонентную сборку.
Вместо 500 отдельных иконок команда рисует 50 базовых объектов и 10–15 модификаторов, а нужные комбинации собираются на лету через варианты компонента в Figma. Это не только экономит время дизайнера — это единственный способ удержать систему управляемой, когда бизнес просит новую иконку каждую неделю. Без модульной архитектуры рост неизбежно превращается в распространение хаоса на весь интерфейс: у каждой команды появляется своя версия «плюсика», и через год никто не знает, какая из них каноническая.
Организация файлов и процесс, который не развалится через год
Технически правильная организация начинается с простого правила: все фреймы квадратные и одинакового размера (24×24px), даже если сама пиктограмма меньше рамки. Разработчикам так проще работать с SVG и CSS — не нужно каждый раз высчитывать смещение под конкретную иконку.
Второе правило касается внутренней структуры компонента — все векторные слои внутри должны называться одинаково, например просто «f». Это выглядит мелочью, но именно это позволяет менять одну иконку на другую через Instance в Figma без потери заданного цвета — при другом нейминге слоёв цвет слетает при замене, и дизайнер тратит время на ручную правку.
Процесс разработки крупной системы обычно выглядит так:
- Фиксируется цель пака: размеры, стили, форматы выгрузки — до отрисовки первой иконки.
- Собирается драфт-файл, где тестируются формы на сетке, проверяется оптический баланс и толщина линии на всех целевых размерах.
- Отрисовываются базовые объекты и сабглифы отдельно, затем собираются в компоненты с вариантами.
- Проводится тестирование в реальном интерфейсе — не в изоляции на белом фоне, а рядом с текстом и цветом бренда.
- Иконка публикуется в библиотеку с описанием, синонимами и версией для разработчиков.
Систему на 100+ человек в организации без единого источника правды удержать невозможно — расползание почти всегда начинается с локальных исключений: одна команда решила, что у неё «удобнее по-другому», старая версия иконки осталась в коде, в макетах живёт третья версия. Гайдлайн на 50 страниц с чек-листами и блок-схемами — это не бюрократия для галочки, а единственный работающий инструмент против такого распада. Он должен явно описывать, что делать, когда правила конфликтуют: например, оптический баланс важнее строгой геометрии, а единообразие нейминга важнее локального удобства одной команды. Связь с остальной дизайн-системой — типографикой, цветом, общей визуальной плотностью бренда — тоже фиксируется в гайде, иначе иконки начинают жить отдельной жизнью от интерфейса, в котором находятся.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
