Прототип за два часа: AI-воркфлоу который я использую на каждом проекте

Прототип, который раньше занимал два дня, теперь делается за два часа. Это не магия и не маркетинг AI-инструментов — это конкретный воркфлоу, в котором каждый шаг сокращён в 3–5 раз за счёт правильного использования генеративных моделей, готовых компонентов и Figma.

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

Эта статья — разбор того, что реально работает на проектах. Без обещаний «прототип одним промптом» и без рекламы конкретных сервисов. Воркфлоу описан так, чтобы его можно было собрать из любых инструментов, которые есть под рукой.

---

## Зачем вообще ускорять прототипирование

### Прототип — это не артефакт, а инструмент мышления

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

• Проверить гипотезу о решении до того, как в него вложен бюджет
• Показать стейкхолдерам не описание, а опыт
• Найти дыры в логике до встречи с разработкой
• Дать пользователю кликнуть и понять, как он реально себя поведёт

Чем быстрее прототип появляется, тем больше итераций влезает в проект. А качество дизайна определяется именно количеством итераций — не вдохновением и не талантом.

### Что меняет AI в этой логике

AI не делает прототип за тебя. AI убирает три самых дорогих по времени этапа:

• Стартовую инерцию. Не нужно сидеть перед пустым артбордом. Первый драфт появляется за 10 минут.
• Рутину наполнения. Тексты, имена, числа, описания карточек, состояния — больше не блокеры.
• Поиск референсов и решений. AI отлично работает как ассистент-куратор, если задавать правильные вопросы.

Дизайнер остаётся в роли архитектора решения и редактора результата. Это важно — без редактуры AI-прототип скатывается в средний универсальный шаблон.

---

## Что должно быть готово до того, как открыть Figma

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

### Минимальный бриф самому себе

Перед стартом отвечаю на пять вопросов письменно — занимает 10–15 минут:

• Какую задачу пользователь должен выполнить в этом прототипе?
• Что должно произойти, чтобы я считал прототип успешным?
• Какие 1–2 экрана точно ключевые, а какие — обвязка?
• Какой уровень детализации нужен: lo-fi для логики или hi-fi для презентации?
• Кто будет смотреть и что у него должно щёлкнуть в голове?

Без этого AI становится бесполезным — он генерирует «что-то про продукт», а не решение под конкретную задачу.

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

• Начинать с поиска вдохновения в Dribbble. Заберёт час и собьёт фокус на визуал вместо логики.
• Делать сразу hi-fi. Дорого править, психологически тяжелее выбрасывать.
• Просить AI «придумать экран». Без контекста выходит обобщённый мусор. Контекст — твоя работа.
• Игнорировать существующую дизайн-систему. Прототип, который не ложится на систему, нельзя передать в разработку — он переделывается заново.

### Чеклист готовности к прототипу

• Сформулирована задача пользователя одним предложением
• Понятно, что такое «успех прототипа»
• Выбран уровень детализации (lo-fi / mid-fi / hi-fi)
• Есть доступ к UI-киту или дизайн-системе
• Понятно, кому показываешь и зачем

Если хотя бы один пункт пуст — не открывай Figma. Сначала закрой пробел, потом стартуй.

---

## Шаг 1: Структура флоу через AI-диалог (20 минут)

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

### Как я строю промпт

Не одним сообщением, а серией. Сначала контекст, потом задача, потом ограничения, потом просьба. AI работает кратно лучше, когда видит цепочку, а не вопрос в вакууме.

Условный пример (адаптируй под свой проект):

1. «Я делаю фичу X в продукте Y. Аудитория — Z. Бизнес-цель — A.»
2. «Главная задача пользователя в этой фиче — B. Сценарий начинается с C, заканчивается D.»
3. «Перечисли минимальный набор экранов и состояний, нужных для этого флоу. Для каждого — цель экрана и ключевое действие.»
4. «Какие edge cases я могу упустить? Где обычно ломается этот тип флоу?»

На выходе получается карта из 5–9 экранов с пометками. Её я переношу в FigJam или прямо в комментарии к будущим фреймам.

### Что спросить у AI помимо самого флоу

На этом же шаге, пока контекст загружен в модели, выжимаю максимум:

• Какие данные нужны на каждом экране и откуда они приходят
• Какие пустые состояния и ошибки обязательны
• Какие микро-копи (кнопки, лейблы) подходят под тон продукта
• Какие 2–3 альтернативных решения этого флоу существуют в индустрии

Это экономит ещё час работы позже — когда сидишь над пустой кнопкой и думаешь, как её назвать.

---

## Шаг 2: Каркас в Figma (30 минут)

Дальше иду в Figma и собираю wireframe-каркас по карте экранов. Принципиально без визуала — серые блоки, плейсхолдеры, базовые компоненты из системы.

### Почему именно каркас, а не сразу hi-fi

Каркас отвечает на один вопрос: «логика держится?». Hi-fi отвечает на десять вопросов сразу, и ни на один — нормально. Если перепрыгнуть этап каркаса, ты будешь править расстановку блоков уже с цветом, тенями и фотографиями — а это в 3–5 раз дороже по времени.

