Завязка
Когда я присоединился к одной из продуктовых команд в качестве дизайнера, передо мной стояла большая задача по рефакторингу интерфейса сложных внутренних систем. Продукты, над которыми мы работали, долгое время развивались без участия дизайнера. В этой ситуации каждый делал, что мог: бизнес предлагал решения, аналитики писали документацию и одновременно с этим рисовали макеты, а разработчики пытались это всё реализовать. Интерфейсы были местами сложными и несогласованными. Было заметно, что руки UX-дизайнера здесь не хватало.

Вскоре, активно включившись в работу, понял, что, пока занят упрощением сложных сценариев и разработкой паттернов, в бэклоге копится огромное количество небольших задач: исправить текст, скорректировать текущую форму, обновить отдельные компоненты. Другими словами, много маленьких задач остаются без моего внимания, и с ними мне требовалась помощь.
Тогда у меня появилась идея: если они раньше создавали большие полноценные макеты, то могли бы помочь мне справиться с моими простыми задачами на уровне подготовки документации? А я мог бы обучить их делать это сразу с использованием компонентов дизайн-системы (ДС) банка? Это позволило бы работать над простыми задачами самостоятельно, повышая общую производительность команды и сокращая time-to-market. Ведь те задачи, в которых не требовалась дизайн-экспертиза, можно было выполнить без привлечения дизайнера быстрее и проще.
Я расскажу о том, как получилось организовать обучение аналитиков дизайнерскому ремеслу: работе в графическом редакторе, основам UX/UI и т.д.

Поиск решения: как убедить руководство
Идея выглядела логично, но одно дело — задумка, и совсем другое — её реализация. Первым делом необходимо было договориться с руководством. Мне нужно было доказать, что обучение аналитиков не станет дополнительной нагрузкой для всех, а, наоборот, поможет бизнесу быстрее выпускать обновления или добавлять небольшие новые фичи.
Я собрал статистику: какие задачи выполняю, сколько времени на них уходит и сколько из них можно было бы делегировать. Посчитал, как это сократит Time-to-Market, и выступил перед бизнесом с небольшой презентацией. Ключевым аргументом стало не просто высвобождение меня из плена мелких рутинных задач, а ускорение работы всей команды. Делиться цифрами «ускорения» здесь особо не имеет смысла — все ситуации индивидуальны: для кого-то ускорение на 1 % — это 1 трудодень, а для кого-то — 1000. Главное, если решите повторить мой опыт, для вас эти цифры должны быть значительны.
Руководство дало зелёный свет, но с условием: обучение должно быть хорошо продумано, а качество макетов от аналитиков не должно ухудшить пользовательский опыт.

Обучение в боевых условиях
Я начал с простого — создал урезанную версию общебанковской дизайн-системы, включив туда только основные компоненты, которые используются в наших продуктах. Разработал гайды, записал вводные видеоинструкции и подготовил некоторые шаблоны.
Чтобы заинтересовать коллег, я подготовил примеры на основе их собственных макетов, которые они ранее передавали разработчикам для подготовки документации. Мы обсудили, как они создают эти макеты, я выслушал жалобы на неудобства и трудности, возникающие при частых правках.
Затем показал, как быстро и эффективно можно собрать аналогичный макет с использованием ДС. Продемонстрировал, насколько легко создавать разные состояния макета, используя готовые компоненты из ДС.
В рассказе о командной работе описал, что комментировать макеты в режиме реального времени и одновременно работать над одним файлом могут несколько человек. Это помогает избежать лишних этапов утверждения, значительно ускоряя процесс.
Одним из ключевых аргументов стала демонстрация компонентов дизайн-системы (ДС). Было подчёркнуто, что компоненты уже содержат множество предустановленных состояний. Это значит, что для получения нужного результата достаточно просто настроить свойства компонента.
Тренировка на пилотной группе аналитиков помогла мне понять, что у аналитиков есть потребность в систематизации навыков по созданию макетов. А я получил дополнительное подтверждение, что иду по верному пути.
Затем стартовали полноценные занятия — пять вебинаров по два часа: теория, практика и разбор ошибок. В курс были включены только базовые навыки, которые потребуются для работы аналитиков: горячие клавиши, автолэйауты, подключение библиотек, принципы работы с компонентами.

