Как быстро создать и безболезненно внедрить большой набор иконок для цифровых продуктов и сервисов: опыт Райффайзенбанка

Во время работы над новой цифровой айдентикой Райффайзенбанка в Вене мы, совместно с филиалами в других странах, разработали новую стилистику иконок. Необходимо было ее поддержать и обновить текущий набор, дополнив новыми метафорами. Делюсь опытом, как выстроить максимально продуктивную работу с дизайнерами и сделать процесс внедрения новых иконок простым и легким для команд и разработчиков.

Как быстро создать и безболезненно внедрить большой набор иконок для цифровых продуктов и сервисов: опыт Райффайзенбанка

Итак, новый набор из более чем 500 иконок стал визуально легче и проще, сократилось количество точек и сложносоставных иконок. Мы значительно расширили его по сравнению с текущим, учли потребности всех команд, переработали ряд метафор и максимально подготовили инфраструктуру для комфортной работы с иконками.

Многие команды в банке работают по Scrum, особенно те, кто разрабатывает цифровые продукты и сервисы. Scrum имеет ряд преимуществ и недостатков в разрезе внедрения общих стандартов. Сделать что-то для всего банка не самая большая трудность для нашего дизайн-сообщества, гораздо более сложный – этап внедрения. У всех свои цели и приоритеты, и чтобы решения, которые разрабатываются на уровне всего банка, внедрялись просто и легко, нужно действовать определенным образом.

Чтобы командам было максимально просто начать использовать новый набор иконок, мы интегрировали его в общий репозиторий дизайн-системы, описали процесс изменения и создания новых иконок, подготовили подробный гайд, описали принципы построения и вовлекли всех амбассадоров и заказчиков иконок в самом начале проекта, чтобы снизить риск отторжения в дальнейшем. Дизайнеры участвовали в реализации новых иконок, давали полезную обратную связь и, по сути, делали их сами и для себя. Но обо всем по порядку.

Подготовка

Один из важнейших этапов проекта по переработке иконок – подготовительная работа, и если провести ее правильно, дальше все пойдёт гладко.

Первая встреча с рабочей группой
Первая встреча с рабочей группой

Рабочая группа

Чтобы учесть голос каждого, для кого важен этот проект, и убедиться, что в конце получится результат, приемлемый для всех, мы сформировали рабочую группу. В нее вошли «владельцы» иконок, в основном, это продуктовые дизайнеры из команд, использующих в работе значительное количество иконок. Группа участвовала в выборе наиболее подходящих метафор, помогала комментировать работу агентства в течение всего проекта.

Сбор и описание метафор

Рабочая группа помогла собрать иконки, которые использовались в разных командах – дизайнеры добавляли свои иконки в рабочий файл в облаке. Получилась солянка из разных метафор и стилистических решений, посмотрев на которую, вы поймете, почему так важно привести все к единообразию.

Рабочий файл
Рабочий файл

Чтобы в полотне таблицы было легко разобраться и нам, и дизайнерам агентства, его нужно хорошо структурировать. Структура нашего рабочего файла оказалась удобной и выглядела так:

  • Категория – позволяет отфильтровать и посмотреть иконки только в заданной категории, а также дает понимание агентству, в какую категорию складывать иконки в Figma.
  • Описание – поясняет дизайнерам из агентства, в каком контексте используется иконка.
  • Имя файла – желательно, чтобы у всех иконок наименование было в едином формате. Мы выбрали простой стиль написания kebab-case: слова пишутся строчными буквами, а для разделения используется дефис. Имя файла в рабочем документе должно совпадать с именем файла в Figma. Дополнительно можно следовать строгим правилам наименования, например, исходить только из контекста использования иконки или только из значения метафоры. У нас получился симбиоз двух этих подходов.
  • Наименования команд (Raiffeisen-Online (RO), Web-site...) – в этот раздел мы складывали иконки из разных команд для сравнения. Колонка Current Pack – для существующего набора. Метафора согласована, не согласована – отображает для агентства финальную метафору. Важно, что определяется только метафора, а не способ отрисовки.
  • 16x16 / 24x24 – показывает нужные нам размеры иконок. Здесь же цветом отмечали готовность иконки со стороны агентства и проставляли дату выполнения.

