Как не бесить фронтендер-разработчика, если ты UX-дизайнер

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

Разработчику бывает больно

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

Если вы юиксер, можете поделиться в комментариях, знакомы ли вам ситуации:

• разработчик сделал по-другому, потому что ему кажется, что это плохой UX;
• макет и спецификация совершенны и полны информации, а после реализации кнопка не там, иконки нет, и вообще макет как будто не смотрели;
• каждое состояние подробно отрисовано, а 404 все равно не по макету;
• разработчик не обращает внимание на все 500 оттенков серого;
• подвинуть кнопку оказалось сложно, долго, невозможно;
• разработчик заверстал по-своему и предлагает поправить макет под верстку.

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

В поисках подхода к коллегам я наткнулась на книгу Маршалла Розенберга «Ненасильственное общение». Для меня главная мысль была такой: если человек проявляет агрессию, у него есть своя боль.

Так я пришла к идее взглянуть на коллег-разработчиков как на пользователей: у них есть свои боли, проблемы и сценарии использования результатов моего дизайнерского труда. Я решила воспринять это как UX-задачу: сделать так, чтобы мой продукт был полезен и нравился пользователям не только визуально, но и функционально.

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

API, макет и постановка противоречат друг другу

Боль разработчика

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

В худшем случае приходится разговаривать со всеми по очереди, и это превращается в бесконечную рекурсию. Немного лучше, когда все оперативно созваниваются и решают, кто и что делает дальше.

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

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

UX-решение

Дизайнер может научиться читать API и сразу учитывать его при проектировании — это не так сложно, как кажется. Если при проектировании сразу сопоставлять API и UX, все нестыковки всплывут до окончательного UI. Их можно сразу обсудить с командой, и тогда бэк и фронт заранее договорятся о наиболее выгодном формате. Проектировщик тоже в профите: не придется возвращаться к закрытой задаче и переделывать макет, когда он дойдет до реализации.

Именно фронтенд-разработчики научили меня читать API, и им было очень приятно: в их глазах я взяла на себя часть их забот. Сам факт моего интереса сильно улучшил наши коммуникации, мы оказались на одной волне.

В БД нет тестовых данных

Боль разработчика

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

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

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

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

UX-решение

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

Ничего не работает

Боль разработчика

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

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

Некоторые QA, с которыми я работала, были очень крутыми профи и сами разбирались в причинах бага, но они и API тестировали отдельно и заранее.

UX-решение

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

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

Разработчику приходится додумывать за дизайнером

Боль разработчика

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

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

UX-решение

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

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

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

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

Бэк присылает 400 Bad Request и непонятно, что не так

Боль разработчика

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

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

UX-решение

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

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

Накостылил 500 строк ради сдвига кнопки на 3px

Боль разработчика

500 строк кода ради сдвига кнопки — конечно, утрированный пример. И тем не менее разработчику порой приходится делать много телодвижений ради небольших визуальных изменений. Так происходит, потому что интерфейс — это не свободный рисунок, а целая система из кирпичиков, которые по-своему сложены, на которых завязана логика, переиспользуемая в других местах системы.

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

UX-решение

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

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

Чек-лист для дизайнера

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

Научиться читать API

Может возникнуть вопрос, а зачем вообще юиксеру уметь читать API. Это же что-то на бэкендерском. Или фронтедерском. Но мое мнение — умение это делать сильно упростит жизнь всем. Если юиксер понимает API, он сможет говорить с разработчиком на одном языке и не предлагать заведомо нерабочие варианты дизайна.

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

Позаботиться о тестовых данных

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

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

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

Привлекать QA и бэк к ревью макетов

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

По готовности макета обсудите его с тестировщиком и бэкендером. Договоритесь, какие ошибки и как будут обработаны в вашей системе. Убедитесь, что API и макет дружат и вместе решают реальную задачу.

Узнать, как работает веб

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

• загрузка и обновление страницы,
• https и websockets,
• сортировка, фильтрация, поиск: серверные и клиентские,
• пагинация: серверная и клиентская,
• что такое гриды и флексы, как верстаются таблицы.

Показать разработчику, если накостылил

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

Отметьте все спорные моменты в макете и обсудите их с разработчиком до того, как макет будет передан в реализацию. Возможно, коллега подскажет вам альтернативное решение. Но как минимум, он лучше оценит срок реализации и будет вам благодарен.

Наблюдайте за процессом

Наблюдайте за процессом разработки в своей команде: от появления идеи до ее реализации. Это интересно.

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

Вместо заключения: зачем это все дизайнеру

После моей первой статьи про сетевой стек в Linux в одном из Telegram-каналов появилось обсуждение. Админ не поверил тому, что я дизайнер. Принято считать, что мы люди творчества и очень далеки от любой техники.

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

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

Так что сейчас я редко представляюсь дизайнером, обычно я с гордостью говорю: «Я Наташа, проектировщик интерфейсов!».