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

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

Дизайнер и фронтенд-разработчик — не чужие друг другу люди. Они работают в соседних кабинетах, вместе ходят в курилку (по крайней мере, так было до повсеместной ковидной удалёнки). Оба делают части одного большого дела и общаются если и не постоянно, то регулярно. И всё же их языки во многом отличаются. Да и не только языки — сами образы мышления.

По заданию Хабра автор этого поста встретился с сотрудниками Промсвязьбанка, чтобы составить небольшой… Нет, не разговорник. Понимайник. Возможно, кому-то он поможет общаться с коллегами по ту сторону HTML более конструктивно, эффективно, а главное — приятно.

Временной разлом

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

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

В идеале все вопросы надо обсудить сразу, пока открыт временной разлом, объединяющий дизайнера и фронта. Но это не всегда возможно. Разработчик должен перенестись в будущее и заранее представить все проблемы, с которыми он может столкнуться. Нужна своя портативная машина времени, прямо в черепной коробке. А её, к сожалению, имплантируют не всем.

Решение — поддерживать связь. Пока идёт общение, временной разлом не затянется. Ну и отличная идея — все мутные моменты прояснять сразу же, а не копить на свой или чужой дедлайн.

Chaotic vs Lawful good

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

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

Есть ещё гриды в гридницах

Грид — очень распространённая абстракция в веб-дизайне, да и не только в веб. Но у дизайнеров и разработчиков гриды разные.

Грид дизайнера измеряется в пикселях. Грид разработчика — в процентах, в долях блока. У разработчика в голове — адаптивность, универсальность. У дизайнера — конкретная картинка. В результате нередко оказывается, что пиксель пёрфект не очень-то пёрфект.

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

Свобода творчества — это, безусловно, хорошо, но когда твоё творчество потом высекают в HTML/CSS — хорошо бы подумать о комфорте скульптора. Маленькие нюансы макета легко могут превратиться в большую проблему верстальщика.

Пиксель пёрфект континиус

Разработчики не умеют в пиксель пёрфект. Если их как следует не пинать.

По каким-то мистическим для дизайнера причинам, даже если в макете чётко указаны все размеры, отступы и прочее, разработчик имеет свойство эти указания интерпретировать… творчески. Или же — игнорировать вовсе.

Среди дизайнеров ходит шутка, что фронтендеры верстают по памяти. Сначала смотрят на макет, потом сворачивают окно и ставят таймер на 30 секунд. Полминуты прошло — отлично, вот теперь можно верстать.

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

Насколько нужен пиксель пёрфект в каждом конкретном случае — вопрос философский. Однако если нужен, то неплохой идеей может быть автоматизировать его контроль и встроить в воркфлоу. Взять gemini или что-то подобное — пусть разработчик не приходит к дизайнеру с проблемой, которую может найти и устранить самостоятельно. Чужое время стоит уважать.

Вупсень и Пупсень… в смысле, пэддинг и марджин

Ни один фронтендер в здравом уме не перепутает padding и margin. И не потому что на фартуках разное количество ягод, а потому что — ну совсем разные же вещи. Допустим, padding входит в box-sizing, а margin — нет. С помощью margin можно центрировать элемент, а с помощью padding — нет. Не говоря уже про margin collapse и другие нюансы, тьма их.

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

Конечно, требовать, чтобы дизайнер чётко следовал фронтендовой терминологии — избыточно и местами даже душно. С другой стороны… Это всего лишь пара слов с хорошо различимым значением. Действительно ли так трудно их выучить?

Буква Г — лоГика

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

Дизайнер методично прорисовывает каждое состояния элемента. Логика, стоящая за этими состояниями, для него вполне очевидна. Он отдаёт макет фронтендеру. Фронтендер смотрит — да, логика действительно очевидна. И немедленно имплементирует её. То, что очевидность у них разная, становится ясно сильно потом, когда уже закрылся временной разлом.

В ПСБ дизайнеры серьёзно озаботились этой проблемой, стали писать развёрнутые комментарии, рисовать стрелочки переходов: в общем-то, описывать почти на уровне столь любимой программистами Finite State Machine. Недопонимания сразу стало намного меньше. С другой стороны, дизайнер, который рисует FSM — это ведь уже почти программист?

Коля любит Мамбу, Оля любит Мамбу

Фронтендеры очень любят компоненты. Компонент — способ переиспользовать код, логику. Если логика не совсем подходит — не проблема, сделаем более общий компонент, будем от него наследоваться. Или используем какой-нибудь миксин…

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

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

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

Правило правой руки

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

Дизайнерам это правило также не чуждо. Они неплохо знают «меню» — то, что разработчики в принципе способны реализовать. В принципе, дизайновые инструменты вроде Figma и не позволяют выйти за рамки возможного. Делать макеты в каком-нибудь After Effects, по счастью, никто ещё не додумался.

С другой стороны, дизайнер не всегда может оценить две важные вещи:

1. какое количество труда уйдёт на вёрстку того или иного дизайна;

2. какое количество ресурсов он потребует от пользовательского устройства.

С опытом (в частности — с опытом взаимодействия с фронтендером, а ещё лучше — с пользователем) дизайнер начинает лучше понимать такие вещи. Появляется представление о том, сколько сто́ит та или иная графическая красивость. Но даже через десятки лет опыта это представление останется приблизительным.

Почему же дизайнер не может заранее рассчитать стоимость? Всё очень просто: её никто не может заранее рассчитать. В том числе — разработчики. И архитектурные сложности, и проблемы с производительностью зачастую выявляются постфактум. Внутричерепная машина времени у фронтендера несовершенна. И хотя велик соблазн свалить все косяки на дизайнера, который не знал чего хотел, нужно помнить, что жизнь — непредсказуемая штука.

Интроверты (не) против экстравертов

Разумеется, реальный фронтенд-разработчик в среднем очень далёк от стереотипного программиста-хиккана, какого любили (да и до сих пор любят) показывать в фильмах. Но стереотипы всегда несут в себе хоть какую-то долю истины. Для разработчика хард скиллы важнее софт скиллов. Это не значит, что последние вообще не важны, работать с Д’Артаньянами и докторами Хаусами мало кто захочет. И всё же в первую очередь важно умение писать код, делать продукт, а уже потом — коммуникабельность и сладкоречивость.

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

Казалось бы, неизбежно противостояние. Физики vs лирики, мужчины с Марса, женщины с Венеры… Но нет, противостояние очень даже избежно. Своими софт скиллами дизайнеры удачно дополняют разработчиков. Любое недопонимание, связанное с различием языков и майндсетов, можно преодолеть, и дизайнеры берут на себя значительную часть этого преодолевания. Нужно только не забывать, что у разных людей — разный набор коммуникативных компетенций, и относиться друг к другу с уважением.

Разговор важнее слов

Есть довольно много вещей, которые у дизайнеров и фронтендеров называются по-разному. Скажем, у дизайнеров интерлиньяж, а у фронтендеров — line-spacing. На фронте — letter-spacing, а у дизайнеров — кернинг. В идеале каждый специалист должен знать оба языка, говорить со «своими» на одном, а с «чужими» — на другом. Совсем в идеале — можно было бы выработать единый язык и заставить всех пользоваться только им.

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

Надеюсь, наш понимайник оказался полезен. А если вы фронтендер или дизайнер, обязательно напишите в комментариях, с какими коммуникативными трудностями сталкивались лично.