На чем мы теряли сотни тысяч рублей и зачем создали свою дизайн-систему

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

За почти 8 лет существования нашей студии мы реализовали более 250 проектов для крупных корпораций, малого и среднего бизнеса. И даже успели попасть в рейтинги Тэглайна, Руварда и Рейтинга Рунета, заняв высокие позиции. Например, из последнего — 8 место среди всех дизайн-студий в Санкт-Петербурге. 

И всех бы этих достижений не было, если бы мы не совершали ошибки и не успели набить десятки, если не сотни, шишек на них. В прошлой статье мы рассказывали, как автоматизировали конструктор КП, наш дизайнер Ваня подробно объяснил, зачем это вообще было нужно и как мы снизили расходы на этом процессе. 

Сегодня же не менее важная тема, которая долгое время тратила слишком много ресурсов — отсутствие внятной дизайн-системы (далее ДС) и как мы решили это изменить.

Эта статья основана на личном разговоре с Иваном — еще одним нашим дизайнером. Который в определенный момент увидел эту необходимость (в создании ДС) и вместе с ребятами реализовал рабочую ДС. 

Спойлер: она и по сей день помогает нам и нашим клиентам. Но обо всем по порядку.

Терминология 

Я понимаю, что большая часть пользователей, которые прочитают эту статью так или иначе связаны с дизайном. Но для галочки давайте вкратце, что такое ДС и UI-kit (тоже важная переменная в этом рассказе). Заходим в гугл и видим следующую картину:

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

UI-kit — визуальные элементы интерфейса, такие как цвета, шрифты, кнопки, иконки, формы, анимации и прочее. В контексте дизайн-системы — условно один из её подпунктов. 

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

ДС это сложный продукт, который расписывается до мелочей чуть ли не в пикселях. Здесь же хоть и присутствуют гайдлайны, но они не затрагивают все возможные сценарии.

Формально, то что реализовал Иван можно назвать ДС, но, если мы рассматриваем все по четкой терминологии, то этот «продукт» все-таки что-то среднее между дизайн-системой и UI-kit. 

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

С этим закончили, можем к истории создания приступать)

Почему мы это сделали?

Прошлая ДС не отвечала всем запросам. По ней банально нельзя было создать адекватные высокодетализированные прототипы. Она была топорной, тяжелой для понимания и, что самое главное, — не была гибкой.

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

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

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

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

Постоянно вносить изменения в ДС в режиме реального времени начинало надоедать. Поэтому Иван принимает решение изменить правила игры и пересобрать все с нуля.

Как проходил процесс создания ДС

В первую очередь были заведены токены. Условно:

— Цветовые токены

— Шрифтовые

— Скругления…

…и так далее 

Далее мы пошли по принципу «атомарного дизайна»*. 

Атомарный дизайн — методология проектирования, которая разбивает интерфейс на составные части, начиная с самых простых элементов (атомов) и постепенно объединяя их в более сложные структуры (молекулы, организмы и т.д.).

Давайте разберем на примере календаря:

— самый «низкий» элемент — текст

— далее — «атомы». Это базовые неразделимые и самостоятельные элементы. К ним мы можем отнести заголовки, иконки, чекбоксы, поля ввода и кнопки. Они не несут большого смысла по одиночке, но незаменимы при сборке интерфейса

— Следующий уровень «молекулы». Сюда можем отнести «день с датой» (объединение текста с базовыми элементами. Например, номер дня со стандартной ячейкой).

— «Организм» — сложные комбинации молекул. Календарь в целом. Т.е. Заголовок месяца с кнопками навигации, строка дней недели, N строк с ячейками дней и как следствие полноценный месячный вид.

— «Шаблоны» — макеты страниц, на которых организмы расставлены в определенные места. На этом уровне показывается, как компоненты располагаются на странице, но без реальных данных. Например, «фильтр с календарем» или «горизонтальное расположение таблицы»

