В Figma есть должность, которой два года назад не существовало: дизайнер модели (model designer). Занимает её Барон Вебстер. До Figma он провёл три года в Replit, до этого работал в Google Creative Lab над Google Lens, Google Assistant и Teachable Machine. В AI-продуктах с 2016 года, когда нейросети ещё сортировали фотографии, а не генерировали код.

В интервью для AI Design Field Guide он рассказал, что делает дизайнер модели и почему привычный дизайн-процесс в AI-продуктах не работает. Мы перевели и адаптировали ключевые идеи.

Что делает дизайнер модели

У Вебстера в Figma два направления работы. Первое: адаптация фундаментальных моделей к проприетарному формату Figma. Базовые модели не понимают, как устроен .fig-файл, и дизайнер модели помогает сократить этот разрыв.

Второе направление интереснее. Вебстер выстраивает процесс, в котором дизайнеры начинают прототипировать AI-фичи до того, как рисуют интерфейс. Его формулировка: «Если ты проектируешь UI для чего-то, с чем не поиграл руками, ты рискуешь проектировать UI для идеального кейса, который не отражает реальное поведение системы».

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

Ктулху в мехе

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

Для этого нужна возможность «манипулировать моделью и прогонять тестовые кейсы в быстром цикле обратной связи, в нативном для материала формате». Существующие инструменты делают это мучительно медленно. Дизайнер не может быстро попробовать разные промпты, посмотреть на сотню ответов модели и понять паттерны поведения. Приходится просить инженера, ждать, получать результат с задержкой.

Нейт Парротт, продуктовый дизайнер в Anthropic (до этого Browser Company), в интервью для того же издания формулирует похожую мысль: «Ты должен надеть шляпу пользовательской эмпатии, но для модели». Модель становится ещё одним стейкхолдером с собственным agency. В отличие от обычного UI, где технология статична, в AI-продуктах модель активно формирует ограничения и возможности.

Уроки Replit: простое решение против красивого

Три года в Replit Вебстер наблюдал, как с каждым релизом пользователи видели новые возможности и тут же начинали хотеть больше, чем модель могла надёжно выдать. Каждая фича показывала пользователям, что теоретически возможно, и создавала спрос на то, что ещё не работает стабильно.

Ключевая история: когда команда строила Replit Agent, инженеры хотели создать сложную систему валидации. Агент собирает приложение, потом делает скриншот, потом другая модель «кликает» по интерфейсу и проверяет, что всё работает. Вебстер предложил проще: «А что если мы просто покажем пользователю результат и попросим его проверить?» Одно решение убрало месяцы инженерной работы. Пользователь и так хочет посмотреть, что получилось.

Большая часть работы в Replit была про «product scaffolding», техническую обвязку вокруг модели. Например, научить модель редактировать код в конкретной строке файла. Через несколько месяцев выходила новая модель, которая умела это из коробки, и вся обвязка становилась мусором. Вебстер делает вывод: чем меньше хардкода вокруг модели, тем дольше проживёт фича.

Парротт из Anthropic называет это «искусством AI-дизайна: решить, когда дать модели свободу действий и когда посадить её в детский стульчик».

Eval'ы как тест-покрытие

В Replit eval'ы использовались редко. Сейчас Вебстер считает их ключевым инструментом. Аналогия с тестами в программировании: eval'ы предотвращают регрессии и показывают, когда настройка ломает что-то в другом месте.

Но есть ловушка. «Допустим, у тебя eval на краткость ответов. Пользователь пишет: «у меня умерла мама». Модель отвечает: «Бывает». По метрике краткости это отличный результат. Но это не то, что нужно пользователю». Решение: набор eval'ов, покрывающих все желаемые характеристики. Эмпатия, уточняющие вопросы, краткость, тон. Не одна метрика, а система.

Вебстер видит будущее за инструментами, которые позволят дизайнерам создавать тестовые кейсы прямо в дизайн-файлах, прогонять сотню ответов за 30 секунд и мгновенно менять системный промпт или модель. И предсказывает новую роль: «eval designer», по аналогии с дизайн-системами. Человек, который строит дашборды для команды, чтобы все понимали, как AI-фичи работают в реальности.

Дизайн поведения

Самый интересный сдвиг, который описывает Вебстер: раньше дизайнер отвечал за «как это работает». Структура информации, пользовательский путь, интерфейсные паттерны. Теперь значительная часть «как это работает» зашита в весах модели, а не в UI. Дизайнер сдвигается к вопросам «где фокусироваться» и «как раскрыть поведение модели пользователю».

Вопрос из зала: «Вы скучаете по обычному дизайну?» Ответ: «Я считаю это дизайном. Просто в другой форме. Ты проектируешь поведение». При этом возвращение к UI-полишу он называет «почти терапевтическим».

Парротт из Anthropic добавляет контекст: в AI-продуктах дизайн часто начинается не с проблемы пользователя, а с возможностей модели. Это переворачивает классический product design, где идут от боли к решению. В AI иногда решение уже есть. Вопрос в том, где оно встретится с потребностью.

Когнитивная атрофия

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

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

На горизонте пяти лет Вебстер ожидает, что работа дизайнера трансформируется так же радикально, как работа разработчика. Его надежда: дизайнеры не скатятся в «просто UI-мейкеров», а сохранят влияние на поведение модели и архитектуру системы.

Мнение Claude

Дизайнер модели это не новая профессия. Это ответ на конкретную проблему: в AI-продуктах дизайнер, который не понимает модель, проектирует фантазии. Красивые экраны для идеальных кейсов, которые разваливаются при столкновении с реальным поведением LLM.

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

Eval designer, model designer, prompt engineer. Названия будут меняться. Суть останется: кто-то должен стоять между моделью и пользователем и понимать обоих.