Зачем среднему бизнесу своя дизайн-система и как она ускоряет разработку

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

Привет! Я Трофим Жугастров, основатель компании Elonsoft. Мы помогаем среднему бизнесу стать крупным с помощью создания кастомных web, mobile и корпоративных IT-продуктов для цифровой трансформации бизнес-модели.

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

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

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

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

В статье рассказываю, что дизайн-система дает нам и нашим клиентам.

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

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

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

За основу взяли Google Material Design и последовательно добавляли новые стили и компоненты, когда нам чего-то не хватало в ежедневной работе. Сейчас у нас много уникальных компонентов, которых не было в материнской дизайн-системе.

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

Сейчас у нас в библиотеке больше ста компонентов, и это экономит нашим дизайнерам от 20 до 50% времени. Разработчикам — примерно столько же. Более точные цифры назвать сложно. В разных продуктах отличается доля типовых компонентов, которые уже есть в библиотеке, и тех, которые нужно придумать с нуля. Человеческий фактор тоже влияет — кто-то из дизайнеров быстрее создает компоненты, а кто-то медленнее. Так что для достоверного замера времени нужна очень большая выборка.

Мы постоянно дорабатываем нашу дизайн-систему. Например, в системе обучения DeasyLMS мы использовали и доработали компонент чата, который разрабатывали для другого проекта. Теперь для новых проектов у нас есть самая свежая и актуальная версия чата. Но иногда что-то приходится дорабатывать из-за внешних факторов, например, когда Фигма обновляется и вводит новый функционал.

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

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

Дизайн-системы бывают продуктовые, брендовые и мультибрендовые. Продуктовые — для одного продукта, например для интернет-магазина «Золотое яблоко». Брендовые рассчитаны на серию продуктов одного бренда — как Яндекс Путешествия, Яндекс Еда, Яндекс Go. Продукты могут отличаться, например, цветом, но связь между ними будет визуально считываться.

А мультибрендовые дизайн-системы, например, Google и его Material Design, адаптируются не просто под разные продукты, а под разные бренды, которые между собой никак не связаны. Условно, от Макдональдса до РЖД.

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

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

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

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

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

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

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

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

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

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

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

Мы занимаемся разработкой кастомных web, mobile и корпоративных IT-продуктов.

Для каждого клиента мы подключаем дизайн-систему, чтобы все его продукты были в одном консистентном стиле. Это ставит нашего клиента в один ряд с Яндекс, Контур, Авито, Сбер с точки зрения дизайна экосистемы продуктов.

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

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