— «Страницы». Это уже конкретная реализация шаблонов с реальными данными. То, что видит и используют пользователи. На этом уровне прорабатываются все детали с реальными юзер-кейсами. Например, «страница бронирование отеля».

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

В начале мы приоритизировали процессы и отрисовали самые часто используемые элементы в интерфейсе. Если чуть конкретизировать — кнопки, инпуты, выпадающие списки и так далее. 

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

Нам повезло избежать больших проблем во время создания ДС. Т.к. изначально мы собирали её с нуля, то Ваня сходу обозначил дизайнерам процесс создания. Поэтому частой проблемы с наименованием элементов удалось избежать. Единственный минус, с которым мы столкнулись, но уже фиксим — не хватает цветовых токенов. 

«Нет и не будет лучшей или худшей дизайн-системы/UI-Kit. То, что мы смогли реализовать — закрывает наши потребности и помогает решать задачи. Именно поэтому мы и делали ДС»

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

Как следствие, мы можем копировать элементы из нашей ДС в новый проект и кастомить всю ДС за счет токенов. 

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

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

«Давайте разберем на примере «атома». Например, вы начали рисовать первый блок какого-либо сайта/приложения. Очевидно, там будет кнопка. Следовательно, нужно отрисовать кнопку. А что нужно, чтобы начать отрисовывать кнопку? Высока вероятность, что в кнопке будут использоваться какие-то иконки. Значит нужно отрисовать и их. А еще стоит сделать контейнер текста отдельным компонентом, который можно будет дальше реиспользовать. В этом случае атомом является сама кнопка»

Разбивайте большие компоненты на мелкие и начинайте отрисовывать все шаг за шагом.

Используем ли мы дизайн-систему?

Вот мы и подошли к главной теме сегодняшнего рассказа. Создать ДС это одно, другое дело — тестить её в реальных условиях.

Да, мы успели протестировать её. И происходило это в два этапа:

— Как только Ваня сделал её, он написал в наш рабочий чатик и попросил фидбек от ребят. Мы естественно посмотрели, что вообще за зверь получился и оставили комменты. Собственно, благодаря этим комментариям ДС стала выглядеть еще лучше.

— После этого мы успели спроектировать несколько… да, к сожалению, я не могу назвать NDA название компании. Но интерфейсы были спроектированы, заказчики довольны, а мы поняли, что все работает как часы.

Сегодня ДС активно используют наши дизайнеры для работы над разными проектами. И вот несколько комментариев от них:

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

Начнем со студии. Это польза в скорости. Теперь нам (наконец-то) не нужно использовать kit сделанный еще в начале зарождения студии. Время — деньги, а это чуть ли не главное в любом бизнесе.

В будущем хотим реализовать еще и интерфейсные шаблоны «популярных» блоков, чтобы еще больше оптимизировать время дизайнеров. Условно, прототипы хиро блока, блока преимуществ, прайса и так далее.

Какова же польза для клиента? Такая же польза в скорости. Заказчики не любят долгие работы, а наша ДС настолько универсальна, что мы можем брать уже готовые блоки и подстраивать их под конкретные запросы. 

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

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

«Не нужно идти к дизайнеру нарисовать что-либо. Заказчик может попросить своего разраба сделать элемент на основе нашей ДС»

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

Относительно недавно фигма ввела новую фичу. Теперь пользователи могут видоизменять одну и ту же ДС с помощью токенов. И работает это не только со светлой и темной темой, но и с созданием неограниченного числа стилей. А значит, что мы можем реализовывать ДС для разных продуктов, а это:

— Изменение цветовой палитры

— Изменение отступов, скруглений и прочих— Изменение размеров бордеров и еще кучу всего

Плюс всё это можно экспортировать и импортировать напрямую. Короче работы еще предстоит много)Спасибо каждому, кто прочитал статью до конца. С вами был UXART. И если вам понравился текст, обязательно поставьте лайк и напишите комментарий)

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

А мы увидимся с вами совсем скоро на том же самом сайте <3