### Что делаю руками, что делегирую AI

Руками:

• Расстановка экранов на холсте по логике флоу
• Базовая иерархия каждого экрана (что главное, что вторичное)
• Связи между экранами стрелками

AI/плагинами:

• Наполнение текстом-рыбой, которая похожа на правду (не Lorem Ipsum, а реалистичные имена, суммы, статусы)
• Генерация повторяющихся карточек со вариативным контентом
• Иконки-заглушки под смысл, а не «первая попавшаяся»

### Анти-паттерны на этапе каркаса

• Тратить время на сетку и отступы. На этом этапе они переделаются ещё дважды.
• Делать все экраны одинаково детально. Ключевые — детально, обвязка — почти схемой.
• Использовать настоящий контент. Реальные тексты тянут в редактуру и съедают час.

---

## Шаг 3: Прогон сценария и диагностика (20 минут)

Готовый каркас почти всегда выглядит логично — пока ты сам по нему не пройдёшь от первого клика до последнего. Этот шаг находит 70% дыр до того, как их найдёт стейкхолдер.

### Как прогонять сценарий

Ставлю себя на место пользователя из брифа и иду по флоу, проговаривая вслух (или в заметках):

• Что я вижу
• Что хочу сделать
• Куда жму
• Что ожидаю увидеть дальше

Каждый разрыв между «ожидаю» и «вижу» — это баг прототипа.

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

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

Эти пять вопросов вытаскивают почти все типичные пропуски: отсутствующие empty states, тупиковые экраны, нелогичные переходы.

### Куда подключить AI на диагностике

Скармливаю модели скриншоты или описание флоу и прошу:

• Найти противоречия между шагами
• Перечислить состояния, которых не хватает
• Сформулировать, что в этом флоу мог бы не понять новичок

AI здесь работает как второй дизайнер на ревью — без эго, без усталости и без «ну вроде норм».

---

## Типичные ошибки, из-за которых прототип буксует

### Дизайнер делает прототип за себя, а не за пользователя

Самый частый сбой. Прототип получается красивым, но проверяет вкус автора, а не гипотезу. Лекарство — вернуться к брифу и переспросить себя: «какой ответ я хочу получить от этого прототипа?».

### AI ведёт, дизайнер идёт

Если ты соглашаешься с первым вариантом модели, прототип становится средним по индустрии. AI хорошо генерирует знакомое, плохо — специфичное. Специфичное — твоя зона.

### Прототип отрывается от дизайн-системы

Сделать «вне системы» быстрее на пару часов. Передать в разработку — дороже на неделю. Если в продукте есть UI-кит, прототип собирается из него с первой минуты, даже на этапе каркаса.

### Слишком много экранов

Прототип на 30 фреймов почти всегда означает, что ты прототипируешь продукт, а не гипотезу. Нужны 5–9 экранов, остальное — обвязка ссылками или статичными картинками.

---

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

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

## Продвинутые сценарии: когда базового воркфлоу не хватает

Простой прототип за два часа закрывает 70% задач. Оставшиеся 30% — это специальные случаи, в которых стандартный путь буксует. Их полезно знать заранее, чтобы не строить процесс с нуля под каждый.

### Сценарий 1: Прототип для исследования с пользователями

Здесь дешёвый каркас не подходит — респондент будет реагировать на «кривые квадраты», а не на гипотезу. Но и фотореалистичный hi-fi не нужен.

Что меняется в воркфлоу:

• Тексты пишутся настоящие, не «правдоподобная рыба». Респонденты читают и принимают решения именно по ним.
• Состояния ошибок, пустых данных и загрузки — обязательно. Их специально проверяют на интервью.
• Кликабельность только по ключевому пути. Остальное — заглушка с подписью «недоступно в прототипе».

AI на этом сценарии помогает быстро сгенерировать варианты микрокопии под разные тоны и потом сократить их до одного.

### Сценарий 2: Прототип для защиты бюджета

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

Что добавляется:

• Один слайд с проблемой в цифрах из аналитики.
• Один экран с предлагаемым решением.
• Один сценарий «как это сработает» на одном пользователе.

Если показываешь больше — теряется фокус, обсуждение уходит в детали.

### Сценарий 3: Прототип в чужой дизайн-системе

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

Порядок такой:

1. Полчаса на разбор системы: токены, основные компоненты, паттерны навигации.
2. Прототип сразу из библиотеки, даже если это медленнее в моменте.
3. Если компонента не хватает — собираешь его из существующих токенов, а не приносишь снаружи.

AI здесь полезен, чтобы быстро описать словами правила системы по скриншотам — это экономит чтение документации.

---

## Командный и AI-контекст

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

### Что закладываю в прототип под команду

• Подписи на сложных экранах. Одно предложение: что это за состояние и когда оно появляется. Разработчик не должен догадываться.
• Список открытых вопросов прямо на холсте. Не в чате, не в задаче — рядом с экраном, к которому относится.
• Версионирование по дням, а не по «final_v2». Достаточно даты в названии страницы.

### Как делю работу с AI в команде

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

