Как быстро создать и безболезненно внедрить большой набор иконок для цифровых продуктов и сервисов: опыт Райффайзенбанка
Во время работы над новой цифровой айдентикой Райффайзенбанка в Вене мы, совместно с филиалами в других странах, разработали новую стилистику иконок. Необходимо было ее поддержать и обновить текущий набор, дополнив новыми метафорами. Делюсь опытом, как выстроить максимально продуктивную работу с дизайнерами и сделать процесс внедрения новых иконок простым и легким для команд и разработчиков.
Итак, новый набор из более чем 500 иконок стал визуально легче и проще, сократилось количество точек и сложносоставных иконок. Мы значительно расширили его по сравнению с текущим, учли потребности всех команд, переработали ряд метафор и максимально подготовили инфраструктуру для комфортной работы с иконками.
Многие команды в банке работают по Scrum, особенно те, кто разрабатывает цифровые продукты и сервисы. Scrum имеет ряд преимуществ и недостатков в разрезе внедрения общих стандартов. Сделать что-то для всего банка не самая большая трудность для нашего дизайн-сообщества, гораздо более сложный – этап внедрения. У всех свои цели и приоритеты, и чтобы решения, которые разрабатываются на уровне всего банка, внедрялись просто и легко, нужно действовать определенным образом.
Чтобы командам было максимально просто начать использовать новый набор иконок, мы интегрировали его в общий репозиторий дизайн-системы, описали процесс изменения и создания новых иконок, подготовили подробный гайд, описали принципы построения и вовлекли всех амбассадоров и заказчиков иконок в самом начале проекта, чтобы снизить риск отторжения в дальнейшем. Дизайнеры участвовали в реализации новых иконок, давали полезную обратную связь и, по сути, делали их сами и для себя. Но обо всем по порядку.
Подготовка
Один из важнейших этапов проекта по переработке иконок – подготовительная работа, и если провести ее правильно, дальше все пойдёт гладко.
Рабочая группа
Чтобы учесть голос каждого, для кого важен этот проект, и убедиться, что в конце получится результат, приемлемый для всех, мы сформировали рабочую группу. В нее вошли «владельцы» иконок, в основном, это продуктовые дизайнеры из команд, использующих в работе значительное количество иконок. Группа участвовала в выборе наиболее подходящих метафор, помогала комментировать работу агентства в течение всего проекта.
Сбор и описание метафор
Рабочая группа помогла собрать иконки, которые использовались в разных командах – дизайнеры добавляли свои иконки в рабочий файл в облаке. Получилась солянка из разных метафор и стилистических решений, посмотрев на которую, вы поймете, почему так важно привести все к единообразию.
Чтобы в полотне таблицы было легко разобраться и нам, и дизайнерам агентства, его нужно хорошо структурировать. Структура нашего рабочего файла оказалась удобной и выглядела так:
- Категория – позволяет отфильтровать и посмотреть иконки только в заданной категории, а также дает понимание агентству, в какую категорию складывать иконки в Figma.
- Описание – поясняет дизайнерам из агентства, в каком контексте используется иконка.
- Имя файла – желательно, чтобы у всех иконок наименование было в едином формате. Мы выбрали простой стиль написания kebab-case: слова пишутся строчными буквами, а для разделения используется дефис. Имя файла в рабочем документе должно совпадать с именем файла в Figma. Дополнительно можно следовать строгим правилам наименования, например, исходить только из контекста использования иконки или только из значения метафоры. У нас получился симбиоз двух этих подходов.
- Наименования команд (Raiffeisen-Online (RO), Web-site...) – в этот раздел мы складывали иконки из разных команд для сравнения. Колонка Current Pack – для существующего набора. Метафора согласована, не согласована – отображает для агентства финальную метафору. Важно, что определяется только метафора, а не способ отрисовки.
- 16x16 / 24x24 – показывает нужные нам размеры иконок. Здесь же цветом отмечали готовность иконки со стороны агентства и проставляли дату выполнения.
Бриф для агентства
Чем больше информации в брифе, тем лучше. Поделюсь примером структуры нашего.
Количество иконок
Лучше заложить чуть больше элементов, чем нужно изначально, так как в процессе работы может потребоваться нарисовать несколько вариантов каждой иконки. Кроме этого, заказчику и агентству полезно понимать реальный объем работ, поэтому лучше сразу обозначить, сколько иконок нужно только перерисовать в новых гайдах, а скольким еще и придумать метафору.
Принципы построения
В нашем случае они максимально простые: все квадраты, прямоугольники и круги рисуются по заданной сетке; толщина линий равна 2 px; углы скругляются, но окончания остаются острыми – мягкие и острые формы рифмуются с логотипом.
Сетка
При построении иконок используется сетка и определяются основные размеры, допустимые к использованию. Мы используем два размера, основной – 24х24, дополнительный – 16х16. В размере 16х16 всего несколько иконок, в основном это стрелки, галочки и другие простые формы из категорий Actions и Navigation.
Технические требования (чек-лист)
Не стоит себя сдерживать, список должен быть максимально полным. Несколько примеров из нашего:
иконки нарисованы по заданной сетке;
- иконки должны быть названы в соответствии с рабочим документом;
- линии должны быть склеены в единый путь;
- иконка в Figma должна быть мастер-символом;
- и так далее.
Категоризация
Чтобы на выходе мы получили набор иконок, с которым будет быстро и удобно работать дизайнерам и разработчикам, необходимо заранее распределить все элементы по категориям. Если использовать поиск Figma, это значительно облегчит навигацию по объемному проекту и ускорит работу. В нашем случае это была хорошая возможность актуализировать наш список категорий. Так, появилась категория Actions, основная для иконок, которые чаще всего используются в интерфейсах; а стаканчик кофе, наконец, переместился из категории Sport в категорию Food and Restaurants.
Описание процесса
Лучше с самого начала определить удобный процесс работы с агентством. Мы двигались итерациями по 20-30 иконок. Для ускорения работы мы сделали под иконки отдельный файл в Figma, куда дали доступ дизайнерам из агентства. Каждый фрейм – отдельная категория. Под иконками проставили теги, чтобы было понятно, что это за иконка и в каком контексте она может использоваться.
Процесс создания
Нам потребовалось два чата: один для коммуникации с менеджером проекта из агентства, второй для рабочей группы.
В чате с агентством мы обсуждали метафоры, итерации, их готовность и правки. С периодичностью раз в две недели мы созванивались, чтобы пройтись по правкам чуть более детально и выровняться.
В чате с рабочей группой, состоящей из дизайнеров разных команд банка, мы в свободной форме обсуждали каждую итерацию. Я как менеджер проекта со стороны банка оценивал комментарии дизайнеров по чек-листу из брифа. Например, комментарий типа «что-то не то с иконкой» переводил в формат «не подходит стилистически» или «отрисована не по сетке, не по гайдам» и тд.
Все комментарии по каждой иконке я собирал в Notion – очень удобном сервисе для такого рода заметок. А чтобы ребятам из агентства было проще ориентироваться, в названии файла проставлял дату, а иконки распределял по категориям.
Внедрение
Чтобы готовый набор не свалился дизайнерам как снег на голову, я пригласил всех на релизную встречу, рассказал о проделанной работе и ответил на вопросы, а после отправил презентацию с необходимыми ссылками и инструкциями. На данном этапе иконки еще не внедрены в дизайн-систему, но были вполне готовы для теста на уровне дизайн-макетов.
Конечно, самый главный вопрос – это процесс обновления. Есть два варианта: разом обновить текущий набор или дать новому и старому набору какое-то время «пожить» вместе, пока все не перейдут на новый. В первом случае все иконки в проектах заменятся автоматически после коммита, при этом есть риск, что в процессе слетят, например, цвета, а на нас сваливается дополнительная работа – нужно вручную заменить более 500 текущих иконок на новые. Во втором случае можно отделаться малой кровью – каждый дизайнер у себя в проекте подключает новый файл и заменяет иконки новыми версиями, так же вручную, но только свою часть и постепенно.
В итоге выбрали второй вариант, где мы оставляем текущий набор как в коде, так и в дизайне, даем какое-то время на миграцию, а потом архивируем его.
Описание процесса создания и изменения иконки
Новый набор может меняться, и очень важно четко определить, каким образом дизайнеры могут добавлять или изменять иконки в рабочем файле в дальнейшем. Мы описали процесс в Figma, и он похож на то, как разработчики смотрят коммиты коллег, прежде чем отправить все в мастер: каждую новую иконку должны посмотреть и утвердить как минимум два дизайнера и один эксперт из команды бренда банка.
Сводный файл для разработчиков
Если у вас уже есть набор иконок, интегрированный в дизайн-систему, то для разработчиков необходимо подготовить сводный файл с соотнесенными новыми и старыми названиями файлов, категориями и прочим. Так разработчикам будет легче разобраться, какая иконка на какую меняется.
Не все прошло гладко с передачей иконок в разработку. Оказалось, что можно было значительно упростить работу как минимум разработчикам. Мне понравилась идея, которую предложила фронтенд-разработчик команды дизайн-системы: мы не собираем таблицу соответствия, а создаем папку, где будет лежать новая и старая иконка, таким образом, чтобы у старой или новой иконки был специфический префикс, например, «new». В ту же папку кладем конфиг, в котором описываем текущее название и категорию иконки, новое название и категорию, а также теги, которые будут помогать с поиском иконки на сайте дизайн-системы.
Потом это все прогоняется скриптом, который на выходе отдает так называемый «план миграции», то есть сопоставляет новую и старую иконку и заодно строит файл сопоставления иконки и тегов. Далее запускается Codemode, который опираясь на этот план миграции правит код, где используются иконки.
Но мы не стали так делать, так как уже была проделана большая работа по сборке таблиц в Figma. Ситуация еще усугубилась тем, что таблицы в Figma были сверстаны при помощи автолейаута и не было возможности скопировать содержимое каждой колонки отдельно, что также могло упростить процесс передачи для разработки. Чтобы не пересобирать таблицу в другом редакторе, пришлось поискать плагин, который смог выгрузить содержимое колонок из Figma в текстовом виде. Обошлись такой небольшой оптимизацией, чтобы хоть как-то упростить работу разработчикам.
Внедрение через дизайн-систему
Когда сводный файл готов, команда дизайн-системы может приступить к обновлению набора иконок. Затем каждая команда сможет их использовать у себя в проектах без каких-либо проблем.
Вместе с агентством мы в сжатые сроки отрисовали 570 иконок. Они стали визуально легче и проще. А благодаря вовлечению всех дизайнеров в работу, у нас не возникло проблем с дальнейшей интеграцией нового набора.
Проект обновления иконок стал одним из шагов на пути решения большой и сложной задачи – сделать бренд единым на всех площадках, объединив гайдлайны для интерфейсов и маркетинговой коммуникации. Перед нами ещё много вызовов, о которых я обязательно напишу в следующих сериях.
Я в целом хорошо отношусь к дизайнерам и не считаю их работу чем-то бесполезным, как это делают многие.
Но в этом конкретном случае я абсолюно не понимаю, куда, и что важнее - зачем было слито очевидно немало бюджета.
На картинке с Security иконками четко видно, что старые и новые иконки почти не отличаются. Для рядового юзера будет все равно, что старая, что новая иконка, что иконки из fontawesome или react-icons библиотек.
Вот ниже две иконки из react-icons библиотеки, которые по сути такие же, как и в новом дизайне.
И ладно бы штатному дизайнеру поставили таск "освежить" иконки в течение месяца - это ок. Но у вас собирался целый консилиум по этому поводу (рабочая группа), сборы метафор, мнения и прочее. А по факту получились точно такие же иконки.
Не буду утверждать, но уверен, что любой адекватный фрилансер сделал бы не хуже (а может и лучше) за бюджет в несколько раз скромнее затраченных средств на весь этот консилиум.
Если кратко - это тот самый случай, когда для замены лампочки привлекают весь штат электриков, размышляют, в какое время лучше делать замену, на какую табуретку становиться и с какой скоростью вкручивать.
Стас, спасибо за комментарий! Security – это не совсем удачный пример. Скриншот больше для ознакомления со структурой сводной таблицы. Мы всегда привлекаем дизайн-сообщество для подобных общебанковских проектов, так как верим, что так у нас больше шансов сделать бренд целостным. Статьи пишем для того, чтобы закрепить знания и поделиться информацией с вами ;)
Хочу чтобы вы меня правильно понимали - я не ради хейта написал. Вполне понимаю всю работу, которая была проделана. Но не понимаю смысл этой работы.
То есть, как уже писал выше, если бы это была задачка для одного штатного дизайнера на ближайшее время - да, окей. Без проблем, захотели освежить дизайн.
Но если формируется какая-то рабочая группа, всерьез обсуждаются метафоры, собираются мнения и комментарии людей по поводу старых/новых иконок - в моем понимании речь уже идет о каком-то серьезном редизайне, смене стилистики, переход с цветных иконок на монотонные (или наоборот).
То есть, в плане работы вопросов нет. Но остается не до конца понятным смысл такой глобализации этой задачи.
А за статью, безусловно, спасибо :)
Мне кажется часто разобраться с зоопарком иконок/интерфейсов/логотипов и т.д. сложнее, чем нарисовать все с нуля) Проследить что есть, какие есть требования, ничего ли не конфликтует и т.д.
И если будет большой редизайн, то эту работу все-равно придется проводить (скорее всего еще большую, т.к. система разрастется дальше). Ребята экономят свое время из будущего.
Отличный комментарий! Все именно так и есть. У нас очень много команд и у каждой свои запросы и потребности. Собрать всех вместе невероятно трудно. Чтобы команды начали пользоваться новым набором на уровне всего банка, необходимо учесть мнение каждой команды и прогнать процесс с тем, чтобы в дальнейшем было проще:)