Правила работы за digital-станком

Исторически сложилось, что производственный цикл digital-проектов в ONY идёт долго. Например, e-commerce проект может идти от 3 до 8 месяцев. За это время может случиться что угодно: кто-то уйдет в отпуск, поменяется дизайнер, придёт новый продюсер и так далее. Причем проект не должен страдать ни по срокам, ни по качеству. Для этого мы разработали правила работы над digital-проектами. В этой статье расскажем о трёх главных и как они облегчают рабочий процесс.

Базовый принцип всего дизайна, что мы делаем в ONY — это крафт. Крафтом мы называем нечто произведённое с большой любовью и вниманием к деталям.

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

— разработчики хотят с лёгкостью забирать макеты в работу и понимать все затеи дизайнера, чтобы выдать классный результат;

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

— продюсер хочет, чтобы макеты отдавались вовремя с минимумом комментариев от клиента;

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

Чтобы совместить принципы дизайна с их реализуемостью, мы разработали внутри агентства несколько документов, облегчающих жизнь digital-направления. Один из таких документов — «Культурный код digital-дизайнера».

Этот документ позволяет делать не просто одноразовые макеты, а создавать полноценный workspace. В нём описаны правила сборки макетов, их презентации клиенту и передачи в разработку. В общем, всё, с чем может столкнуться обычный дизайнер, придя на работу.

Далее расскажем о трёх организационных правилах из этого документа: как делать компоненты, как делать шрифтовые стили и как оформлять UI-Kit.

1. Называйте слои, компоненты, их свойства и значения в едином стиле и по одному принципу. Мы пишем латиницей и используем единый формат написания — kebab-case. Это когда всё пишется с маленькой буквы, а вместо пробелов — дефис.

2. Настраивайте auto-layout. Для фреймов не забудьте задать constraints.

3. Используйте одиночные properties для простых компонентов, чтобы не дублировать варианты. В ином случае — используйте варианты. Напоминалка про свойства.

4. Не оставляйте скрытые слои, если они не скрыты свойством компонента boolean.

5. Не создавайте лишних вложенностей, старайтесь делать простую структуру компонента.

6. Описывайте все возможные состояния компонента сразу. Думайте над фамилией из 99 символов, над номером телефона из Замбии, над работой кнопки «Поделиться» на Nokia 3310, над адресом без номера дома или без названия улицы. Как приходят данные в компонент, что будет, если данных нет, что будет в случае ошибки. А ещё, конечно, учитывайте гайд по доступности. В общем, продумывайте логику компонента тщательно, от этого зависит финальный результат проекта и срок его реализации.

7. Продумывайте анимацию перехода между состояниями компонента. Как крутится лоадер, а потом появляется контент; как убирается товар из корзины и так далее. Можно связывать состояния через prototype или собрать отдельный аниматик для разработчиков.

8. Задавайте размер компонента с учётом клик-зоны. Не делайте её слишком мелкой. Для десктопа 24px и выше — нормальный размер, всё, что меньше — нет. Для мобильных устройств лучше делать 48px.

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

Мы делим стили на 3 типа, в зависимости от уровня экспрессии:

Такого набора обычно хватает на всех проектах, но если чувствуем, что нуждаемся в дополнительных типах — смело их заводим. Например, subheading — для разделения заголовков и подзаголовков, или supporting — для исключений.

В дополнение к типам мы вводим обозначения для зоны применения стиля:

Комбинируя типы экспрессии и зоны применения, получаем готовый код для любого стиля. Например, body/XS-XL говорит нам о том, что мы применяем этот стиль для основного текста на всех экранах. А, например, caption/S сводит зону применения только к одному брейкпоинту. Разрабатывая свой подход, мы вдохновлялись систематизацией макетов от студии Area17, обязательно посмотрите, как у них всё устроено.

Коды стилей могут повторяться, мы различаем их за счёт разных размеров и интерлиньяжей. Бывает так, что разница с ходу незаметна: немного другой интерлиньяж, включённый апперкейс или опентайп фича. Такой случай — исключение. Мы используем для него особый тип supporting и храним там подобные стили. Поле description помогает понять, где этот стиль применяется или в чём его особенность»

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

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

Небольшие дополнительные фишки по организации UI-Kit:

1. Разделяйте компоненты на смысловые группы, чтобы UI-Kit не превратился в бесконечно длинную доску.

2. Выносите неменяющиеся большие блоки в компоненты: баннеры, формы, карусели и так далее.

3. Размещайте компоненты по родству. Например, карточки с карточками, формы с формами и так далее.

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

Если у вас есть digital-задачи, которые нужно решить в кратчайшие сроки — давайте обсудим.

Еще больше кейсов, подкастов от нашей команды и новостей дизайн-индустрии — в нашем Telegram-канале. Подписывайтесь!