AI против Figma: как спроектировать первый вход в B2B SaaS с помощью генеративных моделей

К 2025 году генеративные инструменты выросли не только по качеству результата, но и по удобству для дизайнеров (и речь не только про генерацию UX-концептов для Хабра). Я много экспериментирую с AI-UI и вижу, что решение практических UX-задач стало заметно проще.

Уже сейчас можно быстрее получить понятный lo-fi прототип в виде изображения, а дальше выбрать, как с ним работать: передать фронтенд-разработчику, прогнать через Lovable, Cursor или v0, либо довести до идеала в Pixso или Figma.

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

Какую проблему мы решаем?

Так как мне ближе стартап-контекст, берём типичную ситуацию: есть фаундер и full-stack-разработчик. В голове есть общее представление о будущих экранах MVP, но без глубины: состояния, детали, формулировки, правила, логика ошибок, ветки «пропустить», статусы приглашений и так далее. И часто при этом нет дизайнера, который спокойно всё разложит по полочкам.

Цель эксперимента простая: пройти путь от промпта до экранов, которые не стыдно отдавать в разработку, даже не открывая Figma. Не красивая картинка, а интерфейс, который ощущается как продукт и не ломает доверие пользователя с первого шага.

Что именно мы будем проектировать?

Я беру сценарий «первый вход в B2B SaaS: создание воркспейса и приглашение коллеги». Почему он удобен для валидации моделей? Потому что в нём одновременно сходятся:

скорость получения ценности (time to value),
тревожность пользователя (в B2B люди обычно осторожнее),
базовые enterprise-ожидания (роли, доступы, безопасность),
и простые продуктовые детали (микрокопирайтинг, подсказки, валидация, ветка «сделаю позже»).

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

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

Почему решающим здесь является промпт, а не «вдохновение»?

Качество результата почти всегда зависит от детализации входных данных. Чем конкретнее ввод, тем меньше итераций, меньше потраченного времени, кредитов (инференс API) и нервов.

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

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

В процессе я решил усложнить задачу. Если уж можно разогревать разные модели, почему бы их не сравнить: Gemini 3 Pro, Grok 4.1, DeepSeek 3.2, Claude 4.5, GLM 4.7 и GPT 5.2.

Я взял эти модели, прогрел каждую одним и тем же запросом, затем попросил у каждой промпты для Nano Banana, сгенерировал флоу, а после отдельно задал вопрос-прогноз: какие промпты должны дать лучший результат (при этом реальные результаты генерации моделям не показывались).

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

Старт: задание контекста

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

Фраза для разогрева:

«Как топ-уровневый UX-дизайнер, что ты знаешь о проектировании первого входа в B2B SaaS: создании воркспейса и приглашении коллеги?»

Ответы сразу показывают характер моделей. Я намеренно спрятал их под спойлеры, чтобы самые любопытные могли не погружаться в детали первого ответа.

GLM сказал, что это «отличный вопрос».
Grok внезапно оказался «работавшим» с Notion, Slack и даже Figma.
Gemini решил «сказать прямо» про момент истины.
DeepSeek «точно знает» критический момент этого сценария.
Claude был сухим, минималистичным и явно ориентированным на код.
GPT, в свою очередь, просто «спроектировал бы это вот так».

Если обобщить:

GLM звучит как аккуратная лекция с правильными терминами и попыткой структурировать.
Grok старается быть дерзким и быстрым, любит проценты и «точные» цифры.
DeepSeek говорит языком шагов и проверок, быстро выходя на реальные точки влияния в онбординге: порядок экранов, состояния, подсказки, валидация.
Gemini иногда скатывается в манифесты и эмоции — как будто это презентация, а не рабочий диалог.
Claude даёт спокойные, минималистичные и практичные рекомендации.
GPT стремится быть ближе к «спеке»: целям, ограничениям, безопасности и состояниям интерфейса.