Интерфейс, который меняется сам: как проектировать под реалтайм-персонализацию

Интерфейс, который подстраивается под пользователя в реальном времени — это уже не «фича для крупных платформ», а базовое ожидание. Spotify меняет главный экран в зависимости от времени суток. Booking перетасовывает фильтры под историю поиска. Линкедин подменяет CTA на кнопке в зависимости от того, заполнил ли ты профиль. У всех этих интерфейсов общая черта: они никогда не выглядят одинаково для двух разных людей и для одного человека в два разных дня.

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

## Почему это сейчас стало важным

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

• AI снизил стоимость сигнала. Раньше чтобы понять, что пользователь — новичок, нужны были аналитики и SQL. Сейчас это решает один промпт к модели поверх событий.
• Каналы стали фрагментированными. Один и тот же человек заходит с мобилки утром, с десктопа днём и через email-дайджест вечером. Статичный интерфейс ломается уже на этом.
• Конкуренция за внимание выросла. Универсальный экран проигрывает экрану, который «понял» пользователя за 2 секунды.

Если продукт не умеет адаптироваться — он ощущается старым. Даже если визуально свежий.

## Что такое реалтайм-персонализация на самом деле

Чаще всего под этим словом понимают рекомендации. Это узко. Реалтайм-персонализация — это любое изменение интерфейса в ответ на сигнал о пользователе, контексте или поведении. Сигнал может быть какой угодно:

• кто пользователь (новичок / возвращающийся / платящий)
• где он сейчас (страна, язык, часовой пояс, устройство)
• что он только что сделал (последний клик, последняя покупка, прерванный флоу)
• в каком он состоянии (сессия началась минуту назад или длится час)

Дальше интерфейс может меняться на четырёх уровнях:

### Уровень 1: контент

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

### Уровень 2: иерархия

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

### Уровень 3: компоненты

Подменяются сами элементы. Кнопка «Купить» превращается в «Продолжить покупку», карточка-промо — в карточку-напоминание. Здесь нужны не макеты, а правила: при каком условии какой компонент.

### Уровень 4: навигация и структура

Меняется то, какие разделы вообще существуют для этого пользователя. B2B-продукты часто скрывают разделы под роли. Это самый рискованный уровень — пользователь теряет ориентацию, если структура «гуляет».

Хорошее правило на старте: не лезть на уровень 3 и 4, пока на уровнях 1 и 2 не выстроена дисциплина.

## Первое, что ломается: иерархия

Когда дизайнер рисует экран, он подсознательно выстраивает фокус: где первый взгляд, где второй, куда ведёт глаз. В персонализированном интерфейсе этот фокус может разъехаться, потому что блоки переставляются по правилам, которые дизайнер не контролирует напрямую.

Типичные сценарии поломки:

• Главный CTA уехал ниже фолда, потому что сверху приклеился персонализированный баннер.
• Два разных персонализированных блока конкурируют за внимание — оба «важные», и пользователь не выбирает ни один.
• На пустом сигнале (новый пользователь, нет данных) экран выглядит как сломанный — белые дыры там, где должна быть персонализация.

Чеклист для дизайнера, когда вводится динамический блок:

• Что произойдёт с иерархией экрана, если этот блок появится / исчезнет?
• Есть ли у блока fallback-состояние для пустого сигнала?
• Сколько таких блоков может оказаться на экране одновременно? Что с приоритетом?
• Кто решает, какой блок выигрывает — дизайн-система или продакт-логика? Это где-то записано?

Антипаттерн: «давайте сюда добавим персонализированный слот, контент решим потом». Слот без правил приоритета превращается в свалку через два релиза.

## Вопросы для ревью на этом этапе

• Мы проектируем экран или мы проектируем правила сборки экрана?
• Кто отвечает за иерархию, когда на экране 5+ динамических блоков?
• Есть ли у нас определение «пустого состояния» для каждого персонализированного слота?
• Видел ли дизайнер, как этот экран выглядит для трёх разных типов пользователей, а не только для своего тестового аккаунта?

