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

Привет! Я Лена Плинер, ux/ui дизайнер интерфейсов. Работаю как приглашенный попроектный дизайнер. Сотрудничаю с заказчиками и командами разработчиков. Запускаю MVP, пересобираю и улучшаю уже существующие проекты.

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

В зависимости от схемы работы по проекту и от планов клиента передача макета разработчикам проходит по-разному.

Поэтапная передача

Я могу передавать макет частями, сценариями. Разработчики быстрее начнут свою часть работы, постепенно погружаясь в проект. При такой постепенной передаче можно быстро и безболезненно вносить нужные изменения и быстрее внедрить их на следующих этапах дизайна. Какие могут быть изменения? Какими угодно. Это зависит от технических возможностей, ограничений, новых идей. Дизайнер сделал какую-то фичу, но у разработчиков появились технические ограничения. Дизайнер может предложить другое решение этой фичи. Или у разработчиков появилась идея и дизайнер может быстро ее реализовать.

Передача готового проекта целиком

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

Полная единовременная передача бывает, когда я делаю макет и отдаю его клиентам, у которых пока нет команды разработки.

Я передаю дизайн в Figma, в котором макеты, отмеченные статусами.

Какие бывают статусы

“In progress”. Макеты, над которыми мы работаем. Их пока не комментируют и не берут в разработку.

«Approve”. Макеты, которые мы обсуждаем с заказчиком и его командой. Тут может быть много комментариев. Эти макеты могут отправиться обратно “In progress” или »Dev”.

“Dev”. Эти макеты согласованы, готовы и их забирают разработчики

Еще может быть статус “Future”. Часто используется при MVP проектах для обозначения идей, которые уже реализованы в дизайне, но в разработку отправятся еще не скоро, а может быть и никогда.

Pages содержит название раздела или сценария и имеет свой статус из вышеперечисленных. Например, сценарий покупки (Dev), раздел каталог (Approve) и так далее. Личный кабинет, например, может делиться на разделы — профиль, баланс и так далее и каждый размещается на отдельном pages и имеет свой статус.

Это не обязательные названия статусов и они могут меняться. Самое важное тут — понимание стадии готовности макета всеми участниками команды. Обычно на старте договариваемся какие статусы будем использовать.

Например, сейчас я начинаю новый проект, знакомлюсь с командой и задачами. Это уже существующий проект и есть Figma c макетами. В команде принято отмечать статусы, размещая макеты на полосках разного цвета. Я не против, это не вызывает сложности.

Краткая, но очень важная часть.

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

Что такое спецификация?

Сопровождающая документация для разработчиков, в которой описываются как работает функционал, что происходит в тот или иной момент. Например, “хинт появляется при наведении курсора на элемент с задержкой 400 миллисекунд” и так далее. Полностью описание элементов в различных состояниях, размеры областей, поведение при разном количестве контента и в разных ситуациях.

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

Я не вижу смысла в перелинковке простых сценариев, они не вызывают вопросов у разработчиков. Для сложных сценарии показываю с помощью прототипирования в Figma, либо показываю схему user-flow, в которой видны все переходы

Делаю ее отдельным файлом. В ней содержатся все компоненты, стили, цвета, шрифты, брендинг.

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

Будут вопросы. Как правило, бывают и это нормально. Могут быть сразу, если в разработку макеты уходят прямо сейчас или потом, если команда приступит к макетам позже (это может быть даже через 6 месяцев). Или команда разработчиков может поменяться, не получив контакты дизайнера. Хороший тон — оставить свои контакты.

Про ревью, пожалуй, напишу отдельную тему, процесс этого достин

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

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

Буду рада увидеть мнения разработчиков)

Спасибо за внимание!

Обо мне, моей работе, проектах и о том, что мне интересно в моем телеграм-канале Дизайнер на всю голову.