Tips&Trics: Рабочий документ на подготовительном этапе можно собирать где удобно: в Google Docs, в iCloud. Главное, чтобы все могли туда добавлять иконки из своих проектов.

Бриф для агентства

Чем больше информации в брифе, тем лучше. Поделюсь примером структуры нашего.

Количество иконок

Лучше заложить чуть больше элементов, чем нужно изначально, так как в процессе работы может потребоваться нарисовать несколько вариантов каждой иконки. Кроме этого, заказчику и агентству полезно понимать реальный объем работ, поэтому лучше сразу обозначить, сколько иконок нужно только перерисовать в новых гайдах, а скольким еще и придумать метафору.

Принципы построения

Принципы
Принципы

В нашем случае они максимально простые: все квадраты, прямоугольники и круги рисуются по заданной сетке; толщина линий равна 2 px; углы скругляются, но окончания остаются острыми – мягкие и острые формы рифмуются с логотипом.

Tips&Trics: Иконки должны быть максимально простыми, хорошо считываться, желательно, чтобы они не были сложносоставными, содержали не более двух объектов внутри и не несли двойного смысла. Не стоит пытаться вложить в иконку все содержание и смысл метафоры, иначе будет каша, и никто не сможет уловить смысл.

Сетка

При построении иконок используется сетка и определяются основные размеры, допустимые к использованию. Мы используем два размера, основной – 24х24, дополнительный – 16х16. В размере 16х16 всего несколько иконок, в основном это стрелки, галочки и другие простые формы из категорий Actions и Navigation.

Основные размеры
Основные размеры

Tips&Trics: Не нужно абсолютно все пытаться впихнуть в сетку, иначе в определенных группах у разных иконок будет неправильная развесовка, когда одна иконка кажется меньше или, наоборот, больше другой. У нас были исключения, но они составляли всего 10-15 % проекта.

Технические требования (чек-лист)

Не стоит себя сдерживать, список должен быть максимально полным. Несколько примеров из нашего:

  • иконки нарисованы по заданной сетке;

  • иконки должны быть названы в соответствии с рабочим документом;
  • линии должны быть склеены в единый путь;
  • иконка в Figma должна быть мастер-символом;
  • и так далее.

Категоризация

Чтобы на выходе мы получили набор иконок, с которым будет быстро и удобно работать дизайнерам и разработчикам, необходимо заранее распределить все элементы по категориям. Если использовать поиск Figma, это значительно облегчит навигацию по объемному проекту и ускорит работу. В нашем случае это была хорошая возможность актуализировать наш список категорий. Так, появилась категория Actions, основная для иконок, которые чаще всего используются в интерфейсах; а стаканчик кофе, наконец, переместился из категории Sport в категорию Food and Restaurants.

Описание процесса

Лучше с самого начала определить удобный процесс работы с агентством. Мы двигались итерациями по 20-30 иконок. Для ускорения работы мы сделали под иконки отдельный файл в Figma, куда дали доступ дизайнерам из агентства. Каждый фрейм – отдельная категория. Под иконками проставили теги, чтобы было понятно, что это за иконка и в каком контексте она может использоваться.

Файл с иконками в Фигма
Файл с иконками в Фигма

Tips&Trics: Теги или описание метафоры под каждой иконкой в Figma лучше проставлять сразу, в процессе. Я этого не сделал, и потом мне пришлось потратить досадно много времени на тегирование 570 элементов.

Процесс создания

Нам потребовалось два чата: один для коммуникации с менеджером проекта из агентства, второй для рабочей группы.

В чате с агентством мы обсуждали метафоры, итерации, их готовность и правки. С периодичностью раз в две недели мы созванивались, чтобы пройтись по правкам чуть более детально и выровняться.