Если ответы расплывчатые — персонализация будет работать в демо и ломаться в проде.

## Рабочий процесс: от макета к правилам

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

Практический сдвиг выглядит так:

• Вместо «макет главной» — матрица состояний главной (новичок без данных, новичок после первого действия, возвращающийся активный, возвращающийся «уснувший», платящий).
• Вместо «одна гипотеза CTA» — правило приоритета CTA: какой выигрывает, если оба применимы.
• Вместо «пустое состояние нарисуем потом» — пустое состояние как полноценный экран, потому что для части аудитории оно и есть основной.

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

### Минимальный набор артефактов

• Карта сигналов: какие данные о пользователе доступны на этом экране и кто их поставляет.
• Список слотов: что в принципе может меняться. Контент, иерархия, компонент, раздел.
• Правила приоритета: если в слот претендуют два блока, кто выигрывает.
• Fallback-состояния: что показывается, если сигнала нет или он опоздал.

Без этих четырёх штук персонализация — это разговор, а не дизайн.

## Диагностика: как понять, что интерфейс уже сломан

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

### Симптомы, которые легко пропустить

• Layout shift при загрузке. Сначала экран показывает дефолт, через 200–600 мс «дотягивается» персонализация — и всё прыгает. Особенно болезненно на мобильном, когда палец уже летит к кнопке.
• Двойной онбординг. Пользователь видит подсказку для новичка, хотя он уже неделю в продукте — потому что сегмент пересчитался не вовремя.
• «Пустые соты». Сетка из 6 карточек, но для этого пользователя релевантны только 2 — остальные 4 заполнились мусором или вообще не отрисовались.
• Конфликт с уведомлениями. Персонализированный блок дублирует то, что уже пришло пушом или письмом. Для команды это разные системы, для пользователя — одно раздражение.

### Как это ловить на ревью

• Прогоняй экран минимум для трёх профилей: «нулевой» (нет данных), «средний» (типовой кейс), «крайний» (старый пользователь, много истории).
• Смотри экран на медленной сети — именно там видно layout shift и опоздавшие блоки.
• Открой экран дважды подряд: персонализация на второй заход должна быть осмысленной, а не «как в первый раз».

## Типичные ошибки команд

### Ошибка 1: персонализация без отката

В макете нарисовано красиво, в проде — у 30% пользователей пустой экран, потому что система рекомендаций не ответила. Любой динамический блок должен иметь дефолт, который не хуже «универсального» варианта.

### Ошибка 2: слишком много осей сразу

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

### Ошибка 3: дизайнер не видит свой экран глазами пользователя

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

### Ошибка 4: персонализация ради персонализации

Блок меняется, потому что «у нас же есть данные». Польза для пользователя при этом не сформулирована. Если на вопрос «что пользователь теперь сделает быстрее или лучше?» нет ответа — это не персонализация, это шум.

## Как это укладывается в Figma и дизайн-систему

Хорошая новость: радикально перестраивать инструменты не надо. Достаточно нескольких привычек.

• Варианты компонентов под состояния сигнала, а не только под визуальные стили. У карточки рекомендации — варианты «есть данные / нет данных / опоздали данные».
• Документировать правила рядом с компонентом. Не в отдельном файле «персонализация v3», а прямо в описании компонента: когда применяется, что показывает в пустом состоянии, как ведёт себя в конфликте.
• Прототипы под сегмент, а не под фичу. Полезнее показать на ревью «как живёт новичок первые 3 экрана», чем «как выглядит фича X в идеальном кейсе».
• AI-подсказки и MCP-интеграции — после правил, а не до. Если использовать их, чтобы массово генерировать варианты экранов без чёткой матрицы состояний, получится много красивых картинок и ноль системы. Сначала оси изменчивости — потом ускорение генерации.

## Чеклист перед сдачей макета в разработку

