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 вайрфреймов, экономит время и позволяет команде согласовать структуру с клиентом без лишней работы.

Какие метатеги стоит проверить на своем сайте 

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

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

➡️ Метатеги сайта: полный гайд (Alt, Robots, Canonical, Viewport, Open Graph)

Настроить всё один раз и потом только поддерживать порядок – мы за такой подход! 

Один документ, который спасает проект от переделок

Вместо громоздкого ТЗ начните с ПЗ — «Понимания задачи». Это короткий, живой документ про зачем, а не про как.

Команда бюро Brele сама готовит ПЗ — обычно 1–2 страницы, где фиксирует:

• Контекст — кто клиент и в чём реальная боль
• Цель — не «сделать сайт», а, например, «увеличить онлайн-продажи на 30%»
• Гипотезу — почему выбранное решение сработает
• Решение — формат и ключевые шаги

Результат — что изменится для бизнеса и пользователей

Простой совет

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

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

Почему ПЗ работает:

•

Быстрый старт

— не тратите недели на ТЗ
•

Меньше переделок

— сначала заказчик и подрядчик договариваются о смысле
•

Точная оценка

— понятны сроки и бюджет
•

Вовлечённая команда

— все видят цель, а не список экранов
•

Доверие клиента

— он видит, что исполнитель думает о результате, а не просто «делает задачу»

Реальный эффект

В одном проекте ПЗ помог сэкономить ~12 млн ₽: вместо дорогой разработки маркетплейса запустили MVP и вовремя поняли, что гипотеза работает иначе. Это открытие оказалось в разы дешевле, чем ошибка в продакшене.

Главное правило:

Если в документе больше про «как» — это ТЗ. Если про «зачем» — вы на правильном пути!

Подробнее — в статье «Не ТЗ, а ПЗ: что такое “понимание задачи” и зачем это нужно» 👈

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

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

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

Команда 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 — оптимально по срокам, бюджету и технологиям.

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