Кратко поделюсь программой и основными принципами обучения. Возможно, будет полезно, если вы также решите организовать подобный курс.
Урок 1. Интерфейс и инструменты
Здесь основной акцент на:
-
горячих клавишах, ускоряющих работу (масштабирование холста, выделение объектов и т. д.);
-
массовых операциях (переименование слоёв, выбор одинаковых объектов, редактирование текста);
-
возможностях, упрощающих создание макетов (autolayouts, привязки и т. д.).
Недизайнерам нет необходимости строить объекты или создавать маскированные области при ретушировании фотографии. Информация о принципах работы с кривыми и инструментах, которые не пригодятся в работе, излишняя.
Урок 2. Подключение библиотек и создание стилей
Создание собственных библиотек позволяет переиспользовать стили текста и цвета. На этом уроке участники изучили:
-
создание стилей и переменных для цветов, эффектов и текста;
-
подключение библиотек к рабочим файлам.
Урок 3. Группы, фреймы, привязки, autolayouts
Это довольно сложный материал для восприятия — без достаточного опыта работы с графическими редакторами тяжело воспринимать все эти привязки, размеры фреймов и т. д.
Но чтобы упростить понимание, можно наглядно показать, как изменения в свойствах и размерах фреймов или autolayout’ов влияют на контент. Я демонстрировал эти понятия на таблицах, где наглядно видно, как легко менять размеры столбцов.
Урок 4. Строение компонентов и их применение
Ключевой урок, так как на нём участники увидели «волшебство» работы с компонентами из дизайн-системы.
Пилотная группа получила задание создать макеты, демонстрирующие заполнение форм, успешное выполнение действий, ошибки и другие состояния. Цель задания — показать, как можно настроить компоненты под различные сценарии и упростить процесс разработки.
Урок 5. Создание компонентов и работа с таблицами
К этому моменту мои коллеги уже умели создавать простые макеты и даже адаптировать их под несколько брейкпоинтов. На этом уроке мы перешли к созданию собственных компонентов и формированию таблиц.
Домашнее задание включало создание полноценной таблицы, её заполнение данными, а также внесение изменений: добавление и удаление столбцов, замена содержимого на другой тип.
Развязка: новый уровень работы команды
Пилотная группа из аналитиков после каждого вебинара выполняла домашние задания, и я проверял каждую работу.
В какой-то момент я увидел, как аналитики начали не просто механически повторять действия, а осознавать суть. Они задавали вопросы, предлагали свои идеи по компоновке интерфейсов! Это был тот момент, когда я понял — эксперимент удался.
Спустя три месяца аналитики начали сами вносить правки в интерфейсы. Да, поначалу они просили поддержки, но вскоре всё больше задач стало выполняться без моего участия. Мы запустили процесс дизайн-ревью: аналитики выкладывали макеты в Confluence, а я их проверял, комментировал и апрувил.

Самое главное — аналитики начали мыслить, как дизайнеры. Исчезли запросы на нестандартные, несогласованные решения, которые раньше ломали систему. Теперь аналитики не просто делали макеты, они понимали основные принципы и работали в рамках дизайн-системы.
Этот опыт показал, что иногда решение проблемы лежит не в поиске новых ресурсов, а в более грамотном распределении уже имеющихся. Дизайн перестал быть узким горлышком процесса, а аналитики получили новый ценный навык. А главное — продукт стал лучше.
И если вы сталкиваетесь с похожей ситуацией, возможно, этот путь сработает и для вас.
ссылка на оригинал статьи https://habr.com/ru/articles/889014/
Добавить комментарий