Для нашего креативного агентства, которое в основном специализируется на решениях с активным внедрением иллюстраций, этот заказ стал уникальным! Объем по началу пугал, но мы не подавали вида, а со временем уже привыкли и воспитали в себе новый для нас режим работы над проектом. И тут я должен сказать, что в этом очень сильно помогла вся подготовительная работа, которую проделали все участники проекта со стороны заказчика – такой скрупулезности в постановке задачи я ещё не встречал ни на одном из проектов, коих было не мало.

После того, как мы разобрались со всеми инструментами – бриф, сетка, гайд, рабочая таблица, рабочие чаты и предложили тоже кое-что оптимизировать на стадии согласования и заказчик с этим согласился, мы решили сделать «тренировочный заход» и создать минимальный тестовый набор иконок, чтобы обкатать все механизмы. После испытаний и обсуждения результатов, мы начали работу с дизайнером и набрали нужный темп. Регулярность, контакт и темп – наверное ключевые факторы этого марафона.

Дмитрий,

продюсер проекта, креативное агентство «Вьюга»

Tips&Trics: В самом начале проекта нужно набраться терпения, так как дизайнерам-отрисовщикам из агентства нужно время, чтобы прочувствовать правила и принципы, описанные в гайдах. Будьте готовы к ошибкам: у нас в начале их было около 50% в каждой итерации, а затем количество несоответствий сократилось до 20-10%.

В чате с рабочей группой, состоящей из дизайнеров разных команд банка, мы в свободной форме обсуждали каждую итерацию. Я как менеджер проекта со стороны банка оценивал комментарии дизайнеров по чек-листу из брифа. Например, комментарий типа «что-то не то с иконкой» переводил в формат «не подходит стилистически» или «отрисована не по сетке, не по гайдам» и тд.

Переписка в рабочем чате с дизайнерами
Переписка в рабочем чате с дизайнерами

В нашем приложении используется очень много иконок, и некоторые из них встречаются в разных контекстах. Поэтому важно было проверить все существующие метафоры, а также убедиться, что после обновления набора иконки будут корректно использоваться всеми командами банка. Так, мы пересмотрели некоторые визуальные образы, чтобы они могли использоваться во всех продуктах и интерфейсах. Мы уже обновили все иконки в UI Kit и теперь проверяем, все ли потребности покрывает новый набор.

Ольга Струзберг, старший UX-дизайнер, Райффайзенбанк

Все комментарии по каждой иконке я собирал в Notion – очень удобном сервисе для такого рода заметок. А чтобы ребятам из агентства было проще ориентироваться, в названии файла проставлял дату, а иконки распределял по категориям.

Файл с обратной связью для каждой итерации в Notion
Файл с обратной связью для каждой итерации в Notion

Tips&Trics: Коммуникаций в процессе не должно быть слишком много. После отрисовки всех иконок я решил еще раз критически посмотреть на них с дизайнерами банка, и сделал созвоны раз в неделю. Каждую из 500 (!) иконок мы могли обсуждать минут 20, и очень скоро я осознал, что если мы будем продолжать в том же духе, проект затянется на несколько месяцев. Чтобы сэкономить время, я решил сам экспертно оценить результат, а локальные проблемы с каждой иконкой решать отдельно уже после релиза.

Внедрение

Чтобы готовый набор не свалился дизайнерам как снег на голову, я пригласил всех на релизную встречу, рассказал о проделанной работе и ответил на вопросы, а после отправил презентацию с необходимыми ссылками и инструкциями. На данном этапе иконки еще не внедрены в дизайн-систему, но были вполне готовы для теста на уровне дизайн-макетов.

Конечно, самый главный вопрос – это процесс обновления. Есть два варианта: разом обновить текущий набор или дать новому и старому набору какое-то время «пожить» вместе, пока все не перейдут на новый. В первом случае все иконки в проектах заменятся автоматически после коммита, при этом есть риск, что в процессе слетят, например, цвета, а на нас сваливается дополнительная работа – нужно вручную заменить более 500 текущих иконок на новые. Во втором случае можно отделаться малой кровью – каждый дизайнер у себя в проекте подключает новый файл и заменяет иконки новыми версиями, так же вручную, но только свою часть и постепенно.

