Разница проявляется в производственной логике. Иконки рисуют по мере надобности, и через два года у компании накапливается зоопарк несовместимых стилей. Систему проектируют один раз — с сеткой, толщиной линии, характером скруглений — и дальше она масштабируется на сотни пиктограмм без потери идентичности. Это и экономически выгоднее: пиктограммы дешевле в производстве, чем фотографии и иллюстрации, большой пак рисуется единожды и переиспользуется на всех носителях.
Главная ошибка — проектировать иконки в вакууме, без привязки к остальной айдентике. Профессиональный подход строится на модульной математике, где параметры иконок выводятся из параметров типографики, а не придумываются отдельно.
Такие правила превращают иконографику из декоративного элемента в продолжение шрифтовой пары и логотипа — единую графическую ДНК.
В брендинге принято делить иконки по функции, но реальная практика показывает, что важнее делить их по способу называния и использования — иначе команда начинает путать смысловые и формальные иконки местами.
| Тип | Когда использовать | Пример логики |
|---|---|---|
| Функциональные | Управление интерфейсом: кнопки, навигация, статусы | «Поделиться», «Настройки», «Закрыть» |
| Информирующие | Обозначение категорий, разделов, характеристик товара | Иконки тарифов, характеристик услуги |
| Имиджевые | Крупные иллюстративные иконки для лендингов, презентаций | Иконка-иллюстрация в блоке «Преимущества» |
| Single-purpose (по смыслу) | Уникальная функция, которую нельзя перепутать с другой | «Atlassian Intelligence» — названа по смыслу, не по форме |
| Multi-purpose (по форме) | Универсальные знаки, применимые в разных контекстах | «arrow right», «globe» — названы по внешнему виду |
Подход Atlassian с двухуровневой категоризацией решает конкретную проблему: команда дизайнеров не путает уникальную иконку продукта с универсальной стрелкой, которую можно вставить куда угодно. Без такого разделения система быстро разрастается дублями с разными смыслами под одинаковой формой.
Красивая на вид иконка ещё не значит, что система работает. Есть конкретные, проверяемые критерии, а не только субъективное «нравится/не нравится».
Спроектировать систему — половина работы. Реальные проблемы начинаются на этапе внедрения, когда иконография попадает в веб, приложение, печатную продукцию и навигацию одновременно, и там начинают вылезать конфликты.
При изменении размера иконки меняется не только габарит, но и структура. BBC на своих 180 иконках в трёх размерах столкнулась с тем, что для мелких размеров пришлось полностью переделать пиктограммы: детали, читаемые на 32px, превращаются в грязное пятно на 16px. Если система изначально не предусматривает отдельную версию для мелкого масштаба — при внедрении на мобильных экранах и в навигации бренд теряет узнаваемость.
Одна и та же форма может читаться по-разному в разных культурных и продуктовых контекстах: «конверт» — это письмо или почтовое приложение, «шестерёнка» — настройки или технический раздел. При масштабировании системы на новые продукты команда обязана прогонять метафоры через тест на однозначность — иначе иконка начинает конфликтовать сама с собой в разных разделах продукта.
Система пиктограмм живёт годами и обновляется вместе с продуктом. Без единого репозитория с версиями и правилами наименования (по типу Atlassian с single/multi-purpose) через пару релизов появляются дубли и устаревшие варианты, которые дизайнеры продолжают использовать по инерции. Практический вывод: внедрение системы требует не только гайдлайна, но и библиотеки-источника правды (design system, Figma-библиотека), к которой обращаются все команды — от печати до мобильной разработки.
Разница проявляется в производственной логике. Иконки рисуют по мере надобности, и через два года у компании накапливается зоопарк несовместимых стилей. Систему проектируют один раз — с сеткой, толщиной линии, характером скруглений — и дальше она масштабируется на сотни пиктограмм без потери идентичности. Это и экономически выгоднее: пиктограммы дешевле в производстве, чем фотографии и иллюстрации, большой пак рисуется единожды и переиспользуется на всех носителях.
Главная ошибка — проектировать иконки в вакууме, без привязки к остальной айдентике. Профессиональный подход строится на модульной математике, где параметры иконок выводятся из параметров типографики, а не придумываются отдельно.
Такие правила превращают иконографику из декоративного элемента в продолжение шрифтовой пары и логотипа — единую графическую ДНК.
В брендинге принято делить иконки по функции, но реальная практика показывает, что важнее делить их по способу называния и использования — иначе команда начинает путать смысловые и формальные иконки местами.
| Тип | Когда использовать | Пример логики |
|---|---|---|
| Функциональные | Управление интерфейсом: кнопки, навигация, статусы | «Поделиться», «Настройки», «Закрыть» |
| Информирующие | Обозначение категорий, разделов, характеристик товара | Иконки тарифов, характеристик услуги |
| Имиджевые | Крупные иллюстративные иконки для лендингов, презентаций | Иконка-иллюстрация в блоке «Преимущества» |
| Single-purpose (по смыслу) | Уникальная функция, которую нельзя перепутать с другой | «Atlassian Intelligence» — названа по смыслу, не по форме |
| Multi-purpose (по форме) | Универсальные знаки, применимые в разных контекстах | «arrow right», «globe» — названы по внешнему виду |
Подход Atlassian с двухуровневой категоризацией решает конкретную проблему: команда дизайнеров не путает уникальную иконку продукта с универсальной стрелкой, которую можно вставить куда угодно. Без такого разделения система быстро разрастается дублями с разными смыслами под одинаковой формой.
Красивая на вид иконка ещё не значит, что система работает. Есть конкретные, проверяемые критерии, а не только субъективное «нравится/не нравится».
Спроектировать систему — половина работы. Реальные проблемы начинаются на этапе внедрения, когда иконография попадает в веб, приложение, печатную продукцию и навигацию одновременно, и там начинают вылезать конфликты.
При изменении размера иконки меняется не только габарит, но и структура. BBC на своих 180 иконках в трёх размерах столкнулась с тем, что для мелких размеров пришлось полностью переделать пиктограммы: детали, читаемые на 32px, превращаются в грязное пятно на 16px. Если система изначально не предусматривает отдельную версию для мелкого масштаба — при внедрении на мобильных экранах и в навигации бренд теряет узнаваемость.
Одна и та же форма может читаться по-разному в разных культурных и продуктовых контекстах: «конверт» — это письмо или почтовое приложение, «шестерёнка» — настройки или технический раздел. При масштабировании системы на новые продукты команда обязана прогонять метафоры через тест на однозначность — иначе иконка начинает конфликтовать сама с собой в разных разделах продукта.
Система пиктограмм живёт годами и обновляется вместе с продуктом. Без единого репозитория с версиями и правилами наименования (по типу Atlassian с single/multi-purpose) через пару релизов появляются дубли и устаревшие варианты, которые дизайнеры продолжают использовать по инерции. Практический вывод: внедрение системы требует не только гайдлайна, но и библиотеки-источника правды (design system, Figma-библиотека), к которой обращаются все команды — от печати до мобильной разработки.