Generative UI или почему дизайн-система больше не для людей
Generative UI делает с дизайн-системой странную вещь: она перестаёт быть шпаргалкой, по которой человек собирает экраны, и становится контрактом, по которому экраны собирает модель. Звучит как мелочь. Но на практике это переписывает работу продуктовой команды.
We think that coding agents have now gotten good enough to allow users to become their own forward deployed engineers and more radically customize the software they consume. I'm imagining users designing widely different interfaces for their use cases — perhaps my email client looks more like a task list, and a students' looks more like an events calendar. But these two interfaces likely share some underlying primitives and design decisions that a software team can build and ship.
David Hoang интересно формулирует: дизайн-системы становятся инференс системами: токен, который раньше хранил цвет (--color-primary: #0066FF), теперь должен хранить интент (--color-interactive-primary). Первый говорит «какой цвет», второй — «зачем». Модели во втором случаче гораздо легче решить, в какой ситуации использовать оный. Вы, возможно, замечали эту разницу, когда AI агенту даешь через mcp доступ к фигме: если ваши компоненты имеют осмысленнные названия, то он гораздо лучше справляется с задачей.
На недавнем воркшопе я показывал наши [onsa] исследования в этой области - см видео в аттаче. Пока это не в продакшне, но направление мысли понятно. Я вижу достаточный профит от такого в чат интерфейсе, где длинный хвост возможных запросов юзера - и оттого output-ов - может быть таким, что никогда под каждый чих не отрисуешь UI.
В целом, конечно, это не новая идея: тот же Salesforce со своим constrained app-builder palette делает это с 2014; новое тут только автор: теперь это LLM, а не человек.
Ну и очевидный риск: представьте, как в одной и той же сессии один и тот же аутпут генерится двумя разными наборами компонентов. Боюсь, что юзер даже может почувствовать головокружение :) Поэтому необходим harness, обеспечивающий стандартизацию, и тп.
Мне же интересно, как будет меняться работа продуктовой команды?
1) Очевидно, что дизайн система - как писал выше - становится центральным контрактом. Кнопки, empty стейты и тп — предопределены в каталоге. Если мы раньше в разработке могли чуть отойти от нее - или вообще забить - то тут это а-ля контракт между бэком и фронтом.
2) Возможно, фроентенд разработка выглядит больше как "я сделал новый компонент под <>" и десятки экранов улучшились разом. В принципе, так оно и должно быть в хорошей модульной системе.
Главный челлендж имхо: найти баланс между достаточностью и избыточностью компонентов: при недостаточности - модель выдумывает UI не по гайдлайнам; избыточности - "тупеет" и не может выйти за пределы описанных кейсов.
А теперь то, что мне нравится в этом больше всего
Я как-то рассказывал про работу Эрика фон Хиппель и его концепцию user-centered innovation, суть которой в том, что главные инновации идут не от производителей, а от power/lead юзеров - пользователей с экстремальными потребностями.
Представьте, как ваши power юзеры создают свои компоненты налету, для своих уникальных длиннохвостных потребностей, а вы - по совету AI агента на основе анализа usage статистики, разумеется - потом стандартизируете это в общий каталог и раскатываете на всех.
Главное, что важно отметить в заключение: generative UI — это не когда «AI пишет UI». Это дизайн-система становится API, который модель дергает как тулколл.
Кстати, кто-то уже экспериментирует по сабжу?
Подписывайтесь на Telegram EDU.