Разработка дизайн-системы интерфейса
Собираем общие компоненты и правила для экранов или нескольких продуктов. Разбираем существующие интерфейсы, определяем токены и основные элементы, описываем состояния и использование. Передаём документацию команде для последовательного развития интерфейса.
Формат работы
по этапамСостав, точный срок и стоимость согласуем до начала работ.
01 / Результат
Состав первого этапа дизайн-системы
- Аудит интерфейсов
Сравниваем существующие элементы и выбираем область унификации.
- Токены и компоненты
Фиксируем общие параметры и согласованный набор основных элементов.
- Состояния и правила
Описываем поведение и условия применения компонентов.
- Документация и передача
Объясняем структуру и передаём правила команде.
02 / Границы задачи
За рамками базового состава
- Фирменный стиль и логотип компании
- Все компоненты и программная библиотека без отдельного согласования
Для разбора нужны действующие экраны, макеты и сведения о командах, которые будут использовать систему. Состав компонентов определяем до начала.
Когда продукту нужна дизайн-система
Общие правила полезны, когда одинаковые действия выглядят по-разному на разных экранах, а новые элементы каждый раз создаются заново. Выбираем интерфейсы и команды, которым нужна единая основа.
Первый этап ограничиваем наиболее используемыми элементами. Разработку всех возможных компонентов и программной библиотеки без отдельного согласования не включаем. Логотип и фирменный стиль компании тоже имеют другой состав.
Что выясняем при аудите интерфейсов
Сопоставляем формы, кнопки, списки и другие элементы выбранных экранов. Разбираем, какие различия нужны по сценарию, а какие появились случайно. Уточняем существующие ограничения реализации.
Определяем общий язык элементов с дизайнерами и разработчиками. Материалы UI-дизайна могут стать исходной основой. Если одни и те же элементы решают разные задачи, сохраняем эти различия в правилах.
Как связываем токены и компоненты
Токены задают согласованные параметры оформления: например, цвет, размер текста или расстояние. Компоненты используют эти параметры и имеют определённые состояния. Набор выбираем по потребностям продукта.
Для каждого элемента указываем назначение и допустимые варианты. Проверяем характерный контент и выбранные размеры экранов. Готовая схема макетов не означает автоматического появления реализованной библиотеки в коде.
Какие правила получает команда
Описываем, когда использовать элемент, какие данные он показывает и как сочетается с другими частями интерфейса. Фиксируем выбранные состояния и примеры применения, чтобы новым участникам не приходилось угадывать решение.
Передачу сопровождаем разбором структуры. Передачу проекта команде можно расширить отдельным составом. Порядок добавления новых элементов и обновления правил согласуем с теми, кто будет развивать систему.
Этапы и проверка результата
Работа идёт по этапам: область аудита, основа, компоненты, правила и документация. Срок и стоимость зависят от исходного состояния, числа продуктов и состава первого набора. Оценку даём после разбора.
Проверяем комплектность компонентов, состояний и описаний. Для отдельной оценки удобства и доступности можно согласовать аудит интерфейса. Дизайн-система помогает унификации, но не исправляет автоматически все существующие экраны.
Вопросы перед началом
Вы создадите библиотеку компонентов в коде?
Программная библиотека не входит без отдельного согласования. Определяем, нужны ли только токены, макеты и правила или также реализация.
Все компоненты будут включены сразу?
Нет, набор согласуем по этапам. Начинаем с основных элементов выбранных интерфейсов.
Дизайн-система заменяет фирменный стиль?
Нет, фирменный стиль и логотип компании исключены. Система описывает оформление и использование элементов продукта.
Следующий шаг
Соберём общий набор правил интерфейса
Покажите продукты, повторяющиеся элементы и текущие макеты. Назовите команды, которые будут пользоваться системой, — определим первый набор компонентов.