Дизайн-система: каким проектам нужна, как разрабатывается и на что влияет. На примере ITSM-платформы SimpleOne
9 января 2024
обновлено: 6 ноября 2026
13 ноябрь 2026
Систематизация и унификация – вечный тренд любого бизнес-процесса. Для UX/UI-дизайнеров воплощением этого тренда стала дизайн-система – документ / база знаний / хранилище, которая содержит в себе все элементы дизайна и руководство по работе с ними. Мы рассмотрим следующие вопросы использования дизайн-системы в проектах разработки корпоративных приложений.
- Почему проработанный, а главное, системный дизайн нужен профессиональным платформам и сложным системам не меньше, чем вебу и пользовательским приложениям?
- Как мы, в SimpleOne, пришли к необходимости создания собственной дизайн-системы и как мы её разрабатываем?
- Как дизайн-система помогает нашей команде уже сейчас?
Материал этой статьи основывается главным образом на нашем собственном опыте разработки интерфейса ITSM-системы SimpleOne. Однако, всё нижесказанное будет справедливо для любых сложных систем – будь то ESM-платформа (над которой, мы, к слову, также работаем), ERP-система, СЭД и т.п.
Начнём с начала: зачем вообще таким, отнюдь не развлекательным платформам, как ITSM-система, уделять большое внимание UI и, тем более, UX -дизайну (не говоря уж о CX и BX)? Ведь, если enterprpise-системы подразумевают, что в них люди будут работать, то и излишки в виде «красивого» UI и «хорошего» UX будто бы не нужны. Так до сих пор считают многие разработчики.
Помимо этого, в среде разработки корпоративных систем до сих пор ведутся споры о том, что есть дизайн интерфейсов – исключительно визуальная разработка или нечто большее?
Чтобы понять, что не так с подобным взглядом на UX/UI-дизайн, достаточно обратиться к источнику этих терминов – английскому языку. Английское слово «design» главным образом означает «конструировать», и далеко не всегда относится к художественной работе, чаще к инженерной. Также и дизайн UX и UI – это больше инженерные задачи, особенно в нашем случае. Как и в e-commerce, для проектирования профессионального интерфейса необходима детальная аналитика. Но фокус при проведении исследования сдвинут в сторону востребованности тех или иных функций, времени, затраченного на реализацию нужного регламента, и логики размещения элементов управления в зависимости от этих параметров.
Среди разработчиков распространено заблуждение, что сложные системы необходимо делать простыми. Это невозможно. Зато возможно сделать сложную систему понятной – с помощью грамотно сконструированного интерфейса.Павел Чуприн Главный UX/UI-инженер SimpleOne
Но важна и визуальная часть интерфейса. Зрительно приятный интерфейс создает у пользователя ощущение, в хорошем смысле, простоты. А в конечном счёте, все корпоративные платформы так или иначе должны облегчать работу сотрудников. Инструменты корпоративной ESM / ITSM системы должны повышать скорость, эффективность работы сотрудников, и, что наиболее важно, давать удобный рабочий инструментарий.
В неудобном кресле человек не захочет сидеть по 8 часов в день, в офис, расположенный на окраине, будет постоянно опаздывать, на старом принтере будет печатать бракованную документацию. Представьте все проблемы, которые могут возникнуть в работе сотрудника – каждую из них можно получить, если интерфейс корпоративной системы будет устаревшим, неудобным или банально неприятным глазу: задержки, ошибки, препятствия в коммуникации, потеря данных, да что угодно!
Мы в SimpleOne убеждены, что User eXperience и User Interface критически важны для качественной enterprise-системы. Без удовлетворенности внутренним продуктом тяжело повышать качество внешнего.
Безусловно, требования к UI сервисной IT-системы будут отличаться от требований к UI дейтингового приложения. Однако, и там и там пользователи – люди, чьи поведенческие паттерны, психология, пользовательские ожидания, ментальные модели и эстетические предпочтения не меняются, стоит им перешагнуть порог офиса. Да, на первом месте всё же должен быть процесс, а не человек. Но без человека (а точнее – хоть какого-то внимания к удобству его работы в системе) не получится и процесса, а, значит – и прибыли. Именно поэтому, при разработке платформы SimpleOne, мы стремимся конструировать красивые, элегантные дизайн-решения с высоким юзабилити и низким порогом вхождения в работу инструментов. Главная задача – делать это без потери функциональных возможностей и не в ущерб масштабируемости. Вот здесь вступает в игру дизайн-система!
Основа дизайна enterprise-платформ – системный подход
Упорядоченность, непрерывность и последовательность итераций – фундамент, на котором строится сложная система. Мы ведём непрерывную работу над интерфейсом нашей ITSM-системы. Но изменения внедряются постепенно, очень маленькими порциями, чтобы не навредить сложившимся пользовательским паттернам. Не будет откровением сказать, что в подобной работе не обойтись без фиксации данных и чёткой систематизации знаний и опыта. Именно поэтому любой подобный проект так или иначе подразумевает наличие дизайн-системы. Даже, если вам кажется, что конкретно в вашей корпоративной системе даже и дизайна-то никакого нет, будьте уверены, что дизайн-система или хотя бы UI-кит – точно есть.
Всё, что используется в интерфейсе должно быть систематизировано и быть доступно в одном месте. Вся команда разработчиков должна знать об этом и пользоваться общей базой знаний.
Для этого необходим не просто UI Kit, не набор кнопочек, а целый стандарт разработки интерфейса. Свод правил, хранилище артефактов, интеграция в бизнес-процессы разработки, общее семантическое поле.
Как мы создавали (и создаём) дизайн-систему для платформы SimpleOne
Непрерывное конструирование масштабного проекта предполагает основательную подготовительную работу. Наша подготовительная работа началась, как это часто бывает, с создания UI-кит: все имеющиеся на тот момент компоненты дизайна (цвета, шрифты, кнопки, дизайн-концепция) были скомпонованы в страницы, блоки и далее – в макеты.
Это помогло первичной унификации конструирования интерфейса – количество неподходящих дизайн-решений, принимаемых разработчиками самостоятельно, уменьшилось в разы. Однако, мы быстро выросли в плане функциональности и UI-кит перестал покрывать все наши модули. Разные части системы начали выглядеть по-разному: вёрстка заново каждого нового элемента не только отнимала у нас много времени, но и приводила к багам и несостыковкам в дизайне. Диалог дизайнеров и разработчиков, хоть и был начат, не был налажен на должном уровне. При этом, одной из ультимативных целей проекта уже тогда стало сделать ITSM-платформу, преимуществом которой было бы не только заветное «подходит под программу импортозамещения», но и действительно интуитивно понятный и приятный интерфейс. Так мы пришли к тому, что без дизайн-системы никак – надо разрабатывать.
От набора дизайнов страниц мы вернулись к мельчайшим, но фундаментальным компонентам нашего дизайна. Таким образом мы пришли к атомарному конструированию (Atomic Design) дизайн-системы.
Из уже имевшегося UI-кита туда перекочевали наработки нашего визуального стиля с соответствующими компонентами интерфейса, добавились принципы, рекомендации и правила работы с этими элементами. Все элементы хранятся в общедоступной системе в Figma (советуем начинать именно с неё – последние её фичи хорошо заточены именно под разработку дизайн-систем).
В настоящее время алгоритм нашей работы по дизайн-системе выглядит так:
Стремимся же мы к вот такому алгоритму:
Сейчас, если надо что-то поменять, мы единожды вносим изменение в дизайн-систему, и оно автоматически применяется во всех макетах, мы передаём это изменение на вёрстку, верстальщик меняет соответствующие элементы на фронте, и передаёт их в реализацию. Постепенно мы переводим все элементы дизайн-системы в код, чтобы полностью автоматизировать этот процесс, избавившись от лишних ручных операций.
Поскольку SimpleOne в будущем планирует разработку и на мобильных платформах, мы рассматриваем вариант перевода дизайн-системы в токены, чтобы дизайн-система стала кроссплатформенной, и изменения легко масштабировались в рамках чётких гайдов Apple и Android.
Разработка дизайн-системы SimpleOne это непрерывный процесс идущий в ногу с развитием продукта. При этом колоссальный прогресс виден и измеряем уже сейчас.
Конкретно на нашу работу дизайн-система повлияла так:
- во фронтенде и дизайне снизилось количество ошибок;
- сборка макетов проходит быстрее;
- тестирование макетов проходит в готовом дизайне.
Чтобы подтвердить эти изменения количественно, мы организовали мини-исследование производительности труда наших дизайнеров с дизайн-системой и без неё. Двум группам UX-дизайнеров были даны одинаковые макеты, одна должна была собрать его самостоятельно, другая, пользуясь дизайн-системой. Итог оказался предсказуем – с дизайн-системой результат был достигнут в два раза быстрее. Любопытно, что ошибок при этом было примерно равное количество (немного – у нас классные дизайнеры), и все они связаны с человеческим фактором. Это дополнительный аргумент для того, чтобы мы ускорили перевод дизайн-системы в код.
Чтобы не остаться на задворках IT-индустрии, необходимо вести непрерывное развитие своего продукта. Всем членам команды разработки необходимо работать всё быстрее, при этом ещё и повышая качество своей работы и не теряя связей внутри команды. Дизайн-система – способ обеспечить такую работу как минимум на поле UX. По большому счёту, дизайн-систему стоит воспринимать как конструктор Lego в дизайне, который при этом доступен и полезен для всех, а не только лишь для самих дизайнеров. Конструируя интерфейс нашего ITSM-решения с помощью дизайн-системы, мы видим прогресс не только в работе непосредственно дизайнеров, но и замечаем, что вся команда разработчиков становится ближе к единому пониманию что такое User eXperience, как им с ним работать, и как он потом поможет работать нашим клиентам.
