Как мы подходим к дизайну. Брекпоинты, сетки и UI-kit

В этой статье мы расскажем, как мы в Verno.digital работаем с дизайном, и как заботимся о клиентах и frontend-разработчиках.

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

Мы занимаемся разработкой сайтов и сервисов с экспертизой в маркетинге и UX. Дизайн делаем сервисный, основанный на исследованиях и анализе. Часто на этапе пресейла заказчик воспринимает дизайн, как красивую картинку, не уделяя должного внимания к подходам и стандартам. А во время собеседований мы видим, что подобные стандарты мало кто применяет. Хотя это и есть основа дальнейшего развития и поддержки любого проекта. Иногда к нам стучатся клиенты с запросом поддержки, а у них нет ни исходников, ни компонетного подхода, а желание развивать сайт, мы естественно аргументированно отказываем или предлагаем редизайн и новую разработку, иногда это экономически более целесообразно. К сожалению огромное количество проектов, выпущенных на рынок очень проблематично или невозможно поддерживать.

Мы не будем практически ничего говорить про “картинку”, а расскажем про сервисность и то, как дизайн встраивается в разработку и последующую поддержку проекта.

За время нашей работы к нам попадало много чужих проектов в figma, мы постоянно просматриваем работы на собеседованиях, даем тестовые и пришли к выводу, что большинство подходит к адаптивности по наитию, потому что так заведено и ключевые решения в адаптивах ложатся на плечи frontend-разработчиков. Часто дизайн на многих разрешениях может выглядеть криво или складываться в мобилку раньше необходимого разрешения. Мы и сами этим грешили раньше.

Стандарт, который часто используется в отрасли, хотя намного чаще в макетах можно встретить только 1920px и 375px.

В чем проблема? А проблема в том, как контент будет работать и жить на других разрешениях.

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

Это наш внутренний стандарт для большинства веб-проектов, который мы четко прописываем в договоре и отдаем в последующем файлом в Figma. Однако у нас есть сейчас в разработке сайты с нестандартным контейнером и сеткой, там мы делаем 5 брекпоинтов.

А есть всего 1, но с “резиной” на увеличение. Важно, для 90% проектов подойдет наш стандарт, поэтому смело можно забирать брекпоинты в figma и использовать их.

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

На десктопе мы используем 12 колонок, такая сетка оптимально подходит для большинства сайтов. Для дашбордов и сложных интерфейсов мы используем 24 или 32 колонки.

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

Ui-kit позволяет на этапе дизайна вынести переиспользуемые компоненты и заложить все состояния.

На VC уже образовалось много статей про ui-kit, пересказывать их не будем, тем более набор элементов в проектах чаще всего разный, но у нас есть определенные принципы к организации работы над сбором элементов и компонентов.

1. Если элемент встречается более одного раза в проекте - упаковываем в компонент
2. Элемент имеет более одного состояния в проекте. На этом пункте остановимся подробнее.

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

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

3. Иконки. Тут тоже стоит остановиться подробнее.

Все иконки выносятся в отдельный фрейм кита. Каждая иконка имеет название и является компонентом. Так же выносятся все возможные размеры иконок в проекте. Все это необходимо для того, чтобы соблюдать единообразие в проекте, иметь адекватную декларацию иконок, для избежания повторной выгрузки и использования двух разных иконок одного вида и назначения. На крупных проектах иконки выносятся в storybook.

• Название фреймов в макетах.

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

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

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

Мы продолжаем развивать стандарты и процессы, будем рады, если вы поделитесь в комментариях, как у вас устроен подход к дизайну.