Как организовать свидание между UI/UX дизайнером и Front-end разработчиком, и зачем нужны эти отношения

Эта статья — совместное творчество двух UI/UX дизайнеров, Ольги Барковой и Елизаветы Стороженко из Cadabra Studio, которые хотят помочь упростить коммуникацию между дизайнерами и разработчиками.

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

Все началось с проблемы

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

Недавно Лиза провела вебинар для команды разработчиков, которые занимаются проектом со стороны нашего клиента. Цель вебинара была объяснить, как использовать инструмент Zeplin. Это десктопное приложение, которое помогает UI/UX дизайнерам и front-end разработчикам эффективно работать в команде, экономя время друг друга. Программа обрабатывает файл с дизайном и генерирует руководство по стилю, исходники и спецификации, которые необходимы при верстке. Это один из инструментов, который мы используем для некоторых проектов. Помимо этого, мы создаем проекты в Figma.

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

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

​​В связи с этим, во время вебинара по использованию Zeplin разработчики узнали:

  • как читать теги;
  • как пользоваться сортировкой;
  • как искать описание секций;
  • как пользоваться поиском экранов и находить историю изменений;
  • как пользоваться генерацией кода;
  • как работать с пропорциями.

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

Как эту проблему видят сами дизайнеры

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

Коммуникация

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

Соответственно, я ожидаю и обратного, что если у разработчика есть какие-то вопросы или сомнения в реализации дизайна — он придет ко мне и мы вместе решим, нарисуем дополнительные состояния или выберем подходящее решение для возникшего кейса. Каждый разработчик должен понимать, что до его этапа дизайнер уже проделал работу и, возможно, решения чем-либо обусловлены (после ресерча, диалога с клиентом, опытом и исследованиями и т.д.). Поэтому крайне важно уметь качественно и адекватно говорить, задавать вопросы и быть на одной волне, понимая, что у вас одна цель — сделать хороший продукт.

Халтурность

Хорошая работа дизайнера заключается в правильном оформлении и подготовке макета — все компоненты имеют варианты с состояниями, выравнивание, заложенное поведение внутри компонента (или описанное отдельно поведение), стили текста и цвета. Хорошая работа не должна иметь 25 оттенков серого в цвете текста. Аналогично поступает и фронтенд-разработчик. Он также создает компоненты, стили и закладывает состояния. При этом он должен следовать созданному дизайну или запросить дополнительные моменты. Халтурный разработчик делает «на глаз», и это первый признак его некомпетентности. Нельзя делать, как тебе кажется лучше. Абсолютно все современные инструменты позволяют посмотреть отступы, конкретные стили цвета и т.д. Клиент уже заплатил много денег за качественную работу, он ожидает увидеть то же, что и в дизайне. Надо помнить, что мы тут не фрилансеры, а лицо компании.

Равнодушие

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

Как отсутствие коммуникации влияет на реализацию проекта

Пример 1

Мы (дизайнеры) создали слайдеры для фильтрации рейсов в зависимости от времени вылета/прилета и стоимости с отображением числа результатов. Тип слайдера только один для разных ситуаций, также есть диапазон числовой.

Что сделали разработчики:

  1. Вместо того, чтобы группировать результаты группами, они решили отображать все число результатов на слайдере, меняя ширину столбиков. Это неправильно с точки зрения UX, поскольку сложно увидеть эти столбцы.
  2. Также разработчики потеряли знак тире, который помогал понять юзеру, что поля являются диапазоном.
  3. На сером фоне они сделали поля ввода не с белым фоном, а прозрачным, что нарушило контрастность чтения текста и может привести к судебным тяжбам из-за проблем с доступностью на сайте.
  4. Некоторые моменты в дизайне (как, например, толщина линии слайдера или формат времени) тоже отличаются от задуманной дизайнером.

Пример 2

Дизайн: Размер формы был ограничен, но поля были не меньше по ширине, чем минимальные значения, в выборе пола был дефолтный.

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

Пример 3

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

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

Пример 4

Дизайн: все составляющие кнопок выровнены по центру кнопки, по высоте и ширине.

