Как за 22 часа я собрала полноценный UI-прототип корпоративной системы с помощью ИИ

Всем привет и приятно познакомиться! Меня зовут Азалия Мухаярова, я работаю системным аналитиком в «Технократии» ^[1]. И в этом тексте расскажу вам, как с помощью Figma Make и AI-ассистента сделать рабочий прототип корпоративной системы за 20 с небольшим часов.

Важный дисклеймер: это не идеально выверенный гайдлайн, а скорее рассказ о моем опыте ^[2] и граблях, на которые я наступала, пока собирала прототип, чтобы вы могли избежать моих ошибок, если задумаете провернуть подобное. На этом дисклеймер закончен — Enjoy!

В классическом процессе дизайнер готовит макеты, фронтендер переносит их в код, затем несколько раундов правок. Это рабочая понятная схема, но она требует времени. А если результат нужен уже через пару дней?

Я решила пойти другим путем: с помощью Figma Make сгенерировала интерфейс, экспортировала в код и доработала прямо в IDE с AI-ассистентом. В итоге получился полностью рабочий прототип.

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

Немного контекста о проекте

Это была внутренняя корпоративная система для мониторинга и управления, типичная enterprise-админка с привычным набором функций:

• Авторизация, 2FA

• Личный кабинет с навигационными карточками

• Управление пользователями и ролями

• Реестры сущностей (организации, заявки, записи)

• Детальные карточки с историей изменений

• Настройки системы (технические, параметры)

• Модальные окна для сложных операций

• Система уведомлений

• Светлая и темная тема

Если вы когда-либо работали с CRM, антифрод-системой, бэк-офисом банка, или любой внутренней корпоративной платформой, вам знакома ситуация с кучей страниц, таблиц, форм, а бизнес-логики еще больше.

Инструменты

Этап 0. Подготовка: что именно строим

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

Страницы:

– Логин, 2FA, личный кабинет
– Список пользователей — карточка пользователя
– Список организаций —  карточка организации
– Список заявок —  детали заявки
– Реестр записей — карточка записи
– Список физлиц —  карточка физлица
– Настройки системы
– Мониторинг, отчеты

Роли:

– Администраторы (системный, пользовательский)
– Операторы (старший, младший)
– Менеджеры (старший, младший)

Модальные окна:

– Добавление пользователя
– Добавление сотрудника
– Создание заявки
– Исключение из реестра
– Настройка порогов
– История изменений

и так далее.

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

Этап 1. Фундамент: авторизация и навигация (2 часа)

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

Первым делом я определила цветовую схему. Для светлой темы выбрала акцентный цвет, для темной — контрастные акценты, настроила CSS-переменные и градиентные фоны.

Затем сгенерировала страницу логина с полями для «username» и «password», добавил фирменный стиль и кнопку входа. После этого появилась страница для ввода 6-значного кода двухфакторной аутентификации.

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

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

Этап 2. Управление пользователями (2 часа)

Это был первый «настоящий» CRUD-раздел.  Я описала ИИ задачу примерно так:

«Страница со списком пользователей. Таблица с колонками: ФИО, email, роль, статус, дата создания. Фильтры по роли и статусу. Поиск. Пагинация. Кнопка “Добавить пользователя” с модальное окно и формой».

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

Лайфхак: систему ролей я настроила один раз и потом использовала во всех компонентах. Были два типа ролей — оператор и менеджер, внутри которых разные подроли с разными правами доступа. Так на всех страницах работала одна и та же логика ^[3] проверки прав, и это сильно ускорило работу.

Этап 3. Организации (1,5 часа)

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

В списке организаций есть карточки с названием, идентификатором, типом, статусом, индикаторами использования квот, а в карточка организации — детальная информация, список сотрудников, статистика, кнопка добавления сотрудника.

Первый CRUD-раздел съел больше всего времени, второй оказался примерно вдвое быстрее,
а третий собирался почти без заминок. ИИ уже понимал контекст и использовал готовые компоненты, что сильно ускоряло процесс.

Этап 4. Настройки системы (3 часа)

Этап с настройками системы оказался самым сложным. Здесь generic-подход больше не работал. Нужно было проработать около 30 критериев проверки сгруппированных по уровням (критический/высокий/средний/низкий). Для каждого критерия создавалась карточка с описанием, кодом и цветовой индикацией уровня.

