Границы применимости LLM в мобильном UI-дизайне

LLM уже умеют быстро собирать мобильные макеты, и на первый взгляд результат часто выглядит убедительно. Кнопки похожи на кнопки, bottom sheet на bottom sheet, экран не разваливается, и его можно показать на обсуждении. Но на практике это всего лишь аккуратный черновик, который ещё нужно как следует доработать: посмотреть компоненты, состояния, навигацию, safe area, длинные тексты и поведение на маленьком экране.

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

Привет, Хабр! Меня зовут Равиль Галеев. Хочу показать, как поменять свой подход к мобильной разработке при появлении ИИ-инструментов: что остаётся за специалистом, какие задачи можно ускорить, а где всё равно нужны опыт, проверка и понимание контекста.

Какие подходы я сравнивал

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

• Plugin-сценарии с Figma — дополнительный слой для работы с контекстом, скриншотами и файлом.

• Прямое подключение через Figma MCP — ближе к самому макету, но без удобной обвязки;

• Сборка концепта из компонентов в веб-интерфейсе.

Разные plugin-сценарии  во время прогона вели себя примерно одинаково. Поэтому я не буду делать вид, что один из них принципиально лучше собирал мобильные макеты. Для этого разбора важнее не соревнование моделей, а сам сценарий работы. А вот прямое подключение через Figma MCP ощущалось иначе.

Разница проявлялась не столько на уровне модели, сколько на уровне обвязки. Например, в Codex есть отдельный Figma plugin bundle со skills, командами и рабочим слоем вокруг use_figma, get_metadata, get_screenshot, create_new_file, search_design_system, get_libraries, generate_figma_design. В текущем OpenCode Figma подключена как прямой remote MCP server на mcp.figma.com, без отдельного Figma plugin в списке плагинов. Поэтому raw MCP в OpenCode слабее именно как рабочий контур.

Где LLM даёт практическую экономию

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

Например:

• добавить новую кнопку, ведущую на уже существующий экран;

• добавить ещё одну точку входа в известный flow;

• сделать локальную доработку существующего состояния;

• собрать быстрый концепт перед обсуждением идеи.

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

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

Где начинается расхождение с реальным мобильным макетом

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

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

Здесь повторяется один и тот же паттерн. LLM хорошо срисовывает поверхность.

Для мобильных экранов это значит следующее:

• кнопка похожа на вашу кнопку, но это ещё не реальный компонент;

• bottom sheet похож на ваш bottom sheet, но не факт, что там учтены состояния;

• экран похож на продукт, но не факт, что у него правильная навигация, safe area и соседние стейты.

Я обычно проверяю несколько вещей:

Компоненты: это реальный компонент или просто очень похожий прямоугольник с текстом?

Состояния: что ломается чаще всего: Loading, empty, error, disabled, длинные тексты, клавиатура, safe area?

Поведение: что важно именно для мобилки? Как работают жесты, навигация, sticky-элементы, зоны клика, поведение на маленьком экране?

Логика: что показывает дизайн-ревью? AI смог продолжить форму, но промахнулся и предложил  другой паттерн или другую продуктовую логику.

Что показал внутренний сервис из компонентов

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

Для обсуждения идеи это удобно. Но такой концепт живёт в веб-интерфейсе, и его перенос в чистый мобильный макет всё равно потребует отдельной работы. Нужно будет проверить размеры экранов, safe area, bottom sheet, навигацию, жесты, текстовые переполнения и соседние состояния.

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

Почему новые фичи требуют участия дизайнера

На микрофичах AI чувствует себя уверенно, потому что там чаще всего не нужно придумывать ничего нового. Достаточно продолжить существующую логику экрана.

Новая фича с новыми экранами — это другой класс работы. Здесь нужно ответить на более дорогие вопросы:

• какой паттерн вообще нужен;

• что здесь главное для пользователя;

• как новый экран встраивается в мобильный flow;

• какие состояния обязательны с первого дня.

Здесь AI начинает делать то, что умеет лучше всего: собирать правдоподобное из уже виденного. Внешне это может выглядеть убедительно. Но выбран ли правильный паттерн именно для нового мобильного сценария, уже не очевидно.

Иллюстрации и сцены: отдельное ограничение

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

Поэтому он оказывается действительно полезен на этапе поиска. Если в библиотеке уже есть подходящий визуальный материал, он заметно ускоряет поиск, отбор и первый черновик. Но сгенерировать новую сцену точно в стилистике брендбука пока сложно. Можно подойти очень близко, но почти всегда проявляется артефакт: не тот смысловой центр, лишние объекты, не та логика линий, не тот уровень детализации или слишком общий stock-like вид.

Вот пример иллюстрации, полностью сгенерированной AI. Почти все компоненты соответствуют, но такую карту мы не выпускали.

Для стабильного попадания в стиль по-прежнему требуется отдельная настройка.

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

Почему дизайн-ревью остаётся обязательным

Есть соблазн думать, что если AI уже собрал визуально аккуратный экран, дальше осталась только косметика. Но на мобилке это почти никогда не так.

Здесь дизайн-ревью не формальность. Он ловит вещи, которые AI пропускает чаще всего:

• правильный ли выбран паттерн для мобильного сценария;

• не появилась ли лишняя сущность вместо существующего компонента;

• что будет с экраном в соседних состояниях;

• не ломается ли логика навигации, жестов и иерархии.

К примеру, при генерации можно легко упустить макет в тёмной теме или то, что при генерации макета не учитывалось масштабирование экранов на разных мобильных устройствах или планшетах. 

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

Итоговый вывод

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

После прогонов я сформулировал для себя несколько рабочих правил:

1. Смело подключаю AI на микрофичи и доработки существующих мобильных экранов.

2. Использую AI для первого обсуждаемого артефакта, а не как обещание финального макета.

3. Не путаю аккуратную визуальную копию с реальной компонентной сборкой.

4. Для новых фич сразу закладываю участие дизайнера.

5. Для сцен и иллюстраций сначала ищу и переиспользую существующее, а не надеюсь на идеальную генерацию с нуля.

6. Дизайн-ревью не пропускаю даже после удачного первого черновика.

Подробнее про подходы к Figma MCP, AI-инструментам и визуальным пайплайнам можно посмотреть в источниках ниже.

Источники

1. Личная практика и наблюдения при сборке мобильных макетов.

2. Figma — Design systems and AI: Why MCP servers are the unlock.

3. Figma — The TL;DR on MCP: Why context matters and how to put it to work.

4. Figma — Workflow lab: Expanding the canvas with Figma MCP.

5. Figma — Agents, meet the Figma canvas.

6. Builder.io — Announcing Visual Copilot 1.0.

7. Anima Docs — Anima MCP.

8. GitHub — Getting 403 on FrameLink MCP call even though MCP shows as connected.

9. GitHub — Implement MCP-spec OAuth for server authentication.

Благодарность

Большое спасибо Илье, Родиону Беловицкому и Павлу Степанову, которые помогли мне нащупать границы применимости LLM в мобильном UI-дизайне.