• Для каждого динамического блока есть состояние «нет сигнала».
• Описано правило приоритета, если на экране несколько блоков претендуют на главный акцент.
• Решено, что происходит при опоздавшем ответе сервера: показываем дефолт и не подменяем, или подменяем с анимацией.
• Экран проверен минимум на трёх профилях пользователя, а не только на дизайнерском аккаунте.
• Понятно, кто в команде владеет правилами сборки: дизайн, продакт или ML.
• Есть способ отключить персонализацию на этом экране в проде, если что-то пойдёт не так.

## Вопросы для ревью

• Можем ли мы коротко описать словами, по какому правилу собирается этот экран? Если нет — правила пока нет.
• Что увидит пользователь, если все сигналы пропадут одновременно? Это всё ещё рабочий продукт?
• Где задокументировано, какая логика побеждает в конфликте между двумя персонализированными блоками?
• Видел ли разработчик ту же матрицу состояний, что и дизайнер, или ему придётся достраивать её самому?

## Короткий итог сегмента

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

## Сценарий: онбординг, который догоняет пользователя

Классический онбординг — линейная цепочка из 4–5 шагов. Реалтайм-персонализация ломает эту линейность: пользователь может прийти с инвайтом от коллеги, с заполненным профилем из соцсети, с историей в соседнем продукте. Дизайн должен это видеть.

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

### На что смотреть в макете

• Что увидит пользователь, у которого уже закрыты три задачи из четырёх — мы его поздравляем или сразу даём оставшийся шаг?
• Если задача закрылась в фоне (например, подтянулись данные из интеграции) — экран меняется в моменте или на следующем заходе?
• Можно ли пройти онбординг «не по порядку» и не сломать состояние?

## Сценарий: главный экран с конкурирующими блоками

На дашборде живут рекомендации, незавершённые задачи, апсейл, системные уведомления и иногда баннер от маркетинга. Каждый блок считает себя главным. Без правил приоритета побеждает тот, кого выкатили последним.

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

## AI-сборка экрана: где это работает, где ломается

Соблазн отдать сборку экрана модели велик: «вот сигналы, вот библиотека блоков, собери лучшее». На практике это работает только при двух условиях.

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

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

### Анти-паттерны при работе с AI

• Генерация вариантов экранов без матрицы состояний. Модель быстро выдаёт сто красивых картинок, но ни одна не отвечает на вопрос «что показываем, если сигнала нет».
• MCP-интеграция как замена правилам. Подключение Figma к данным продукта полезно для прототипирования на реальных значениях, но не отменяет описанной логики сборки. Иначе в макете всё красиво на одном пользователе и непредсказуемо на остальных.
• AI-копирайт на динамических блоках без редактуры. Текст рекомендации, собранный на лету, периодически выдаёт странные формулировки. Нужны границы: длина, тон, запрещённые конструкции, дефолтная фраза.

## Как проверять качество в продакшене

Макет — это гипотеза. Качество персонализации видно только на живых данных.

• Снимки экранов по сегментам. Раз в неделю — пачка скриншотов реальных пользователей из ключевых сегментов (с их согласия и без чувствительных данных). Глазами видно то, чего не видно в метриках.
• Метрика «полезность блока». Не только CTR, а доля сессий, где блок реально помог: клик привёл к завершённому действию, а не к возврату назад через две секунды.
• Доля дефолтов. Сколько процентов показов — это запасной вариант, потому что сигнал не пришёл. Если эта доля растёт, персонализация деградирует тихо.
• Жалобы поддержки с тегом «странный экран». Отдельный тег, который читает дизайн-команда, а не только продукт.

## Как объяснить решение команде

Самая частая проблема — не сама логика, а то, что разработка, продукт и ML собирают её каждый по-своему. Дизайнер думает, что «правило очевидно из макета», разработчик достраивает по интуиции, ML-команда оптимизирует свою метрику. На выходе три разных продукта в одном экране.

Что помогает на ревью:

• Одна страница правил рядом с макетом. Не дизайн-доки на 40 экранов, а короткий текст: какие оси, какие приоритеты, что в дефолте, что отключаемо.
• Матрица состояний вместо «идеального» экрана. Показываешь не один кадр, а сетку: сегмент × наличие сигнала. Сразу видно, где дыры.
• Сценарии «день из жизни». Один и тот же пользователь, три захода в течение недели. Это убеждает лучше, чем любая презентация архитектуры.
• Явная зона ответственности. Кто решает, что блок А важнее блока Б — дизайн, продукт или модель? Если ответа нет, решение примет тот, кто пишет код последним.

