Руководство по разработке продуктового дизайна

Софт

Photoshop предоставляет огромное количество плагинов, которые могут облегчить ваш рабочий процесс, но мы рекомендуем использовать Figma или Adobe XD. Эти программы совмещают преимущества использования векторной графики с простотой работы над растровыми изображениями, что особенно полезно при создании дизайна для устройств с большой плотностью пикселей. Используя Figma или XD, вы не будете переживать о выбранных цветовых профилях, а размер рабочих файлов будет в разы меньше. В итоге вы получите много полезных функций, которые смогут ускорить рабочий процесс.

Наименование файлов

Несмотря на то, что переименование файлов возможно на стороне бэкенда, будет лучше всем следовать одинаковым правилам:

Используйте латинский алфавит.
Не используйте пробелы.
Используйте нижний регистр (lowercase).
Используйте @2x- или @3x-постфиксы для подготовки изображений для устройств с разной плотностью пикселей.
Используйте эти же правила для именования папок.
Вкладывайте смысл в названия.

Оптимизация изображений

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

Посмотрите на гайд по оптимизации изображений от Google и следуйте следующим правилам:

Используйте JPG для изображений без прозрачности и в тех случаях, когда вы можете пожертвовать качеством картинки в пользу размера.
Для максимального качества и поддержки прозрачности используйте PNG.
Для анимаций используйте видеоформаты или гифки. Но GIF-анимация будет более хорошего качества при меньшем весе.

Инструменты для оптимизации изображений

Мы советуем использовать следующие инструменты: Kraken, ImageOptim, Optimage. Photoshop и Sketch по умолчанию сохраняют метаданные в изображениях и используют не оптимальные алгоритмы сжатия. Предлагаемые инструменты, наоборот, сделают так, чтобы ваша картинка не потеряла в качестве, но при этом весила меньше.

Старайтесь использовать SVG

При использовании SVG вы не будете волноваться о подготовке изображений для устройств с разной плотностью пикселей, создавая версии @2x и @3x. Также не придётся создавать версии одного файла с разрешениями для разных частей сайта (к примеру, логотип в футере и в шапке может быть разного размера, но с SVG вы будете использовать один файл). Другое преимущество SVG в том, что векторная графика занимает намного меньше места и является текстом, что позволяет эффективно производить сжатие на стороне сервера с помощью gzip для последующей передачи клиенту.

Несколько правил о работе с SVG

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

Проверьте, что вы не используйте base64-изображение внутри вашего SVG. Это возможно, когда вы случайно экспортируйте в SVG растровое изображение.

Пример, когда вы вставили base64-изображение в SVG

Уберите из SVG всю ненужную информацию с помощью SVGOMG. Обычно SVG содержит разные мета-данные (заголовок, описание). Также экспортированный SVG имеет prettify-код вместо inline минимизированного. Также могут присутствовать неиспользуемые группы и пустые контейнеры. Всё это можно убрать без потери качества с помощью SVGOMG.

Проверяйте SVG в браузере перед тем, как передать файлы разработчикам. Это позволит убедиться в том, что вы экспортировали SVG правильно и браузер отрендерил всё корректно.

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

Определите приемлемую степень сжатия для нестатических изображений

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

Favicon

Подготовьте два PNG-файла с разными разрешениями:

Первый: favicon.png с размером 32×32. Все современные браузеры поддерживают PNG-формат для favicon, и вам не нужно конвертировать его в ICO.
Второй: favicon-180×180.png с размером 180×180 для мобильных устройств.

Многие авторы заявляют, что нужно подготавливать большое количество версий favicon: 16×16, 24×24, 48×48 и так далее. Не стоит тратить на это время, так как в подавляющем большинстве случаев будет достаточно 32×32 и 180×180 версий. При необходимости браузер сможет сделать ресайз изображения до необходимого ему формата. Также не забывайте использовать инструменты по оптимизации изображений и для Favicon.

Grid

Держите в голове поведение CSS Grid Systems при разработке дизайна. Посмотрите на Bootstrap Grid — очень популярный CSS-фреймворк. Эта сетка будет покрывать большинство стандартных случаев, также она проста в настройке для разработчика. Главное понимать, что ширина колонок в CSS-фреймворках относительная, но имеет статический размер внутреннего паддинга. Bootstrap Grid по умолчанию имеет 12 колонок и внутренний паддинг 15 px, но при этом легко кастомизируется.

Когда вы создаете UI, то всегда работаете со статической картинкой, следовательно размер контейнера также будет статическим. Например, если размер артборда 1920 px, рабочая область 960 px, то размер одной колонки равен 80 px, где с каждой стороны будет отступ 15 px, а ширина внутренней части колонки 50 px.

Когда вы построили UI с использованием такой сетки, разработчику не придётся постоянно измерять размер некоторых объектов. Он просто будет знать, что элемент занимает, к примеру, две колонки. Просто покажите разработчику overlay с колонками, и он будет задавать их размер с помощью классов, таких как .col-sm-2, .col-sm-6.

Responsive дизайн

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

Если вы подготовили несколько версий страницы для 320×568, 1024×768 и 1920×1080, это не означает, что ваша работа закончена. Вам по-прежнему нужно объяснить разработчику, что будет происходить в переходах между разрешениями:

