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

Работа с компонентами

• Создайте UI-кит, в которой будут иметься все элементы будущего макета: компоненты кнопок, инпутов, чекбоксов, радио, карточки, модальные окна и т.д., а также все использованные шрифты и цвета. Разработчики будут брать все элементы оттуда;
• Используйте компоненты для консистентности. В случае, если вам понадобится поменять какое-либо свойство компонента — не забывайте делать это через родительский компонент (в UI-ките), а не дочерний, чтобы у разработчиков не возникало вопросов об итоговом варианте;
• Используйте одинаковые компоненты для одинаковых элементов интерфейса. Например, если кнопка используется на нескольких страницах, она должна быть представлена одним компонентом, а не отдельными элементами;
• Давайте понятные и логичные названия компонентам. Например, ‘Button / Primary / 44px" или "Card / Product’, чтобы было ясно, какой это элемент и где он используется. Кроме того, так будет удобнее найти компоненты, распределенные по папкам в фигме.

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

• В макете должны быть проработаны все состояния элементов интерфейса (например, кнопки, инпуты, свитчеры): enabled, hover, focused, pressed, disabled;                             
• Продумайте как будут выглядеть страницы ошибок: 404, 500, — и покажите их на макете;
• У динамических блоков и карточек покажите загрузку контента, пустой блок или ошибку. Также покажите состояние любой формы при успехе, отправке или ошибке.

Текстовые и цветовые стили

• Используйте четкие текстовые стили для заголовков, подзаголовков, текста кнопок и основного текста; 
• При работе с цветовыми стилями в наименовании стиля указывайте: цвет (или где он применяется) → насыщенность цвета (через числа). Например, неправильно: blue, dark blue, light blue. Правильно: blue/100, 200, 300, 400. Либо accent/100, 200, 300, 400 (от наименее насыщенного к более насыщенному); 
• Использование разных текстовых стилей внутри одного текстового блока усложняет работу разработчика: становится неочевидно, к каким именно словам относится тот или иной стиль. Смешивать заголовок и текст в одном контейнере — плохая идея. Даже если с текстовыми стилями еще можно разобраться, правильно определить и воспроизвести отступы в таком случае значительно сложнее.

Типографика и шрифты

• Убедитесь, что все шрифты соответствуют тем, которые поддерживаются в вебе, и содержат необходимые для сайта символы (₽, отдельные буквы для иностранных языков). Если используются кастомные шрифты — сократите их количество до минимального;
• Шрифты должны быть доступны для коммерческого использования, либо должна иметься лицензия на его использование;
• Обеспечьте достаточный контраст для читаемости, особенно для текста;
• Старайтесь минимизировать изменение размера шрифта у определенного блока, т.е. если текстовый блок в мобильном отображении имеет размер шрифта 16, то старайтесь сохранить 16 в десктопной версии. Шаг в 2 пикселя (16, 18, 20) особо не даст результатов.

Иконки и графика

• Все иконки и графика должны быть векторными (SVG);
• Если вы используете изображение, на которое были применены наложения в фигме, заранее экспортируйте его и загрузите в макет окончательный вариант, так как у разработчиков наложения не отображаются и картинка будет в исходном варианте; 
• Подготовьте иконку сайта (Favicon).

Анимация и интерактивность 

• Описывайте анимации (если они есть), как они будут работать: время, задержки, эффекты;
• В случае сложных взаимодействий предоставьте видео или анимационные гифки для лучшего понимания;
• Если есть реализованный пример на работающем сайте, то прикрепите ссылку на него комментарием.

Адаптивность и резиновость

• Проработайте макеты для всех ключевых решений: десктоп, планшет (если в нем есть необходимость), мобильные устройства;
• Покажите, как элементы должны адаптироваться при уменьшении или увеличении ширины экрана;
• Используй максимум автолэйаутов и минимум брейкпойнтов. Автолэйауты фигмы очень похожи на инструмент Flexbox в CSS — разработчик закодит элемент или целый блок по тем же настройкам, как у вас в макете. Не нужно рисовать десяток брейкпойнтов каждой страницы, достаточно показать несколько размеров блока, если его поведение меняется в адаптиве. Например, перестраивается порядок элементов в блоке. Вам меньше механической работы, а разработчику не нужно искать глазами, как и что меняется среди кучи макетов.

Файловая структура и комментарии

• Логично организуйте все слои и группы в макете. Каждые сгруппированные слои (во избежание путаницы) должны носить понятные названия и отвечать логике страницы для понимания как самим дизайнером, так и разработчиком. Никаких ‘Frame6529’; 
• Все ненужное на макете, если это нигде не используется, нужно удалить, чтобы не сбивать разработчика с толку (да и себя тоже). Если удалять нельзя, то сделайте полупрозрачным или вынесите на отдельную страницу (например, ‘Drafts’); 
• Добавляйте комментарии и пояснения там, где могут возникнуть вопросы. Например: «у этой карточки фиксированная высота текста, остальной текст будет скрываться в многоточие».

Место для реальных данных

Подставляйте реальные данные или длинные названия (Кременчуг-Константиновское, Верхненовокутлумбетьево, Константин Константинопольский) во избежание ломаной верстки. Если место ограничено — предложите обрезку текста с многоточием или перенос на следующую строку. Кстати, принудительные переносы слов на другую строку, поставленные в Figma (перенос через Shift+Enter или неразрывный пробел Alt+Space), разработчик не увидит или не сможет повторить в типовом компоненте.

Порядок макетов

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