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

Усі статті, обговорення, новини про 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 для пользователей требует огромного количества навыков и тяжелой работы. Когда разработчики и дизайнеры работают вместе над выполнением своих проектов, положительные результаты того стоят.

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

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