Что будет происходить с колонками и контентом внутри на каждом брейкпоинте.
Что будет происходить с размером контейнера на разных разрешениях (будет он занимать всю ширину экрана или примет новое статическое значение).
Как изменения разрешения повлияют на размеры изображений. Рассмотрим пример: есть картинка 200×200 px в десктопной версии, и вы решили, что изображение на мобильной версии будет занимать 100% контейнера, например, на устройстве с разрешением 375×667 px. В таком случае вам придётся иметь изображение 750 px по ширине для того, чтобы не получить размытую картинку на устройствах с большей плотностью пикселей.

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

Используйте стандартный набор брейкпоинтов: 320×568, 375×667, 768×1024, 1024×768, 1280×768, 1366×768 и 1920×1080. И не забывайте про landscape-режим на мобильных устройствах.

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

Не изобретайте велосипед

Если у вас нет достаточного количества времени и вы не уверены, что сможете продумать компонент от начала до конца (к примеру, dropdown или datepicker), попросите разработчика показать, какую библиотеку он привык использовать для этих целей, и просто стилизуйте её под общий UI Kit.

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

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

Анимации и прототипы

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

Используйте Principle, Framer или Adobe After Effects для анимаций. Это поможет избежать недопониманий между вами, разработчиками и клиентами, а также позволит протестировать ваши предположения. Анимации и прототипы помогают делать более крутые презентации ваших идей для клиентов.

UI Kits

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

В UI Kit вы должны добавить цвета, шрифты, компоненты (кнопки, формы, слайдеры), показать состояния объектов (active, hover, default). Используйте D.R.Y. («Don't Repeat Yourself»): принцип по которому вы думаете, что необходимо поместить в UI Kit, а что нет. Если вы используете два одинаковых элемента в рамках страницы, то смело помещайте его в UI Kit.

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

Мы рекомендуем использовать Craft для создания вашей UI-библиотеки. Также для больших проектов хорошей практикой является создание HTML, CSS-версии UI Kit и использование именно её для контроля качества элементов.

Экспорт

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

Zeplin. Современный инструмент для инспектирования макетов

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

Старый подход описания макетов, популярный в Photoshop

Состояния элементов

Во избежание недопонимания, мы рекомендуем использовать следующую терминологию, которая соотносится с названиями состояний в CSS. Больше вам не придется дополнительно объяснять разработчику, что вы имели ввиду:

Default.
Hover — состояние элемента при наведении мышкой.
Active — состояние при клике или нажатию на элемент.
Focus — состояние текущего выбранного поля (inputs, text areas).
Visited — состояние ссылки, на которую уже переходил пользователь.

Примеры состояний элементов

Line-height

Понимание line-height — неотъемлемая часть работы над дизайном и процесса передачи макетов разработчику. Для этого необходимо знать, как браузер производит рендер элементов на странице и как line-height влияет на это. Посмотрите на изображение ниже. Это типичный пример текстового блока и того, как браузер воспринимает его высоту. Высота блока совпадает с величиной line-height.

Одно из преимуществ использования Sketch в том, то что он рендерит текстовые объекты по такому же принципу как и браузер. А в Photoshop line-height никак не влияет на размер блока.

Хорошей практикой является использование line-height близким по значению к line-height шрифта. Не используйте много разных значений line-height в рамках одного проекта. К примеру, Roboto имеет 1,4x line-height от размера шрифта. Это означает, что при шрифте 16 px line-height будет 22 px.

Даже если вы решите использовать нестандартное значение, старайтесь использовать одну и ту же пропорцию на протяжении всего сайта. Наиболее частыми значениями являются 1,3 — 1,6 от размера шрифта. Разработчики это оценят. Они смогут задать line-height глобально и им не придётся отдельно устанавливать и проверять line-height каждого элемента. Они продолжат работать только с размером шрифта.

Теперь немного поговорим о поведении с нецелочисленными значениями в разных браузерах. Для примера возьмём:

Размер шрифта — 36 px.
Line-height — 1,4.

Chrome, Safari, Opera считают line-height с использованием только целочисленных значений, отсекая цифры после запятой. К примеру, в расчёте 36 px * 1,4 = 50,4 эти браузеры оставят 50.

Но Firefox учитывает значения после запятой. В результате 36 px * 1,4 = 50,4 будет всё равно 50,4 px. Визуально разница будет заметна в случае рассмотрения примера с двумя строчками текста. На изображении ниже line-height = 1,41. В Chrome, Safari и Opera размер элемента будет равен 100 px, тогда как Firefox будет считать высоту как 101.533 px.

Если вы хотите добиться абсолютного Pixel Perfect и поддерживаете Firefox, то задавайте максимально точную величину line-height как 1,34 653. Если для вашего проекта это не имеет значения, можете смело оставить просто 1,3.

Шрифты

Пытайтесь найти приемлемый для вас шрифт на Google Fonts. Браузеры поддерживают разные форматы шрифтов. Это означает, что разработчику придётся специально подготавливать ваш кастомный шрифт с использованием специальных сервисов по конвертации TTF/OTF в WOFF, WOFF2 или EOT. В ходе этого процесса шрифт может потерять в качестве. Поэтому моя рекомендация — используйте кастомные шрифты только в том случае, когда вы уверены, что ваши разработчики умеют с ними работать.

Ещё несколько вещей, которые необходимо знать об использовании шрифтов:

Не используйте больше двух шрифтов на проекте. Их количество влияет на скорость загрузки сайта.
Не используйте слишком много разных размеров и начертаний (italic, bold, light, thin, regular).

Разработчик и дизайнер

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

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

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