Разработка: текст смещен вниз по высоте, иконка поехала вниз и отступ не соответствует дизайну, иконка лоадера уехала вверх.

Пример 5

Дизайн: в мобильной версии календарь открывается модальным окном на весь экран.

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

5 шагов навстречу друг другу

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

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

Когда дело доходит до разработки и дизайна, у каждой компании разные организационные структуры. У более крупных брендов могут быть два отдельных отдела, и внутри этих двух групп могут быть более сложные команды (например, команда фронтенд-разработчиков и команда бэкенд-разработчиков). В то же время в более мелких компаниях дизайнеры и разработчики могут работать в тандеме в одном отделе, разделяя смежные задачи. Или же, как было в нашем случае, разработчики вообще могут быть частью другой компании. Какова бы ни была структура отделов, чтобы добиться наилучшего результата с точки зрения реализации дизайна, обе команды должны регулярно сотрудничать, и вот несколько идей о том, как это сделать.

Шаг 1 — Достигнуть взаимопонимания

Вы когда-нибудь заходили в комнату с другом и обнаруживали, что полностью пропустили мимо внимания какой-то предмет в комнате, в то время как ваш друг сразу заметил этот объект? В целом люди смотрят на вещи иначе, исходя из их личных вкусов, предпочтений или прошлого опыта. Дизайнеры и разработчики также часто видят вещи по-разному в результате их собственных навыков, талантов и сильных сторон. Уже по одной этой причине самое важное правило, которому необходимо следовать при работе над дизайнерским проектом, — это держать дверь для общения постоянно открытой.

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

Шаг 2 — Вовлечение в звонки и обсуждения

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

Шаг 3 — Продлить конфетно-букетный период как можно дольше

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

Шаг 4 — Изучите фишечки друг друга

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

Хотя дизайнеру не нужно быть полным экспертом в PHP или CSS, постарайтесь узнать о них как можно больше. Существует множество ресурсов для самообучения, доступных как в Интернете, так и в автономном режиме, например, те же курсы, которые помогут вам быстрее разобраться.

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

Шаг 5 — Поддерживайте друг друга до конца

Каждый раз, когда вы работаете с разработчиком, и он возвращается к вам, говоря, что что-то невозможно реализовать, учитывая ограничения проекта или определенной платформы, попросите его объяснить причины этого конкретного препятствия. Это связано с приведенной выше идеей расширения ваших знаний о разработке. Как только они объяснят, почему что-то не работает, вы можете извлечь из этого уроки, использовать эти знания, чтобы ограничить свои будущие ошибки и не сбиться с пути в продвижении проектов и задач.

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

Вывод

Создание невероятного UI/UX для пользователей требует огромного количества навыков и тяжелой работы. Когда разработчики и дизайнеры работают вместе над выполнением своих проектов, положительные результаты того стоят.

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

Случалось ли у вас подобное недопонимание? Чем это было вызвано? Делитесь в комментариях своим мнением! Для нас это важно.

👍НравитсяПонравилось2
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Тут просто верстальщик говно был :)

Я так и не понял, помогли ли рекомендации в итоге? Указанные расхождения в дизайне и разработке могут быть некомпетентностью с обоих сторон. Я видел дизайнеров, как будто они художники, размеры в Фигме взяты с потолка, разбивка не компоненты и переиспользуемые блоки хаотична или очень далека от вёрстки, нет общего стиля и т.д. Есть базовый чек лист обсуждаемый вначале — выбор единиц измерения, тип адаптивного дизайна, набор разрешений, как читать фигму и т.д. Далее многие состояния/действия/переходы не очевидны, возможностей фигмы недостаточно чтобы это показать(есть другие инструменты типа Flinto), поэтому важно словесно описывать дизайн в Джире задаче, прописывая дизайн таким образом помогаешь разработчику и выявляешь не стыковки в бизнес логике и дизайне

Рекомедации помогли) после проведенного вебинара для верстальщиков дизайн был исправлен. Мы согласны с Вами. Все задачи должны быть описаны в Джире или другом таск менеджере. Но поскольку в данном кейсе команда дизайнеров и разработчиков работали в разных компаниях, коммуникация была построена не сразу и оказалось, что верстальщики не до конца были знакомы с инструментом (Zeplin).

