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

Что следует знать дизайнеру о работе разработчика

Этот список требований и пожеланий друг другу составлен представителями обеих профессий:

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

2. использование лучших практик и общепринятых решений (например, что есть контейнеры 1024px, 1180px, 1200px и т. д., а не 1234px, потому что так влезло);

3. представление об адаптивном дизайне (респонсивном, резиновом — кажется, терминология в этом вопросе уже мало кого волнует);

4. знакомство со способом разметки CSS Grid Layout;

5. знакомство с фреймворком Bootstrap;

6. понимание и грамотное обращение с концепцией дизайн-систем, которые помогают сделать дизайн проекта единообразным и согласованным в рамках проекта;

7. умение создавать интерактивные прототипы, чтобы проверить функциональность дизайн-концепций и взаимодействие пользователей с ними;

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

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

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

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

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

2. Стандартом де-факто становится знание разработчиком Sketch и Figma, где разработчику видны все размеры, отступы и стили элементов, и откуда он выгружает элементы дизайна.

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

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

5. Запрос на компетенции расширяется, когда речь идёт о продуктовой разработке. Здесь разработчику, возможно, придётся погрузиться в суть исследований и UX, откуда взялись те или иные интерфейсные решения, которые этот разработчик будет делать, и т. д. Это позволит на этапе разработки адекватно «подчищать» хвосты за дизайнером или грамотно обращать его внимание на пробелы. 

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

С каким дизайном приятно иметь дело

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

UI-кит:

• список текстовых стилей макета (шрифты и параметры шрифтов для заголовков, текста и т. д.). Если шрифт относится к Google Fonts, то лучше приложить ссылку на него — тогда он не подтягивается файлом, а прописывается ссылкой, что экономит 15 кБ;

• гибкие тексты и заголовки с учётом разного количества букв и вероятности переноса на несколько строк;

• все используемые в проекте цвета;

• размеры сетки и контейнеров для всех устройств;

• виды кнопок, ссылок;

• все состояния интерактивных элементов (hover, active, selected, checked, валидация, минимальные и максимальные состояния);

• используемые в проекте иконки изображения.

Помощь в понимании макета:

• комментарии к блокам;

• описание функциональности;

• хорошая структура дизайн-документа: все слои и фреймы понятно проименованы, соблюдена вложенность слоёв, одинаковые элементы интерфейса объединены в компоненты;

• последовательность и регулярность (логичность) в дизайн-решениях;

• понятная сетка и отступы;

• понятные референсы в местах, где есть такая необходимость (чаще это касается моушен-дизайна).

Оформление элементов:

• правильно указанные размеры для блоков и отступов. Все значения должны быть целыми числами;

• расположение блоков по сетке;

• указание line-height в процентах;

• применение Auto layouts (инструмент в Figma для автоматического выравнивания соседних модулей).

Заключение

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