Как быстро создать и безболезненно внедрить большой набор иконок для цифровых продуктов и сервисов: опыт Райффайзенбанка

В итоге выбрали второй вариант, где мы оставляем текущий набор как в коде, так и в дизайне, даем какое-то время на миграцию, а потом архивируем его.

Описание процесса создания и изменения иконки

Новый набор может меняться, и очень важно четко определить, каким образом дизайнеры могут добавлять или изменять иконки в рабочем файле в дальнейшем. Мы описали процесс в Figma, и он похож на то, как разработчики смотрят коммиты коллег, прежде чем отправить все в мастер: каждую новую иконку должны посмотреть и утвердить как минимум два дизайнера и один эксперт из команды бренда банка.

Сводный файл для разработчиков

Если у вас уже есть набор иконок, интегрированный в дизайн-систему, то для разработчиков необходимо подготовить сводный файл с соотнесенными новыми и старыми названиями файлов, категориями и прочим. Так разработчикам будет легче разобраться, какая иконка на какую меняется.

Сводная таблица в Фигма
Сводная таблица в Фигма

Tips&Trics: Для быстрого поиска иконки на портале дизайн-системы в сводной таблице необходимо указать теги.

Не все прошло гладко с передачей иконок в разработку. Оказалось, что можно было значительно упростить работу как минимум разработчикам. Мне понравилась идея, которую предложила фронтенд-разработчик команды дизайн-системы: мы не собираем таблицу соответствия, а создаем папку, где будет лежать новая и старая иконка, таким образом, чтобы у старой или новой иконки был специфический префикс, например, «new». В ту же папку кладем конфиг, в котором описываем текущее название и категорию иконки, новое название и категорию, а также теги, которые будут помогать с поиском иконки на сайте дизайн-системы.

Файловая структура вместо таблицы
Файловая структура вместо таблицы

Потом это все прогоняется скриптом, который на выходе отдает так называемый «план миграции», то есть сопоставляет новую и старую иконку и заодно строит файл сопоставления иконки и тегов. Далее запускается Codemode, который опираясь на этот план миграции правит код, где используются иконки.

Но мы не стали так делать, так как уже была проделана большая работа по сборке таблиц в Figma. Ситуация еще усугубилась тем, что таблицы в Figma были сверстаны при помощи автолейаута и не было возможности скопировать содержимое каждой колонки отдельно, что также могло упростить процесс передачи для разработки. Чтобы не пересобирать таблицу в другом редакторе, пришлось поискать плагин, который смог выгрузить содержимое колонок из Figma в текстовом виде. Обошлись такой небольшой оптимизацией, чтобы хоть как-то упростить работу разработчикам.

«Чтобы иконки корректно заехали в нашу библиотеку на фронте, мы начали составлять таблицу соответствия в Figma. Когда значительная часть работы уже была проделана, встретились с фронтенд-разработчиками по конкретной реализации, и оказалось, что табличка в Figma не очень подходит для выгрузки в код. Для корректного обновления ребята предложили написать скрипт, который мог бы помочь свести иконки и их названия, но так как мы уже потратили несколько недель на сборку сводных таблиц по каждой категории, решили выгрузить их в текстовом виде в отдельный файл, а в следующий раз попробовать скрипт. 😅 Мы сделали выводы и в очередной раз отметили необходимость синхронизации на каждом из этапов»

Виктория Дубровская,

руководитель направления по развитию платформ разработки Core Foundation Mobile and Frontend

Внедрение через дизайн-систему

Когда сводный файл готов, команда дизайн-системы может приступить к обновлению набора иконок. Затем каждая команда сможет их использовать у себя в проектах без каких-либо проблем.

Вместе с агентством мы в сжатые сроки отрисовали 570 иконок. Они стали визуально легче и проще. А благодаря вовлечению всех дизайнеров в работу, у нас не возникло проблем с дальнейшей интеграцией нового набора.

Проект обновления иконок стал одним из шагов на пути решения большой и сложной задачи – сделать бренд единым на всех площадках, объединив гайдлайны для интерфейсов и маркетинговой коммуникации. Перед нами ещё много вызовов, о которых я обязательно напишу в следующих сериях.

