«Язык — это не просто набор несвязанных звуков, фраз, правил и значений; это совершенно целостная система, привязанная к контексту и поведению.» — Кеннет Л. Пайк

У веба есть акценты. И у наших дизайн-систем они тоже должны быть.

Дизайн-системы как живые языки

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

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

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

Единообразие становится тюрьмой

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

Наши дизайн-системы должны научиться говорить на диалектах.

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

Когда идеальное единообразие подводит

В Booking.com я усвоил этот урок на собственном опыте. Мы A/B-тестировали всё — цвета, текст, формы кнопок, даже цвета логотипа. Как профессионал с графическим образованием и опытом создания гайдлайнов бренда, я был шокирован. Пока все восхищались безупречной дизайн-системой Airbnb, Booking вырос в гиганта, никогда не заботясь о визуальном единообразии.

Хаос научил меня важному: единообразие — это не ROI. ROI — это решённые проблемы.

В Shopify. Polaris был нашей жемчужиной — зрелым языком дизайна, идеальным для мерчантов за ноутбуками. Как продуктовая команда, мы должны были внедрять Polaris как есть. Но тут наша команда фулфилмента столкнулась с вызовом: создание приложения для складских комплектовщиков, работающих на общих потрёпанных Android-сканерах в тусклых проходах, в толстых перчатках, сканирующих десятки товаров в минуту, многие из которых слабо владеют английским.

Выполнение задач со стандартным Polaris: 0%.

Каждый компонент, отлично работавший для мерчантов, полностью проваливался для комплектовщиков. Белые фоны создавали блики. Цели 44px были невидимыми для пальцев в перчатках. Надписи в регистре предложений занимали слишком много времени для чтения. Многошаговые процессы путали не-носителей языка.

Перед нами был выбор: отказаться от Polaris полностью или научить его говорить на складе.

Рождение диалекта

Мы выбрали эволюцию, а не революцию. Работая в рамках основных принципов Polaris — ясность, эффективность, единообразие — мы разработали то, что теперь называем диалектом дизайна:

  • Блики и слабое освещение: Тёмные поверхности + светлый текст для уменьшения бликов на экранах с низким DPI.
  • Перчатки и спешка: Цели 90px (~2 см) для работы в толстых перчатках.
  • Многоязычие: Экраны с одной задачей и простым языком для снижения когнитивной нагрузки.

Результат: выполнение задач выросло с 0% до 100%. Время онбординга сократилось с трёх недель до одной смены.

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

Фреймворк гибкости

В Atlassian, работая над платформой Jira (самой по себе системой внутри более крупной системы Atlassian), я настаивал на формализации этого подхода. Десятки продуктов, использующих общий язык дизайна на разных кодовых базах, требовали системной гибкости — мы встроили её прямо в процессы работы. Старая модель — запросы на исключения и особые одобрения — не работала в масштабе.

Мы разработали Фреймворк гибкости, чтобы помочь дизайнерам определить, насколько гибкими должны быть их компоненты:

  • Единообразный: Используется без изменений. Платформа фиксирует дизайн и код.
  • Авторитетный: Адаптируется в рамках ограничений. Платформа задаёт умные настройки по умолчанию, продукты кастомизируют.
  • Гибкий: Расширяется свободно. Платформа определяет поведение, продукты управляют представлением.

Во время редизайна навигации мы распределили все элементы по уровням. Логотип и глобальный поиск остались единообразными. Хлебные крошки и контекстные действия стали гибкими. Продуктовые команды сразу видели, где инновации приветствуются, а где важна консистентность.

Лестница решений

Гибкость требует границ. Мы создали простую лестницу для оценки того, когда правила стоит нарушать:

  • Хорошо: Запустить с существующими системными компонентами. Быстро, единообразно, проверено.
  • Лучше: Немного растянуть компонент. Документировать изменение. Внести улучшения обратно в систему для всех.
  • Наилучший вариант: Сначала прототипировать идеальный опыт. Если пользовательское тестирование подтверждает преимущество, обновить систему для его поддержки.

Ключевой вопрос: «Какой вариант позволит пользователям добиться успеха быстрее всего?»

Правила — это инструменты, а не реликвии.

Единство важнее единообразия

Gmail, Drive и Maps — это безошибочно узнаваемый Google, но каждый говорит со своим акцентом. Они достигают единства через общие принципы, а не клонированные компоненты. Одна лишняя неделя споров о цвете кнопки стоит примерно $30K рабочего времени инженеров.

Единство — это результат для бренда; беглость — результат для пользователя. Когда они конфликтуют, вставайте на сторону пользователя.

Управление без шлюзов

Отрывок: «Язык — это не просто набор несвязанных звуков, фраз, правил и значений; это совершенно целостная система, привязанная к контексту и поведению.» — Кеннет Л. Пайк. У веба есть акценты. И у наших дизайн-систем они тоже должны быть...