Вавилонское сайтотворение: как фронтендеры и дизайнеры понимают друг друга
Каждый из нас говорит на собственном языке. К счастью, иногда эти индивидуальные языки достаточно похожи, чтобы объединять их в большие группы. Всё, что внутри такой группы, мы условно считаем одним языком — например, русским.
Но порой неизбежно вылезают различия. «Гражданский брак» значит разное для юриста и не-юриста. Обыватель назовёт цифрой то, что математик — числом. Слово «крайний» имеет особое значение для лётчиков и парашютистов.
Дизайнер и фронтенд-разработчик — не чужие друг другу люди. Они работают в соседних кабинетах, вместе ходят в курилку (по крайней мере, так было до повсеместной ковидной удалёнки). Оба делают части одного большого дела и общаются если и не постоянно, то регулярно. И всё же их языки во многом отличаются. Да и не только языки — сами образы мышления.
По заданию Хабра автор этого поста встретился с сотрудниками Промсвязьбанка, чтобы составить небольшой… Нет, не разговорник. Понимайник. Возможно, кому-то он поможет общаться с коллегами по ту сторону 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, по счастью, никто ещё не додумался.
С другой стороны, дизайнер не всегда может оценить две важные вещи:
какое количество труда уйдёт на вёрстку того или иного дизайна;
какое количество ресурсов он потребует от пользовательского устройства.
С опытом (в частности — с опытом взаимодействия с фронтендером, а ещё лучше — с пользователем) дизайнер начинает лучше понимать такие вещи. Появляется представление о том, сколько сто́ит та или иная графическая красивость. Но даже через десятки лет опыта это представление останется приблизительным.
Почему же дизайнер не может заранее рассчитать стоимость? Всё очень просто: её никто не может заранее рассчитать. В том числе — разработчики. И архитектурные сложности, и проблемы с производительностью зачастую выявляются постфактум. Внутричерепная машина времени у фронтендера несовершенна. И хотя велик соблазн свалить все косяки на дизайнера, который не знал чего хотел, нужно помнить, что жизнь — непредсказуемая штука.
Интроверты (не) против экстравертов
Разумеется, реальный фронтенд-разработчик в среднем очень далёк от стереотипного программиста-хиккана, какого любили (да и до сих пор любят) показывать в фильмах. Но стереотипы всегда несут в себе хоть какую-то долю истины. Для разработчика хард скиллы важнее софт скиллов. Это не значит, что последние вообще не важны, работать с Д«Артаньянами и докторами Хаусами мало кто захочет. И всё же в первую очередь важно умение писать код, делать продукт, а уже потом — коммуникабельность и сладкоречивость.
Дизайнеры же, как с некоторой завистью говорят на фронтенде, — софтовые ребята. Им необходимо общаться и с разработчиками, и с заказчиками, и со всеми подряд. Всех понимать, иногда даже включать телепатию. Софт скиллы здесь как минимум столь же важны, как хард скиллы.
Казалось бы, неизбежно противостояние. Физики vs лирики, мужчины с Марса, женщины с Венеры… Но нет, противостояние очень даже избежно. Своими софт скиллами дизайнеры удачно дополняют разработчиков. Любое недопонимание, связанное с различием языков и майндсетов, можно преодолеть, и дизайнеры берут на себя значительную часть этого преодолевания. Нужно только не забывать, что у разных людей — разный набор коммуникативных компетенций, и относиться друг к другу с уважением.
Разговор важнее слов
Есть довольно много вещей, которые у дизайнеров и фронтендеров называются по-разному. Скажем, у дизайнеров интерлиньяж, а у фронтендеров — line-spacing. На фронте — letter-spacing, а у дизайнеров — кернинг. В идеале каждый специалист должен знать оба языка, говорить со «своими» на одном, а с «чужими» — на другом. Совсем в идеале — можно было бы выработать единый язык и заставить всех пользоваться только им.
Однако история учит нас, что история никого ничему не учит спонтанно возникшие пиджины и прочие суржики оказываются более живучими, чем конланги, и более эффективными, чем разговорники. Когда мы собирали материалы для этого поста, разработчики и дизайнеры ПСБ, конечно, высказывали некоторые претензии к коллегам, но сходились в одном: говорить, хотеть говорить, быть готовым говорить — это самое важное. Точность терминов требуется в ТЗ или мануале. В живом общении специалистов лучше говорить неправильно, но понятно, чем мучить зазря вокабуляр.
Надеюсь, наш понимайник оказался полезен. А если вы фронтендер или дизайнер, обязательно напишите в комментариях, с какими коммуникативными трудностями сталкивались лично.