Частые проблемы и недопонимания бывают из-за того, что дизайнеры не шарят в принципах работы вэба в целом, нарисуют что-то «невероятное», а когда заказчик увидит эстимейты на реализацию всех этих хотелок, то начинается процесс упрощения или сами разработчики идут наиболее простым путем, чтоб уложиться в эстимейты.
Иногда разработчики делают так, как считают лучше потому что в дизайне 100500 размеров шрифтов и отступов которые не имеют никакой закономерности и логики 😄 не обобщаю, но такое бывает.
Если с обоих сторон все профессионально, то основная проблема бывает в представлении как должна работать анимация и транзишены, так как дизайн зачастую это статика и разработчик уже сам додумывает как это все должно работать.
Так же часто «невероятный UI/UX» идёт вразрез c производительностью и быстродействию работы сайта.

Согласны! Именно для этого мы и делились личным опытом, как наладить коммуникацию, чтобы сразу было понятно, что технически возможно реализовать. Но, когда команды работают в разных компаниях, это не всегда бывает просто)

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

группировать результаты группами

не ну с такими формулировками понятно почему фронтенд вас не понял)

Создание невероятного UI/UX для пользователей требует огромного количества навыков и тяжелой работы

я правильно понял, что невероятный — это зачеркивать ссылки при наведении, как у вас на сайте?
вообще, достаточно закидать фронтендера за сто баксов тикетами на каждую из «ошибок» и в дальнейшем они не должны наступать на те же грабли

Цікаво, чому у вас саме чоловік- разработчік, а дизайнером є жінка?

это ж стараю украинская традиция ещё со времён козачества

Поставте дизайнерам гіт та спілкуйтеся з девелоперами на етапі перших пулл реквестів, вже краще справа буде

Cadabra Studio

+бла-бла-бла+

Создание невероятного UI/UX

= джинса.

Какой-такой невероятный UX? "Невероятный"— это плохой. А хороший — тривиальный, предсказуемый, быстрый.

Ради интереса зашёл к ним на сайт. Если пропустистить мат, то ничего. Потому что это ******** **** ********* *************** ********** ********* **** ********* ********* ********************ный *******ц!

Например: меню, когда наводишь мышь, не подчёркивается, а перечёркивается. Советую зайти, там прекрасно всё.

Ниже где «RVOS Insurance App» — вообще на :hover не реагирует -_-

А Back-end как всегда забыли
Итого дезигнеры что-то от балды нарисовали, менеджмент подписал, фронтенд согласился, а бэкенд повесился от нереалистичных хотелок

Бери выше, бэкенд сказал: «ну вы сами этого хотели», и реализовал всё в точности так, как просили. И что ещё важнее — ровно в те сроки, которые просили, уложился в дедлайн,... и свалил на другой проект. А это менять, потому что «а мы имели в виду другое» — ищите дураков. Потому что когда вас спрашивали до реализации — вы сказали, «всё написано в ТЗ, меняться ничего не будет, ибо согласовано, работайте».

UIUXdating.com пора вам таки робити стартап, а то домейн ще вільний: ua.godaddy.com/...​ainToCheck=UIUXdating.com
го-го-го а то хтось таки ідею вкраде

не думаю що щось пропустив, бо ваша стаття точка зору однієї сторони і розуміння аля все робити групами та великим скоупом показує лише те що розуміння архітектури і реюзабл компонентів для цієї сторони це якась магія, а отже статтю можна не читати, хватає тільки заголовку, аналогічно як ресурс на подобі «лєнта.ру» та інших жовтропресів. Отож задумайтесь на рахунок ресурсу бо він ще вільний )

Эх, думала статья про тиндер, где с одной стороны дизайнеры, а с другой — девелоперы)

Эта статья — совместное творчество двух UI/UX дизайнеров, Ольги Барковой и Елизаветы Стороженко из Cadabra Studio

но уже с первых слов стало понятно, что либо речь пойдет о ЛГБТ либо нас еще как-то обманут(

Подписаться на комментарии