Привет! Я Владимир Белов — продуктовый дизайнер в Group-IB. Веду телеграм-канал «Заметки дизайнера» , где делюсь полезными ссылками, интересными продуктами для собственного анализа, статьями.
В этой статье хотел бы поделиться своей объективной оценкой, каким образом построить рабочий процесс с разработчиками. Часто дизайнеры любят накидать компоненты по разным страницам в Figma, не умеют правильно систематизировать и пояснять, что в принципе хотят. В итоге на стенде получаем не то, что мы ожидали. Поэтому я разберу и расскажу, каким образом настроить процесс с разработчиками так, чтобы вы были на одной волне.
Постарайтесь выключить интроверта и сконцентрируйтесь наладить контакты с разработчиками. Больше общайтесь, сходите в бар после работы.
Поймите раз и навсегда: каждый по-своему в «художник», и многие любят вставлять своё мнение, свои решения, в том числе разработчики в интерфейсах. Поэтому всегда внимательно слушаем, так как бывают полезные советы, возможно технические ограничения. Это одна из причин, почему надо чаще общаться с разработчиками. Включаем эмпатию, так как если мы будем думать “Я дизайнер, а не ты!!!”, то это как минимум не по-дизайнерски, и к этому прибавляется неуважение к коллеге и к своей работе.
Не все понимают отличия между этими терминами, но при этом без этого нельзя отдавать свои макеты: будь то сайт или интерфейс:
- UI-kit включает в себя базовый набор элементов, блоков и т.п.
- Guidelines больше включает принцип работы с интерфейсом: сетка, отступы, шрифты, цвета, иконки, темы, анимация и т.п.
- Дизайн-система включает в себя все это вместе + работа с компонентами и правильный нейминг, то есть токены. И все это закидывать в storybook, zeroheight.
Но имея что-то одно из этого, нет никаких гарантий, что ваш макет будет в точности, как вы его спроектировали. Читаю разные комментарии, что многие дизайнеры — лентяи, которые забывают показать элементарные состояния компонентов, либо в гайде прописать одни отступы, а в макетах использовать другие, аля ну случайно. “Умеете, ну могете”.
Начните перед проектированием собирать объем необходимых компонентов и строго использовать их в своих макетах, а не сбрасывать их. Пропишите свои базовые гайды. Скиньте это своему разработчику для изучения. Но лучше созвониться, пообщаться, обсудить и ответить на вопросы. Тем самым вы закрепите эту тему. И вероятность того, что пойдет все насмарку, становится маловероятна.
Просто запомните, что разработчики — системный народ. Они не будут искать в ваших макетах, страницах необходимое. Они берут и делают всё для разработки. Если не покажите, как вы хотите, то получается отступ не 32px, а 56px. Шрифт не 40px, а 24px.
Постарайтесь устраивать раз в неделю синхрон по вашим задачам: что у вас в планах, что вы сделали, а также показать прототип, где вы расскажите детально, что необходимо учитывать во время разработки. После этого разработчикам становится легче воспринимать ваш макет и самое главное понимать.
Не забывайте хвалить разработчиков за выполненную работу, реализовав ваши интерфейсы.
Одна из важных вещей: не стоит разработчикам писать в личку свои правки с легкой претензией. Не надо. Вы и разработчик — одна команда, цель которой является решить бизнес-задачу, поэтому после релиза на стенд, посмотрите внимательно то, что разработали. Создайте артбоард в фигме и начните описывать правки.
- Заголовок. Кратко пояснить, что неправильно. Например, “Неправильный стиль заголовка”
- Описание. Подробно и понятно объяснить пути решения. В нашем случае, “В макете используется 20px Roboto Light. В макете я использую H3 Roboto Bold 24px”
- Ссылка на гайд/дизайн-систему. ОБЯЗАТЕЛЬНО
- Прикладываю скрин как на макете и как на стенде. Для сравнения.
После этого, если вы отправите в личку pdf с правками, то реакция тут конечно зависит от каждого человека, но я считаю, что несовсем правильно кидать такие документы в личку, когда пользователь может просто забыть, да и веет легким неуважением.
Я всегда ставлю задачу: Trello/Jira, отмечаю, что это баг, описываю, что за задача, прикладываю файл. Кидаю на команду или прикрепляю к конкретному разработчику. Дальше идет процесс делегирования, построение и решение вашей задачи уже внутри команды разработчиков. Влезать своим «Ну че когда уже» тоже не надо, но отслеживать статус обязательно.
Загрузка...