### Вопросы для ревью с командой

• Если завтра отключить ML-сервис, экран останется осмысленным?
• Где в коде живёт правило приоритета — в дизайн-системе, в продуктовом слое или внутри модели?
• Может ли поддержка по скриншоту пользователя сказать, почему он видит именно это?
• Что мы измеряем, чтобы понять, что персонализация делает лучше, а не просто иначе?

## Короткий итог сегмента

Продвинутая персонализация — это не «больше AI», а больше дисциплины: явные правила, наблюдаемая сборка, проверка на живых сегментах и общая для команды картина состояний. AI и MCP ускоряют работу там, где система уже есть, и усиливают хаос там, где её нет.

## Сводный чеклист: готов ли интерфейс к реалтайм-персонализации

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

### До запуска

• Описаны оси сегментации — не больше трёх, и каждая имеет понятный продуктовый смысл, а не «потому что в данных есть такое поле».
• Для каждого динамического блока есть пустое состояние, дефолт и состояние «сигнал устарел».
• Матрица состояний сегмент × сигнал собрана и просмотрена глазами, а не только в голове автора.
• Зафиксированы инварианты: что остаётся на экране всегда, независимо от модели.
• Прописан порядок приоритетов блоков на случай конфликта рекомендаций.
• У копирайта в динамических блоках есть границы — длина, тон, запрещённые конструкции.
• Пользователь может явно сказать «мне это не интересно» хотя бы для ключевых блоков.

### На запуске

• Каждый показ логируется так, что по ID сессии можно восстановить, какие блоки и почему выбрались.
• Есть фича-флаг, который отключает персонализацию и возвращает дефолтный экран в один клик.
• Дефолтный экран сам по себе считается рабочим продуктом, а не «заглушкой».
• Поддержка знает, куда смотреть, чтобы объяснить пользователю его экран.

### После запуска

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

## Анти-паттерны уровня процесса

Дизайнерские анти-паттерны про AI и состояния уже разобраны выше. Эти — про то, как команды ломают реалтайм-персонализацию организационно, даже если сами экраны спроектированы аккуратно.

### «Персонализацию ведёт ML, дизайн ведёт лендинги»

Самое тихое и самое дорогое разделение. Дизайн отвечает за статические страницы, а всё, что меняется в рантайме, считается зоной модели. Через полгода продукт состоит из двух разных продуктов: красивого фасада и непредсказуемой ленты. Никто не считает себя владельцем того, как они стыкуются.

### Один эксперимент — одна метрика

Реалтайм-блок поднимает CTR, и его раскатывают. Через квартал оказывается, что выросла усталость от ленты, упала глубина просмотра, выросли отписки. На ревью эксперимента эти метрики просто не смотрели. Любая персонализация должна оцениваться парой «целевая метрика + защитная метрика», иначе оптимизируется одно за счёт другого.

### Правила живут в трёх местах

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

### Нет ритуала деградации

Никто заранее не договорился, что произойдёт, если модель начнёт ошибаться: откатываем на дефолт, оставляем последний хороший срез, показываем редакционную подборку? Решение принимается ночью под давлением и обычно плохое.

## Вопросы для финального ревью

• Если новый дизайнер придёт через полгода, сможет ли он по документации понять, почему экран выглядит так у этого пользователя?
• Что должно случиться, чтобы мы откатили персонализацию назад — есть ли заранее заданный порог, или будем спорить в моменте?
• Какие блоки мы готовы оставить «человеческими» навсегда, потому что персонализация там даёт больше шума, чем пользы?
• Кто из команды смотрит на скриншоты живых пользователей, а не только на агрегированные метрики?
• Если завтра придёт регуляторное требование объяснить пользователю, почему он видит именно это, — мы сможем?

## Практический итог

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