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