Автоматизация в отделе дизайна: аналитика, прототипы и сервис без Figma
Это вторая часть цикла об автоматизации дизайн-процессов с помощью искусственного интеллекта. В предыдущем материале речь шла о главном принципе: внедрение нейросетей начинается не с выбора инструмента, а с детального понимания самого процесса.
Теперь - о практическом кейсе. Как мы использовали ИИ для проверки аналитики, создания прототипов и вёрстки интерфейсов, а также почему полноценный сервис удалось собрать практически без постоянной работы в Figma.
Один проект - два сценария работы
Перед командой стояла задача создать масштабный сервис для фотографов. Он состоял из нескольких больших частей, и именно это позволило проверить сразу два подхода к автоматизации.
Первая часть - внутренний сервис, личный кабинет для сотрудников и рабочих процессов. Здесь на первом месте были функциональность, логика и скорость работы.
Вторая - публичный кабинет для клиентов. Он тоже являлся частью общей системы, но должен был выглядеть презентабельно, аккуратно и визуально убедительно.
Мы работали над направлениями параллельно. Клиентскую часть дизайнеры сначала собирали вручную в виде прототипов. Внутренний сервис я решила создавать с помощью нейросети, опираясь на готовую бизнес-аналитику.
Нейросеть как дополнительный аналитик
К моменту начала работы аналитическая документация уже была подготовлена специалистами. Однако я решила не ограничиваться обычной вычиткой и подключила к проверке нейросеть.
Документ передавался частями: отдельная страница, функциональный блок или небольшой раздел. Затем формулировался запрос примерно следующего содержания:
- проанализировать бизнес-решение в сравнении с конкурентными сервисами;
- проверить понятность и кликабельность интерфейса;
- оценить решение с точки зрения UI/UX;
- найти критические проблемы;
- определить, что упущено;
- предложить возможные улучшения.
Важный нюанс - нейросеть не должна была самостоятельно менять документацию. Её задача заключалась в подготовке рекомендаций. Полученный список сортировался по приоритету: критичные замечания, некритичные проблемы, небольшие недочёты и идеи для дополнительного рассмотрения.
После этого я самостоятельно принимала решения: какие рекомендации использовать, какие отклонить, а какие отправить на обсуждение. Затем просила обновить документацию с учётом выбранных комментариев. Только после этого блок передавался в работу над интерфейсом.
Такой подход оказался полезным по двум причинам. Во-первых, некоторые идеи действительно не были замечены первоначально. Во-вторых, проверка занимала значительно меньше времени, чем самостоятельное чтение и анализ документа объёмом около пятидесяти страниц.
При этом полностью доверять результатам ИИ нельзя. Особенно на первых этапах приходилось тщательно перепроверять все предложения: нейросеть могла неверно трактовать бизнес-логику, неправильно понять роль отдельного пользователя или предложить решение, не подходящее конкретному продукту.
Почему аналитику нужно делить на части
Передать нейросети всю документацию одним большим файлом кажется удобным, но на практике это снижает качество результата. Модель начинает терять контекст, смешивать разные сценарии и выдавать слишком общие рекомендации.
Гораздо эффективнее работать небольшими блоками. Каждый раздел получает собственную задачу, контекст и критерии проверки. Так проще контролировать качество, находить ошибки и понимать, к какому месту документа относится конкретное замечание.
Работу я выполняла в Claude Code через терминал. Для этого достаточно было подготовить локальную папку, добавить туда:
- актуальную аналитическую документацию;
- брендбук;
- используемые шрифты;
- дополнительные материалы по проекту.
Чтобы задать визуальное направление, дизайнер вручную подготовил всего одну десктопную страницу шириной 1920 пикселей. На ней были показаны основные формы, размеры, шрифтовая пара, принципы отступов и общий характер интерфейса.
Этого оказалось достаточно, чтобы нейросеть получила визуальную отправную точку.
Перенос интерфейса из Figma
Дальше я последовательно двигалась по сайдбару: открывала один пункт, передавала соответствующий блок аналитики и формировала задачу на создание прототипа.
Через MCP Figma нейросети передавалась ссылка на нужный фрейм. Запрос был простым: использовать макет как визуальную основу и собрать аналогичный прототип в локальном проекте.
Первые результаты выглядели плохо. Интерфейс мог быть функциональным, но визуально заметно отличался от исходника: нарушались пропорции, менялись отступы, неправильно отображались состояния элементов, а иногда терялась сама логика композиции.
Мы проверили несколько вариантов передачи информации.
Дизайн-токены
Сначала предпринималась попытка выгрузить токены и скрипты макета, а затем передать их через HTML-плагин. Однако бесплатной версии инструмента хватало только на один макет. Покупать отдельный доступ для каждого экрана не хотелось, а полного совпадения всё равно добиться не удалось.
Скриншоты
Следующим вариантом стали скриншоты. Они помогали объяснить общую композицию, но не передавали структуру интерфейса, реальные размеры и взаимосвязи элементов. В результате вёрстка оставалась приблизительной.
Пошаговый диалог
Наиболее эффективным оказался третий способ - организовать работу как полноценный диалог. Я попросила нейросеть не угадывать недостающие детали, а задавать вопросы и запрашивать дополнительные материалы.
Скриншоты были вынесены в отдельный документ. Через MCP передавались дополнительные данные, после чего модель анализировала макет более внимательно: учитывала размеры, расположение блоков, типографику и визуальные зависимости между элементами.
Когда результат стал приемлемым, я попросила сохранить весь рабочий процесс в отдельном файле формата Markdown. Этот документ стал внутренней инструкцией: на следующих страницах нейросеть должна была повторять те же шаги.
Затем из накопленного опыта был сформирован отдельный навык для повторного использования в других проектах - перенос макетов из Figma в вёрстку с максимальным визуальным соответствием на десктопе шириной 1920 пикселей.
После создания первого полноценного экрана нейросеть уже лучше понимала визуальную систему продукта. Последующие страницы собирались быстрее и требовали меньше исправлений.
Адаптивность закладывали сразу
Отдельное преимущество такого подхода - возможность думать об адаптивности ещё на этапе прототипирования. Не приходилось сначала создавать только десктопную версию, а затем отдельно объяснять, как она должна перестраиваться на меньших разрешениях.
Для каждого блока сразу определялись:
- поведение колонок;
- порядок элементов на мобильном экране;
- точки перелома;
- минимальные размеры кнопок и полей;
- правила переноса текста;
- скрытие или замена второстепенных элементов.
Это снижало риск типичной ситуации, когда десктопный макет выглядит хорошо, но при адаптации требует фактически полной переделки.
Как проверяли готовые страницы
Каждый экран проходил несколько этапов контроля. Сначала проверялась соответствующая бизнес-логика: все ли сценарии пользователя учтены, правильные ли статусы отображаются, не потерялись ли обязательные действия.
Затем выполнялась визуальная проверка. Сравнивались:
- размеры блоков;
- отступы;
- шрифты;
- цвета;
- состояние элементов;
- расположение панелей;
- поведение длинных текстов;
- адаптивные версии.
После этого проводилась проверка в браузере. Важно было убедиться, что макет не только похож на исходник, но и корректно работает при реальных данных, разных разрешениях и нестандартных сценариях.
Как показывать результат клиенту без Figma
Для демонстрации результата мы использовали не статичный макет, а готовую HTML-страницу. Клиент мог открыть её в браузере, перейти между разделами, проверить состояния элементов и оценить общий пользовательский путь.
Такой формат оказался нагляднее обычного прототипа. Видно не только расположение блоков, но и то, как ведёт себя будущий продукт: открываются ли списки, работают ли кнопки, меняется ли контент, как интерфейс реагирует на действия пользователя.
Кроме того, HTML-прототип позволяет быстрее обнаруживать проблемы. То, что на картинке кажется понятным, в рабочем сценарии иногда оказывается неудобным. Поэтому интерактивная демонстрация помогает обсуждать не абстрактный макет, а реальный пользовательский опыт.
Правки через GitHub
Ещё один важный эффект - изменить прототип мог не только дизайнер. Все материалы хранились в репозитории, поэтому к работе подключались разработчики, аналитики и другие участники команды.
Правки проходили через привычный процесс:
1. специалист создавал отдельную ветку;
2. вносил изменения;
3. описывал задачу;
4. отправлял результат на проверку;
5. команда обсуждала решение;
6. после согласования изменения объединялись с основной версией.
Это сделало прототип частью общего рабочего процесса, а не изолированным файлом, который существует только у дизайнера.
Второй сценарий: перенос готовых прототипов
Параллельно мы проверяли и более привычный вариант - перенос уже созданных прототипов из Figma в HTML и CSS.
В этом случае нейросеть использовалась не для самостоятельного поиска решения, а как исполнитель. Ей передавались готовые макеты, комментарии, шрифты, изображения и требования к поведению элементов.
Такой подход был быстрее для страниц, где визуальная концепция уже полностью утверждена. Однако он требовал качественно подготовленных исходников. Если в макете отсутствовали состояния, не были описаны правила адаптации или использовались неподготовленные изображения, нейросеть начинала додумывать детали.
Получается, что автоматизация не устраняет необходимость в дизайне и аналитике. Она переносит часть ручной работы на этап подготовки исходных данных.
Где нейросеть пока проигрывает
Лучше всего ИИ справлялся с интерфейсами, где есть повторяемые элементы, понятная структура и строгие правила. Личные кабинеты, таблицы, формы, каталоги и административные панели подходят для такого подхода особенно хорошо.
Сложнее обстоят дела с креативными контентными сайтами. Там важны нестандартная композиция, эмоциональная подача, выразительная типографика, неожиданные переходы и визуальная идея.
Нейросеть способна собрать аккуратный и технически корректный вариант, но часто делает его слишком предсказуемым. Она стремится к знакомым паттернам, безопасным отступам и стандартным решениям. В результате интерфейс может быть удобным, но не обладать характером.
Поэтому для имиджевых проектов роль дизайнера остаётся ключевой. ИИ можно использовать для быстрых итераций, технической подготовки и проверки гипотез, но творческое направление по-прежнему должен задавать человек.
Что изменилось в работе команды
Главный результат эксперимента - не отказ от Figma как таковой. Гораздо важнее то, что дизайн перестал быть отдельным этапом, оторванным от аналитики, разработки и проверки.
Теперь процесс выглядит более последовательно:
- аналитика дробится на функциональные блоки;
- нейросеть помогает искать противоречия и недостающие сценарии;
- дизайнер задаёт визуальное направление;
- ИИ переносит правила на повторяемые экраны;
- адаптивность продумывается заранее;
- прототип сразу становится интерактивным;
- команда обсуждает изменения в репозитории.
При этом окончательное решение остаётся за специалистами. Нейросеть ускоряет подготовку вариантов, но не отвечает за продуктовую стратегию, приоритеты и качество пользовательского опыта.
Итоги
Автоматизация дала наибольший эффект там, где процесс удалось описать правилами. Чем понятнее структура данных, требования к интерфейсу и критерии готовности, тем полезнее становится ИИ.
Самыми важными выводами стали несколько принципов:
1. Не стоит загружать нейросети всю документацию целиком - лучше работать небольшими блоками.
2. ИИ эффективнее использовать для рекомендаций, а не для безусловного принятия решений.
3. Один качественно подготовленный экран помогает задать визуальные правила для всего проекта.
4. Скриншоты, инструкции и рабочие сценарии нужно хранить отдельно и переиспользовать.
5. Адаптивность следует продумывать одновременно с десктопной версией.
6. HTML-прототип часто полезнее статичного макета для обсуждения с клиентом.
7. Креативные задачи всё ещё требуют сильного дизайнерского участия.
В итоге сервис удалось собрать без постоянной ручной работы в Figma, но не без дизайна, аналитики и контроля. Инструменты ускорили производство интерфейсов, однако качество по-прежнему определялось тем, насколько хорошо команда понимает задачу и умеет формулировать требования.
