Figma Make и вайрфреймы: где AI реально экономит время 🧩

В Kokoc.tech решили проверить: можно ли ускорить работу с mid-fidelity вайрфреймами и при этом не потерять качество структуры продукта.

Что проверяли:

Figma Make — AI-инструмент, который помогает генерировать структурные прототипы.

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

Как тестировали:

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

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

3. Сгенерировали макет, проверили соответствие функциональным требованиям и структуре, сделали несколько итераций правок через Point and Edit.

Что узнали:

• Вайрфреймы теперь показывают структуру и логику продукта, без отвлечения на визуальные детали;

• Чем больше деталей мы собираем на этапе подготовки, тем меньше итераций нужно для правок;

• В этой работе роль дизайнера смещается в сторону аналитики: важно не просто принять результат от AI, а критически проверить его на соответствие UX-паттернам и пользовательским сценариям;

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

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

Вывод: Figma Make отлично подходит для быстрой генерации mid-fidelity вайрфреймов, экономит время и позволяет команде согласовать структуру с клиентом без лишней работы.

Как превратить аудит в инструмент выбора, а не в приговор.

Когда проект упирается в старую кодовую базу, разговор почти всегда один и тот же:

— Переписываем всё?
— Дорого…
— Но по-другому никак?

Команда Kokoc.tech вместо одного «правильного» ответа сделали иначе — разложили проект на 4 варианта развития и показали клиенту не только технику, но и последствия для бизнеса.

Как это выглядело на практике:
Проект на стеке Bitrix + Vue, работал как SPA. Быстро для пользователя, но с проблемами:

• долгая первоначальная загрузка;
• поисковые системы не видят HTML — критично для SEO.

Команда рассмотрела 4 варианта:

1️⃣ полная переразработка;
2️⃣ вынос фронтенда в отдельный SSR-сервис (Nuxt);
3️⃣ возврат к нативным шаблонам Bitrix;
4️⃣ оптимизация текущего SPA через Prerender.io.

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

В итоге клиент увидел не «совет разработчиков», а таблицу выбора:

• где он быстрее решает текущие боли;
• где экономит на поддержке в будущем;
• какие решения потребуют изменений в бизнесе, а какие — нет.

🔍 Главная польза — решение можно принять, не погружаясь в код.

Финальный вариант оказался гибридным: быстро закрыть SEO через Prerender.io и за 3 месяца вынести фронтенд в Nuxt — оптимально по срокам, бюджету и технологиям.

Если в сложных проектах вы хотите меньше споров и больше осознанных решений — попробуйте матрицу сценариев вместо одного ТЗ. Клиенты это ценят 😉

🔄 Культура улучшений работает только тогда, когда улучшать может каждый

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

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

Что именно сделали:

• создали единый тактический бэклог по всему производству, разбитый по направлениям и стыковым зонам (frontend, frontend + дизайн, frontend + QA и др.);

• закрепили за каждым бэклогом owner’а, отвечающего за приоритизацию и результат;

• сделали бэклоги полностью открытыми — любой специалист может предложить улучшение, даже за пределами своей роли;

• ввели планёрки раз в две недели с руководителем производства: статусы, блокеры, новые инициативы, пересборка приоритетов.

Почему этот подход полезен другим агентствам и командам:

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

📈 Результат — более 200 реализованных улучшений за год: от ускорения CI/CD и унификации линтеров до стандартов документации, запуска внутренней Академии разработки и прозрачных правил работы с клиентскими сметами.

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