Дизайн на аутсорс-проектах: пилим внутренние процессы под решение задач клиента

Мы разрулили хаос в дизайн-процессах, чтобы максимальное время посвящать продукту и заказчику. Рассказываем (и показываем) наши лучшие практики.

Привет! Меня зовут Алина, я дизайн лид в диджитал-продакшн ФОДЖИН. Сегодня хочу рассказать про процессы, которые помогли нам не множить папку с дизайн-долгом и делать продукт, который выглядит и работает как задумывали.

Мы разрабатываем, проектируем, исследуем, дизайним, или коротко – создаем диджитал-продукты для людей. Мы уже давно стаффим наших спецов как на международные, так и на крупнейшие проекты в России. Заняли 25 место в рейтинге аутстаф-разработчиков России (2023) по версии Tagline, а сейчас активно вкладываемся в направление заказной разработки.

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

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

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

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

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

Решением послужила унификация структуры и процессов работы с файлом на всех аутсорс-продуктах.

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

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

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

Эти шаблоны обеспечивают удобный и функциональный «минимум» и помогают за очень краткий срок настроить комфортную для всех среду работы над продуктом.

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

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

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

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

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

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

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

А если вам нужны дизайн и разработка, то пишите нам)

А у вас были подобные кейсы? Как вы их решили? Расскажите в комментах, интересно же!