Простое правило: всё, что сгенерировано и не отрефлексировано вручную, помечается. Серый фон, тег ai-draft, отдельный слой — неважно. Важно, что это видно.

---

## Как проверять качество прототипа

Прототип «работает» — это не «открывается и кликается». Это набор измеримых признаков.

### Чеклист готовности

• Каждый ключевой экран отвечает на вопрос «что здесь делает пользователь?» одним глаголом
• Есть три состояния каждого важного экрана: пустое, нормальное, с ошибкой
• Путь от первого клика до результата помещается в одну схему
• На холсте нет экранов, к которым не ведёт ни одна стрелка
• Тексты на ключевых экранах прочитаны вслух и не спотыкаются
• Видно, какие компоненты — из дизайн-системы, какие — заглушки

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

• Какую гипотезу проверяет этот прототип и как мы поймём, что она подтвердилась?
• Что в этом флоу нельзя реализовать в текущем спринте и почему?
• Какие данные нужны на каждом экране и откуда они берутся?
• Где в прототипе ты как разработчик не понимаешь, что должно произойти?

Если на любой из вопросов ответ «не знаю» — это не провал, это следующая задача.

---

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

Главная ошибка на показе — водить курсором по макету и рассказывать, что нарисовано. Команда и так это видит.

Полезнее показывать три вещи:

1. Гипотезу. Что мы хотим узнать или подтвердить.
2. Развилки. Где было два пути и почему выбран этот.
3. Зоны риска. Что в прототипе слабее всего и где ждём обратной связи.

Такой показ занимает 10 минут вместо часа и оставляет команду с конкретными задачами, а не с общим «вроде красиво».

## Анти-паттерны, которые я раз за разом ловлю

Прототипирование с AI ломается не на сложных кейсах, а на одних и тех же привычках. Их легче заметить у других, чем у себя, поэтому держу список перед глазами.

### «Сначала соберу, потом подумаю»

Самый частый. Открываешь Figma, накидываешь блоки, через сорок минут понимаешь, что не знаешь, какую гипотезу проверяешь. Дальше включается достройка задним числом: придумываешь объяснение тому, что уже нарисовано. AI это только усиливает — модель послушно подбросит ещё пять вариантов того, что вообще не нужно.

Лечится одним вопросом перед первой рамкой: что я хочу, чтобы команда поняла, посмотрев на это через два часа.

### Полировка вместо проверки

Прототип ещё не отвечает на главный вопрос, но уже подобраны иконки и тени. На ревью обсуждают радиусы, а не логику. Это удобный способ спрятаться: визуально готово, значит как будто работа сделана.

Правило простое: пока не пройден сквозной сценарий хотя бы один раз, никакой визуальной шлифовки.

### Слепое доверие к AI-черновику

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

### Прототип без точки выхода

Кликаешь, кликаешь, и в какой-то момент сценарий заканчивается ничем: ни успеха, ни ошибки, ни возврата. Тестировать такое бессмысленно — пользователь просто упрётся в пустоту, а ты решишь, что это «проблема пользователя».

### Один прототип под все задачи

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

Лучше три коротких прототипа под три аудитории, чем один универсальный.

### «AI сделает всё, я только соберу»

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

---

## Финальный чеклист перед тем, как показать прототип

Прохожу его буквально пунктами, не по памяти. Память врёт в пользу того, что уже сделано.

• Сформулирована одна гипотеза, ради которой собран прототип
• Есть сквозной сценарий от входа до результата без обрывов
• Все ключевые экраны имеют три состояния: пустое, нормальное, ошибка
• AI-сгенерированные куски визуально отделены от ручных решений
• На холсте нет «висячих» экранов без входа и выхода
• Подписаны спорные места и открытые вопросы рядом с экранами
• Тексты прочитаны вслух, без спотыканий и канцелярита
• Понятно, что из дизайн-системы, а что — заглушка
• Прототип открывается на том устройстве, на котором его будут смотреть
• Заранее ясно, кто и какое решение примет после показа

Если по любому пункту ответ «потом» — лучше отложить показ на час и закрыть, чем выносить сырое.

---

## Вопросы для ревью самому себе

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

### По сути

• Что изменится в продукте, если гипотеза подтвердится? А если нет?
• Какой самый дешёвый способ проверить это без прототипа вообще?
• Что в этом флоу я не решил, а замаскировал красивым экраном?

### По форме

• Где я выбрал визуал вместо логики, потому что так быстрее?
• Какие три экрана можно выкинуть, не теряя смысла?
• Что я не смогу объяснить разработчику без оговорки «ну тут условно»?

### По AI-части

• Какие решения я принял сам, а какие просто принял от модели?
• Что из сгенерированного я бы не нарисовал руками, если бы рисовал с нуля?
• Где AI закрыл дыру в моём понимании задачи, которую надо было закрыть ресёрчем?

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

---

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

Два часа на прототип — это не про скорость рук и не про то, что AI «делает за тебя». Это про дисциплину постановки задачи и жёсткое отделение того, что нужно проверить, от того, что хочется нарисовать.

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

Если убрать одно из трёх, два часа превращаются в два дня, а прототип — в красивую картинку, по которой невозможно принять решение.