Мы разрулили хаос в дизайн-процессах, чтобы максимальное время посвящать продукту и заказчику. Рассказываем (и показываем) наши лучшие практики.
Привет! Меня зовут Алина, я дизайн лид в диджитал-продакшн ФОДЖИН. Сегодня хочу рассказать про процессы, которые помогли нам не множить папку с дизайн-долгом и делать продукт, который выглядит и работает как задумывали.
Немного о нас
Мы разрабатываем, проектируем, исследуем, дизайним, или коротко – создаем диджитал-продукты для людей. Мы уже давно стаффим наших спецов как на международные, так и на крупнейшие проекты в России. Заняли 25 место в рейтинге аутстаф-разработчиков России (2023) по версии Tagline, а сейчас активно вкладываемся в направление заказной разработки.
С чем столкнулись
Долгое время мы работали на аутстаффе, и когда к нам в руки попал первый аутсорс, пришлось на скорую руку оформлять все процессы. Сначала получилось не очень круто, в ходе работы мы неоднократно сталкивались с различными проблемами. Например, на проекте часто менялись разрабы и дизайнеры, и им приходилось тратить много времени на то, чтобы понять происходящее и полноценно вкатиться в проект.
Спустя примерно полгода такой движухи мы поняли, что это не ок и нам нужно менять подход. Решили не изобреть велосипед, а сделали аутстафф нашим преимуществом: проанализировали опыт других компаний, собрали лучшие практики и создали свои процессы на их основе. Погнали смотреть, что у нас вышло!
Оптимизировали структуру файла
Вернемся к проблеме, упомянутой выше – замена сотрудников. Это происходило потому, что изначально аутстафф был у нас в приоритете и в случае появления нового контракта мы отдавали специалиста туда. На смену приходил горячий, свежий спец с только что законченного аутстафф-проекта.
В чем минус? В том, что ребята приходили со своим взглядом на ведение файла и документации и поэтому долго вкатывались. Мы тратили много времени на объяснение договоренностей о работе со страницами, а не на то, чтобы реально копать вглубь в задачу клиента.
Еще периодически были непонятки с движением макетов по страницам: клиенту на ревью улетала копия, и дизайнеры путались с фиксом правок, кто-то фиксил на деве, кто-то на ревью.
Решением послужила унификация структуры и процессов работы с файлом на всех аутсорс-продуктах.
Имея четкую структуру и процесс продвижения по ней макета, мы перестали плодить ненужные страницы, и стали экономить лишнее время, которое особенно ценно на первых этапах работы над продуктом.
Сделали шаблоны для оформления компонентов и стилей
UI Kit необходим для единообразия элементов интерфейса, он помогает скоординировать дизов и разработчиков. В процессе работы над ним мы обычно закладывали в эстимейт не только его создание, но и визуальное оформление, которое делали каждый раз почти с нуля и стилизованным под проект, с фирменным шрифтом, цветом и айдентикой.
Спустя какое-то время мы поняли, что это тратит много лишнего времени, и чтобы это фиксануть – сделали «нейтральные шаблоны», которые теперь просто копипастим. Они подходят под большинство проектов и уже имеют все нужные настройки. Согласовали с разрабами список нужных атрибутов для кита, что позволило нам довести до автоматизма его передачу в дев.
Эти шаблоны обеспечивают удобный и функциональный «минимум» и помогают за очень краткий срок настроить комфортную для всех среду работы над продуктом.
Заменили комментарии на карточки
При создании дизайна мы не только разрабатываем прототип, но также описываем анимацию и прочие важные вещи в комментариях – это позволяет разработке и клиенту понимать, как работает макет. Долгое время мы по привычке использовали дефолтные комментарии в Фигме – но в какой-то момент поняли, что это не совсем удобно. Они открываются по одному, и при просмотре ты просто забываешь, что было пару комментариев назад. Это сильно влияет на общее считывание картинки.
Поэтому мы заменили обычные комменты на карточки, в которых описываем ограничения и поведение элементов. Они позволяют оценить логику сразу у всей страницы.
Внедрили процесс тестирования верстки дизайнером
Фигма дает некоторые погрешности при просмотре сайта в режиме прототипа: даже если он кликабельный и анимированный, это все равно не то же самое, что тестировать отзывчивость реального продукта.
Есть вещи, которые видит только дизайнер, поэтому мы ввели процесс тестирования верстки дизом. Вначале QA проверяют логику и пиксель перфект, а затем мы проверяем макет на реальных данных: финальную композицию, последовательность анимации, складывается ли это в общую картинку и выглядит ли это так, как было задумано изначально.
Для подобного рода тестирования мы составили свой чек-лист, который позволяет ничего не упустить при проверке. Этот процесс помог свести к минимуму возможность возникновения правок по дизайну в последний момент или после релиза.
Заключение
Эти процессы помогли нам уделять больше времени и ресурсов самому продукту, а не операционным задачам. Теперь к старту проекта у нас уже многое готово, что позволяет нам оперативно приступить к работе и думать, как улучшить продукт, а не как назвать документ.
Шаблоны, которые были упомянуты в статье, я выложу в нашей телеге про дизайн – там мы пишем про то, как у нас все устроено.
А если вам нужны дизайн и разработка, то пишите нам)
А у вас были подобные кейсы? Как вы их решили? Расскажите в комментах, интересно же!