Пришлось также сделать модальные окна настройки порогов (целые числа 1–100), весов (дробные 0.1–2.0), уровней срабатывания. 

А затем, справочник со всеми критериями, с поиском и фильтрацией.

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

Совет: для сложных форм расписывайте каждое поле отдельно, указывайте тип данных, диапазон, валидацию, формат ввода и формат отправки. Чем точнее ТЗ, тем меньше правок потом придется делать.

Этап 5. Реестры и заявки (2,5 часа)

Раздел с реестрами и заявками занял примерно 2,5 часа. Сначала я сделала список заявок со статусами:  «Новая», «В обработке», «Завершена», «Отклонена»; фильтры по дате, статусу, организации и модальное окно с деталями.

Потом настроила главную таблицу системы с записями с сортировкой по уровню риска, фильтрами, пагинацией (10/20/50 записей). 

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

К этому моменту у меня уже были готовые UI-компоненты (таблица, пагинация, фильтры, бейджи), и новые страницы собирались как конструктор.

Этап 6. Физические лица (2 часа)

Раздел с физлицами занял около 2-х часов. Сначала был список с поиском по идентификаторам и ФИО. Карточка физлица показывала личные данные, связанные записи и систему комментариев.

Появились специализированные компоненты:

• Отображение идентификатора — сокращенный формат (1234…5678) с кнопкой копирования

• Отображение номера записи — маскирование средней части 

Эти компоненты переиспользуются на всех страницах, поэтому один раз сделал и везде работает.

Этап 7. Универсальные компоненты (1,5 часа)

Зачем это?

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

Этап 8. Сложный бизнес-процесс: исключение из реестра (4 часа)

Это самая интересная часть. 

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

Я описала ИИ, как должно работать:

Условия отображения кнопки
Кнопка появляется только если запись активна и еще не была исключена. Доступ к ней имеют только «Старшие операторы». Если запись уже исключена, вместо кнопки показывается зеленый текст с датой.

Модальное окно с readonly-блокомСодержит информацию о записи (нередактируемая, на сером фоне). ФИО, идентификатор, уровень, связанные записи и дата отображаются сразу.

Форма исключения

Состоит из 4-х полей. Причина выбирается из dropdown, номер документа — текстовое поле (макс. 32 символа), дата документа — date picker с запретом на будущие даты, документ-основание загружается через drag-and-drop с ограничениями по формату и размеру.

Поведение ^[4] кнопок

Кнопка «Отмена» спрашивает подтверждение, если форма заполнена. «Подтвердить» меняет состояния: disabled, active и loading. Escape работает как «Отмена», а клик по фону не закрывает окно (критическое действие).

Алгоритм отправки

Если есть файл, его сначала загружают и получают URL. Затем отправляется основной запрос с данными формы. В случае успеха появляется toast-уведомление, окно закрывается и данные обновляются. При ошибке ^[5] toast показывает сообщение, окно остается открытым, данные сохраняются.

Вывод

Для критических бизнес-процессов нужно расписывать все: каждое состояние кнопки, каждый сценарий закрытия окна, каждый вариант ответа сервера. ИИ не придумает это за вас, но отлично реализует, если вы опишете.

Этап 9. База данных и документация (2 часа)

Параллельно с UI я попросила ИИ сгенерировать:

• SQL-схему базы данных (примерно 20 таблиц с связями, индексами, ограничениями)

• Функции и триггеры для автоматизации

• Seed-данные для тестирования

• Документацию с описанием API, маппингом полей, примерами запросов

Это не для прототипа, а для команды backend-разработчиков, которая будет реализовывать настоящий API. Передать проект гораздо проще, когда есть не только UI, но и готовая структура данных.

Что получилось за день

Что работает в прототипе 

• Авторизация с 2FA

• Навигация между всеми разделами

• CRUD для всех основных сущностей

• Фильтрация, поиск, пагинация

• Модальные окна с валидацией

• Система ролей и прав доступа

• Светлая и темная тема

• Toast-уведомления

• Загрузка файлов с drag-and-drop

• Адаптивная верстка

Чего нет

• Реальный бэкенд (все на mock-данных)

• Настоящая авторизация (Keycloak)

