Design + Frontend: советы для эффективного взаимодействия двух команд на одном проекте
Привет, я Настя, UI/UX дизайнер технологической компании CRT. Сегодня поговорим о том, как наладить эффективное взаимодействие между фронтенд и дизайн тим на одном проекте.
Думаю, многим знакома ситуация, когда внутри команды возникают недопонимания и разногласия – и в коммуникации, и в важных технических моментах. Это всегда замедляет процесс работы и осложняет достижение общей цели. В этой статье поделюсь решениями, которые постоянно применяю в работе с коллегами. Рекомендую их не только дизайнерам, а вообще всем, кто работает в коммерческой разработке. Ведь, как мы все понимаем, в нашем деле самое главное – создавать продукты, которыми можно гордиться. Остальное – рабочие моменты 🙂
Итак, разберём несколько типичных ситуаций между командами фронтенда и дизайна.
Ситуация 1. Разработчик видит макет только в момент приёмки и постановки задачи
Наиболее общая «боль» всех коммерческих проектов – в отсутствии диалога между фронтенд и дизайн командами в начале разработки продукта. Первые подключаются к проекту в моменте сдачи дизайн-макетов и не всегда понимают, что с ними делать. Вторые могут не знать определённых сложностей проекта или специфики технологий, на которых он будет реализован, и потому предлагают сложные или вовсе нереальные дизайн-решения.
Такие ситуации распространены, если команды разрозненны и работают каждая в своей зоне ответственности. Для продукта это означает настоящую катастрофу: сроки релиза будут переноситься из-за всплывающих проблем и доработок, клиент будет терять деньги, команда – погружаться в разногласия и негатив. Круто? Не очень. А главное – очень-очень затратно и муторно. Но как сделать, чтобы было нормально?
Хорошее решение: подключайте разработчиков к работе дизайнеров.
приглашайте разработчиков на дизайн-обсуждения. Полезно всем, потому что помогает подсветить «тонкие» места, которые стоит учесть в разработке макетов (напр. технические ограничения и возможности, влияние на производительность и доступность) и в логике дизайна. В итоге получаем правильный процесс разработки макетов, и (как бонус) уважительную коммуникацию внутри команды проекта 🙂
- просите разработчиков проводить ревью дизайн-макетов при получении. Это касается не только проверки «все ли экраны и состояния отрисованы», но и таких важных вопросов, как ясность логики макета, наличие / отсутствие необходимых комментариев и описаний от дизайнера, и вообще всего, что может затормозить процесс фронтенд-работ.
Такой подход (помимо всего перечисленного) обладает явным накопительным эффектом – вся команда учится работать вместе и минимизировать риски возникновения возможных проблем.
Ситуация 2. Изменения в дизайн вносятся без предварительного согласования с дизайнером
Если вы – дизайнер, скорее всего, у вас сейчас задёргался глаз. Потому что сейчас мы будем разбирать наиболее больную боль нашей профессии. Как это обычно происходит? Макеты переданы фронтенд-тим, и в ходе работы разработчики приходят к выводу, что некоторые элементы дизайна неэффективны или сложны в реализации. Если в команде не налажена коммуникация (читай 1 пункт), изменения вносятся без согласования с дизайнером, и он может обнаружить их только на моменте релиза.
Почему я не считаю такой подход корректным?
Во-первых, каждый специалист ответственен за свою предметную область. В процессе работы дизайнер глубоко погружается в контекст задачи, чтобы найти лучшее решение конкретной проблемы, которую поставил перед ним клиент. Благодаря развитой насмотренности он находит, зачастую, нестандартные решения.
Например, сложный дизайн, анимация и интерактивные элементы могут привлечь внимание пользователей, и сделать продукт более конкурентоспособным на рынке. А изображения плохого качества из-за чрезмерного сжатия, «дёргающаяся» и тормозящая анимация, наоборот, могут оттолкнуть пользователя и помешать достижению целей клиента.
У фронтенд-команды свои задачи и свои компетенции, а ещё своё понимание эффективности и неэффективности тех или иных дизайн-элементов. Если возникает вопрос «зачем дизайнер это придумал именно так?», значит нужно это обсудить. Хороший специалист всегда сможет объяснить своё решение, и предложить варианты его реализации.
Во-вторых, точечные несогласованные изменения в дизайне могут нарушить его целостность. Дело в том, что в процессе работы дизайнер учитывает общий стиль проекта, цели и требования пользователей, маркетинговые стратегии и многие другие факторы, в которые разработчик погружается далеко не всегда.
Изменения, не согласованные с дизайнером, могут привести к несоответствию интерфейса потребностям пользователей или бизнес-задачам. Здесь уже начинает страдать не только дизайнер, но и сам клиент. Это плохо, так не надо)
В-третьих, зачастую желание упростить дизайн или даже проигнорировать некоторые его аспекты обусловлено личными предпочтениями разработчика. А здесь мы приходим к такому известному всем понятию, как «вкусовщина». Она «ест» больше временных ресурсов, чем любые, самые крупные правки.
Хорошее решение: помнить, что все мы – профессионалы в своей области.
устанавливайте открытую коммуникацию между командами. Если проект делается под девизом «да что они там напридумывали опять» – это заведомо провальный проект. По своему опыту знаю, как упрощает все процессы простое человеческое «Привет! Возник вопрос по этому элементу. Давай созвон, обсудим?». 30 минут на митап – посильно. Взаимное уважение внутри команды – бесценно.
- согласовывайте любые изменения в дизайне с дизайнером. Это, как минимум, позволит сохранить целостность логики и дизайна, как максимум – понять, нужны ли эти изменения в принципе.
внимательно относитесь к деталям дизайна. Если разработчикам кажется, что без одной анимации продукт начнёт лучше работать – лучше уточнить, так ли это. Дизайнер точно пояснит, какое предназначение в неё закладывалось.
Ситуация 3. Ошибки дизайнера становятся поводом для разногласий
Этот кейс не про поиск решений, а про важный инсайт. За годы работы я поняла, что дизайн без косяков – это как код без багов: то, чего очень хочется, но практически нереально достичь 🙂 Все мы люди, и по разным причинам можем допускать ошибки в работе. Это не значит, что надо сразу идти и обвинять коллегу в некомпетентности. Помните, что вы работаете в команде над общей целью. И, если обнаружена проблема, ваша задача – найти решение, а не виновного.
Если говорить про ошибки дизайнеров, то все они делятся на 3 простых человеческих категории и зависят от опытности дизайнера вообще и его опыта на проекте в частности.
Отсутствие / недостаток опыта работы. В этом случае важно понять, простить и научить, как делать правильно. Если вы – начинающий дизайнер и попали в смешанную команду, где есть не только опытные коллеги-дизайнеры, но и фронтенд разработчики, считайте вам повезло. Налаживайте коммуникацию, подключайте их к ревью макетов и впитывайте инфу про все технологические нюансы переноса дизайна на прод. 100% вам это пригодится на будущих проектах. А для коллег-фронтеров тут только один совет – показывайте всем начинающим ребятам, как нужно в коммуникацию, ревью и этичный фидбек.
Новичок на проекте. Бывает, ошибки допускают и опытные дизайнеры. Чаще всего это происходит, когда они подключаются к новому проекту и не знают всей его специфики. В такие моменты могут появиться ошибки, связанные с неправильной логикой или созданием дизайн-элементов, клонирующих по функционалу имеющиеся. Здесь вам поможет UI-кит проекта, документация и (опять же) коммуникация внутри команды.
- Отсутствие навыков разработки. Дизайнер – это дизайнер, и он не должен разбираться в тонкостях разработки. Поэтому так важно взаимодействие с командой фронтенда, которая сможет в моменте спокойно объяснить, почему реализация чего-то невозможна, и посоветовать, как лучше сделать (а не просто отменить дизайн и по частям перенести только то, что переносится, без согласований).
А бывает так: то, что разработчик считает ошибкой – не ошибка вовсе) Самый мой любимый пример – это разные отступы в кнопках. Там, где есть иконка, и где её нет.
Ситуация 4. Разработчики думают, что дизайнер – лентяй
В идеальном мире с большими бюджетами и подробно расписанными ТЗ у дизайнера действительно бывает достаточно времени и ресурсов на то, чтобы отрисовать все состояния всех элементов, расписать документацию к ним и найти самое эффективное решение поставленных задач.
Но в реальности часто бывает наоборот:
Сжатые сроки, в рамках которых дизайнер отрисовывает самые важные элементы, а потом сталкивается с недовольством разработчиков от того, что в макете не показаны вообще все возможные состояния кнопки / поля / формы и т.д.
- ТЗ, ограничивающее функционал и количество отрисовываемых экранов, и, опять же, гнев разработчиков за то, что «потеряли» какую-то важную страницу или сделали несовременный топорный функционал.
Длительный этап согласования дизайна, в процессе которого итоговые решения могут быть далеки от того, что изначально рекомендовал дизайнер. А если разработка происходила параллельно с дизайном – это ещё и постоянные правки в код.
Хорошим решением для менеджеров проекта будет составление подробного описания задач, и ведение работ по методу Agile. Это поможет контролировать все процессы и точно спасёт от ситуаций, когда разработка начинается ДО того, как клиент утвердил дизайн.
Хорошим решением для дизайнеров и разработчиков будет проектирование упрощённых user flow или lo-fi прототипов, их обсуждение и совместное выявление логических несостыковок до этапа отрисовки дизайна. Это позволит сэкономить кучу времени на всех дальнейших этапах!
Вместо вывода
Проверено множеством проектов – эффективное взаимодействие между фронтенд-разработчиками и дизайнерами играет ключевую роль в создании успешных продуктов. Открытость к обсуждению, понимание ролей и целей проекта, а также уважение к коллегам помогут нам преодолеть любые трудности и достичь общих целей.
Надеюсь, статья получилась полезной и для коллег-дизайнеров, и для коллег-разработчиков! Если у вас есть истории из вашего опыта совместной проектной работы – напишите о них в комментариях 🙂