Всем привет, меня зовут Илья Аллендорф, я занимаюсь дизайном внутреннего продукта в X5 Tech. В статье расскажу, как я улучшил подготовку макетов для разработки и навёл порядок в рабочем проекте в Figma.

В 2023 году я пришёл в новый продукт, который разрабатывался с нуля. За два года мы запустили MVP, перевели бизнес-процесс в продукт, достигли целевых метрик, а ещё совершили ошибки и сделали ценные выводы. Кроме того, мы ускорили сycle time, улучшив взаимодействие с дизайном: навели порядок в Figma, договорились с аналитиками, упростили жизнь разработке и уменьшили этап дизайн-ревью.

Теперь обо всём по порядку.

Предпосылки

У меня было несколько причин для пересмотра дизайн-процесса: 

Документация дизайна

В Figma отсутствовало детальное описание дизайна или же оно отличалось от финальной userstory, что приводило к неверной реализации.

Не было порядка в Figma

Во время рабочего процесса легко забыть об оформлении задач, свалив всё в одну кучу. Из-за этого Figma становилась громоздкой, неудобной и тормозящей. Кроме того, разработке не хватало дизайн-документации.

Объёмное дизайн-ревью

При проверке реализации выявлялось множество ошибок и несоответствий. Фронтенд-разработчики упускали часть дизайна: они задавали много вопросов или самостоятельно додумывали реализацию.

Опрос

Чтобы выяснить ключевые проблемы разработки при взаимодействии с Figma, я провёл опрос среди 22 фронтенд-разработчиков из разных команд и узнал об их опыте:

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

Шаг 1: осознанное проектирование

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

1. Обсуждать и фиксировать договорённости с аналитикой на этапе discovery. Это может избежать расхождения драфта user story и решения в Figma.

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

3. Согласовывать с командой финальное решение.

4. Договориться о том, когда нужно описывать финальную версию userstory по задаче для соответствия финальному дизайну.

5. Сообщать аналитику о любых изменениях в дизайне.

Шаг 2: ограничения разработки

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

1. Возможности системы. Можно ли сделать автосохранение?

2. Скорость разработки. Насколько сложной будет реализация автосохранения?

3. Ошибки, валидации, поведение. Какие могут быть проверки и ошибки при автосохранении?

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

Шаг 3: как оформлять проект в Figma

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

1. Оформить структуру проекта, разделив его на файлы: Sandbox (рабочий файл), Master (чистовик), UI library (компоненты), исследования и т. д.

2. Разделить файлы на страницы с понятными названиями разделов, страниц и задач. Последние можно именовать названиями и номерами из системы управления задачами.

3. Оформлять задачи в виде секций: макет, карточки документации, компоненты и состояния.

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

Шаг 4: как оформлять задачи в Figma

Во время дизайна полезно описывать ваше решение текстом: как работает интерфейс и компоненты, когда появляется валидация, ошибки и т. д. Это будет полезно как вам — вы сможете перечитывать и проверять решение, так и команде — аналитики смогут писать пользовательские стори и технические спецификации, опираясь на наглядные макеты с дизайн-документацией. Разработке также будет удобно смотреть в одном месте всё, что касается сборки дизайна и функционала.

Рекомендации по сборке и оформлению дизайна:

1. Собирайте макеты, используя auto layout, — так отступы и размеры будут заданы похожим на вёрстку способом, а разработчику будет легко повторить это в коде.

2. Используйте дизайн-систему, создавайте локальные компоненты и варианты для каждого возможного состояния — default, hover, pressed, disabled, error, loading, empty state и т. д.

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

4. В сложных решениях стоит сделать прототип для демонстрации и приложить ссылку в карточку документации.

Шаг 5: дизайн-ревью

Хотя и предыдущие действия направлены на уменьшение ошибок при разработке, этот этап по-прежнему нужен. Для проведения ревью необходимо:

1. Договориться о внедрении дизайн-ревью как об обязательной части процесса разработки. Вы можете добавить колонку в системе управления задач как обязательный этап.

2. Проверить реализацию удобным для вас и разработчика способом. В моём случае достаточно скриншотов интерфейса и комментариев в Figma. Фронтенд-разработчик пишет в комментариях, а я проверяю исправления.

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

Также не отбирайте хлеб у тестировщиков: разделите области ответственности и проверяйте только то, что касается дизайна.

Заключение

Наведение порядка в Figma — это не только про организацию файлов, но и про упрощение работы всей команды. Всё, о чём я рассказал, основано на моём опыте: эти шаги помогли снизить количество ошибок, ускорить процесс разработки и улучшить взаимодействие внутри команды. Чёткая структура, оформление задач и тесное сотрудничество с аналитиками и разработчиками действительно делают дизайн-процесс проще.  

А чтобы ничего не упустить, я подготовил для вас чек-лист:

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

Почитать больше про системный подход к дизайну в X5 Tech:

• Статья Стаса про корпоративный шрифт: «Создание собственного корпоративного шрифта. Зачем он нужен и какой путь мы прошли»

• Статья Георгия о цветах: «33 оттенка зелёного. Как мы проектировали темизированные палитры для внутренних интерфейсов Х5»

• Стандарт по текстам от Саши: «Синергия дизайнеров и техписов: создание единых стандартов Tone of voice»

• Стандарт по дизайн-подходу от Ильи: «Единый стандарт дизайн-подхода в X5 Teсh»

• Про рефакторинг дизайн-системы от Дениса: «Метём метлой. Рефакторим дизайн-систему, чтобы верстать макеты без боли»