• Подключение к БД

• Тесты

• CI/CD

Как  это повторить: пошаговая инструкция

1. Начните с архитектуры.

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

2. Настройте проект.

npx create-react-app my-app --template typescript
# или используйте Vite
 [6]

npm install tailwindcss lucide-react sonner @radix-ui/react-dialog
 [6]

3. Определите дизайн-систему

Цвета, шрифты, размеры, радиусы скруглений. Задайте CSS-переменные. Определите светлую и темную тему. Это фундамент, на котором все будет строиться.

4. Начните с оболочки 

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

5. Сделайте первый CRUD-раздел вручную

Именно здесь формируется паттерн, который вы будете повторять ^[7] дальше. Это займет больше всего времени, но задаст темп всей системе. Делаем список, карточку, модальное окно, фильтры, пагинацию.

6. Масштабируйте паттерн

Каждый следующий раздел быстрее предыдущего. ИИ видит существующий код и генерирует консистентные компоненты.

7. Выносите переиспользуемое (по ходу дела)

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

8. Детально описывайте сложные процессы

Сложные сценарии требуют точности. Если это критическое действие, многошаговая форма или загрузка файлов, общего описания недостаточно. Нужно зафиксировать поля, валидацию, диапазоны и состояния интерфейса. Чем конкретнее формулировки, тем стабильнее результат.

9. Документируйте параллельно 

Сразу делайте SQL-схему, описание API и маппинг полей. Это не для прототипа — а для команды, которая будет делать продакшен.

Грабли, на которые я наступила

1. Слишком абстрактные описания

Как не надо:«Сделай страницу управления пользователями»

Как надо: «Таблица пользователей. Колонки: ФИО, email, роль (dropdown из 6 вариантов), статус (активен/заблокирован), дата создания. Фильтр по роли, фильтр по статусу. Поиск по ФИО и email. Пагинация 10/20/50. Кнопка “Добавить” в правом верхнем углу.»

Чем конкретнее пишите — тем меньше итераций правок.

2. Забыла про состояния кнопок

В первой  раз кнопка «подтвердить» была всегда активна. Пришлось отдельно прописывать три состояния: disabled, active, loading.  Теперь делаю это сразу.

3. Не описала поведение ^[8] при закрытии

Модальное окно с заполненной формой — что происходит при нажатии Escape? При клике по фону? При нажатии крестика? Все это нужно описывать явно.

4. Валидация — отдельный разговор

Для каждого поля формы нужно указать: тип данных, обязательность, минимум/максимум, формат ввода, формат отправки, текст ошибки. Иначе получите поле, которое принимает всё подряд.

5. Темизация в конце 

Я добавила темную тему в начале проекта, и это было правильно. Если добавить ее в конце, придется переделывать каждый компонент. CSS-переменные — ваш друг.

Когда этот подход работает

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

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

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

И подходит для проверки гипотез. Если возникает вопрос «а вот так будет удобно?», проще собрать и проверить, чем долго обсуждать.

Когда не работает

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

Со сложными анимациями тоже возникают ограничения. Базовые переходы он делает нормально, но продуманную анимацию всё равно проще и чище собрать руками.

И, конечно, нельзя воспринимать прототип как готовый продакшен.  Mock-данные, безопасность и тесты нужно будет отдельно доводить до ума.

Выводы

В итоге меньше чем за три рабочих дня я получила прототип, на который обычно уходит 2–3 недели команды из дизайнера и фронтендера. Он не идеальный и не готов для продакшена, но позволяет:

– Показать, как система будет выглядеть и работать
– Собрать обратную связь до начала дорогой разработки
– Передать backend-команде четкое ТЗ с визуальными примерами.
– Убедить стейкхолдеров, что проект реально сделать.

Формула проста: ваша архитектура плюс ИИ-генерация плюс детальные описания дают прототип за день.

Figma Make использует модели Gemini 3 Flash/3.1 Pro, Claude Sonnet 4.6/Opus 4.6. В процессе было потрачено примерно 8–10 тысяч токенов.

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

---

Чтобы не пропустить анонс новых материалов подпишитесь на «Голос Технократии» ^[9] — мы регулярно рассказываем о новостях про финтех, стейблкоины и AI, а также делимся полезными мастридами и актуальными событиями.