7272
57 комментариев
100 ₽

Олег, моё почтение, пиши ещё с сохранением орфографии 👍🏻

Ответить

Я в целом хорошо отношусь к дизайнерам и не считаю их работу чем-то бесполезным, как это делают многие. 
Но в этом конкретном случае я абсолюно не понимаю, куда, и что важнее - зачем было слито очевидно немало бюджета.

На картинке с Security иконками четко видно, что старые и новые иконки почти не отличаются. Для рядового юзера будет все равно, что старая, что новая иконка, что иконки из fontawesome или react-icons библиотек. 
Вот ниже две иконки из react-icons библиотеки, которые по сути такие же, как и в новом дизайне. 

И ладно бы штатному дизайнеру поставили таск "освежить" иконки в течение месяца - это ок. Но у вас собирался целый консилиум по этому поводу (рабочая группа), сборы метафор, мнения и прочее. А по факту получились точно такие же иконки. 

Не буду утверждать, но уверен, что любой адекватный фрилансер сделал бы не хуже (а может и лучше) за бюджет в несколько раз скромнее затраченных средств на весь этот консилиум. 

Если кратко - это тот самый случай, когда для замены лампочки привлекают весь штат электриков, размышляют, в какое время лучше делать замену, на какую табуретку становиться и с какой скоростью вкручивать. 

27
Ответить

Стас, спасибо за комментарий! Security – это не совсем удачный пример. Скриншот больше для ознакомления со структурой сводной таблицы. Мы всегда привлекаем дизайн-сообщество для подобных общебанковских проектов, так как верим, что так у нас больше шансов сделать бренд целостным. Статьи пишем для того, чтобы закрепить знания и поделиться информацией с вами ;)

4
Ответить

Еще такой момент, если вырвать из контекста то усилия именно здесь, с иконками избыточны. Но если посмотреть на работу над дизайном достаточно большой структуры в целом то это только одна из частей которые неизбежно нужно поддерживать и согласовывать.

Многие понятно, решат что да это лишнее, слитый бюджет ИБД и тп. Но нужно понимать что в дизайне в целом не бывает “второстепенных”  вещей (хотя для стартапа это может и оправдано). В большом продукте весь опыт складывается из этих вот “мелочей”. Одна цепочка действий пользователя уже включает в себя несколько элементов интерфейса. Допустим один из них сочли не важным и отложили, другой отдали фрилансеру чтобы не отвлекаться, третий достался в наследство от старой версии и решили не трогать (работает же!). А теперь представим что только в одном продукте таких взаимодействий могут быть десятки и в каждом есть элементы с такими вот недоработками. После 2-х 3-х обновлений возможно это даже будет не заметно, но в какой то момент накопится критическая масса мелочей и они уже перестанут быть мелочами. Один баг/неаккуратность может быть незаметна, 2-3 — не критично, 4-сойдет ок, а после какого-то количества начнется паника “*$@!! что стало с нашим продуктом?”

И таких примеров много, когда с точки зрения функционала вроде все нормально но в процессе использования что то постоянно раздражает. Большинство пользователей даже не поймут что именно, но будут беситься. А раздражать будет как раз вот этот холистический эффект от кривых мелочей. 
Простой пример: в некоторых переходах кривая анимация (лишь чуть чуть отличающаяся от нативной) и из этого создается ощущение что приложение постоянно лагает или подтормаживает, хотя там просто эффект выбивается из привычных паттернов. Кто в теме, тот заметит, а обычный пользователь будет думать что приложение так “тупит” а вот в другом “все гладко”. 

Ну это не говоря уже о том, что продуктов может быть несколько и если на каком то этапе это запустить то накопится такой завал и хаос в бэклоге, что проще будет начать переделывать все с нуля. 

3
Ответить

«Деньги для нашей организации не так важны, как честность партнеров». © Казино Рояль
Здесь читай: стабильность, качество, предсказуемость результата.

Ответить

Комментарий недоступен

20
Ответить