Собираем дизайн без дизайнера
Часть 2
предыдущая часть 👆
Есть довольно много способов сгенерировать дизайн через AI и чтобы как-то систематизировать знания, перечислю их, а потом расскажу, какой выбрал я.
Важно добавить, что при выборе решения опирался на такие критерии:
– уже есть продукт в виде бота для приложения, хочется сразу заложить хорошую основу
– важно использовать дизайн не только как экраны для вёрстки, но и как CJM для продакта, будущего дизайнера или AI-дизайнера, чтобы проще было ориентироваться в системе и не пришлось по 10 раз разжёвывать, как работает функционал
– поиск сервиса зависит от лучших AI-решений в области дизайна (nano banana pro, например)
– дополнительно нужно учесть соотношение цена/качество
– и поправку на то, что у меня будет нативное IOS-приложение
Теперь если пройтись по инструментам, то решения можно разделить на 2 категории + гибридный вариант: генерация дизайна сразу в коде либо через промежуточный слой в виде figma или figma-подобных сервисов.
Под генерацию в коде подходит
claude code + frontend skill (можно установить через /plugins) + MCP figma
codex + frontend skill
antigravity + frontend skill + MCP для google stitch
lovable
Нужные скиллы можно поискать на skills.sh
В моем случае последнее решение не подходит, потому что нельзя создать нативное IOS-приложение. Есть обходное решение через прослойку в виде webview, но по опыту могу сказать, что с этим будет много гемора. Мне нужна связка Swift + SwiftUI либо Flutter.
Ещё важно сказать, что lovable все же для быстрого прототипирования, что не совсем мой случай если вернуться к критериям. Да, там есть доступ к кодовой базе, но внутри код довольно посредственный и слабо представляю, как такое можно масштабировать в будущем, не отказываясь от lovable. Тогда возникает вопрос: а зачем изначально использовать данное решение, если от него придётся отказаться? Думаю, эта штука хорошо подходит фаундерам, которые совсем не разбираются в коде и им нужно просто быстро накидать решение, чтобы проверить гипотезу.
Ещё стоит отметить, что под капотом lovable, скорее всего всё те же нейронки и связки, которые описаны в первых 3-х пунктах. Да, со своими скилами и агентами, но построенные на базе вышеупомянутых решений. Исходя из этого возникает вопрос: а зачем нужна прослойка, за которую нужно платить, если можно напрямую использовать решения без прослойки?
Первые 3 решения запомним, к ним ещё вернёмся.
Промежуточный слой для генерации дизайна
– google stitch
– nano banana pro
– midjorney
– uizard
Здесь интересней, первые 2 решения — это продукты гугла и у них есть ряд преимуществ над последними двумя решениями.
Если у вас нет продукта и вы даже не понимаете, как подойти к дизайну, то nano banana pro сможет по референсам сгенерировать визуально более-менее нормальные макеты, чтобы получилось нащупать визуальный язык и понять, какой интерфейс нужен. Причём nano banana pro встроена как отдельная модель в gemini и в google stitch. Разница лишь в том, что google stitch — это figma-подобное решение, которое на выходе генерирует макет, который, кстати, как доп. опцию можно выгрузить в figma.
Процесс генерации картинок интерфейса в gemini отлично подходит, чтобы создать спеки для кодингового агента, который уже в коде создаст интерфейс. Здесь собственно можно сразу вернуться к пунктам 1-3 из раздела генерация интерфейса в коде.
Если вам не нужна спека и уже есть продукт, например бот в tg, то имеет смысл через кодингового агента сгенерировать CJM + экраны и отдать сразу напрямую google stitch для генерации макетов. Потом можно подключить MCP в antigravity и работать через кодингового агента напрямую с макетами.
Большим преимуществом связки является возможность гибридного режима, когда можно и ручками через AI в google stitch поправить дизайн и сразу работать с макетами через кодингового агента, чего не позволяет сделать midjorney и uizard, который нужен вообще для набрасывания мокапов.
продолжение ниже 👇
Часть 2
предыдущая часть 👆
Есть довольно много способов сгенерировать дизайн через AI и чтобы как-то систематизировать знания, перечислю их, а потом расскажу, какой выбрал я.
Важно добавить, что при выборе решения опирался на такие критерии:
– уже есть продукт в виде бота для приложения, хочется сразу заложить хорошую основу
– важно использовать дизайн не только как экраны для вёрстки, но и как CJM для продакта, будущего дизайнера или AI-дизайнера, чтобы проще было ориентироваться в системе и не пришлось по 10 раз разжёвывать, как работает функционал
– поиск сервиса зависит от лучших AI-решений в области дизайна (nano banana pro, например)
– дополнительно нужно учесть соотношение цена/качество
– и поправку на то, что у меня будет нативное IOS-приложение
Теперь если пройтись по инструментам, то решения можно разделить на 2 категории + гибридный вариант: генерация дизайна сразу в коде либо через промежуточный слой в виде figma или figma-подобных сервисов.
Под генерацию в коде подходит
claude code + frontend skill (можно установить через /plugins) + MCP figma
codex + frontend skill
antigravity + frontend skill + MCP для google stitch
lovable
Нужные скиллы можно поискать на skills.sh
В моем случае последнее решение не подходит, потому что нельзя создать нативное IOS-приложение. Есть обходное решение через прослойку в виде webview, но по опыту могу сказать, что с этим будет много гемора. Мне нужна связка Swift + SwiftUI либо Flutter.
Ещё важно сказать, что lovable все же для быстрого прототипирования, что не совсем мой случай если вернуться к критериям. Да, там есть доступ к кодовой базе, но внутри код довольно посредственный и слабо представляю, как такое можно масштабировать в будущем, не отказываясь от lovable. Тогда возникает вопрос: а зачем изначально использовать данное решение, если от него придётся отказаться? Думаю, эта штука хорошо подходит фаундерам, которые совсем не разбираются в коде и им нужно просто быстро накидать решение, чтобы проверить гипотезу.
Ещё стоит отметить, что под капотом lovable, скорее всего всё те же нейронки и связки, которые описаны в первых 3-х пунктах. Да, со своими скилами и агентами, но построенные на базе вышеупомянутых решений. Исходя из этого возникает вопрос: а зачем нужна прослойка, за которую нужно платить, если можно напрямую использовать решения без прослойки?
Первые 3 решения запомним, к ним ещё вернёмся.
Промежуточный слой для генерации дизайна
– google stitch
– nano banana pro
– midjorney
– uizard
Здесь интересней, первые 2 решения — это продукты гугла и у них есть ряд преимуществ над последними двумя решениями.
Если у вас нет продукта и вы даже не понимаете, как подойти к дизайну, то nano banana pro сможет по референсам сгенерировать визуально более-менее нормальные макеты, чтобы получилось нащупать визуальный язык и понять, какой интерфейс нужен. Причём nano banana pro встроена как отдельная модель в gemini и в google stitch. Разница лишь в том, что google stitch — это figma-подобное решение, которое на выходе генерирует макет, который, кстати, как доп. опцию можно выгрузить в figma.
Процесс генерации картинок интерфейса в gemini отлично подходит, чтобы создать спеки для кодингового агента, который уже в коде создаст интерфейс. Здесь собственно можно сразу вернуться к пунктам 1-3 из раздела генерация интерфейса в коде.
Если вам не нужна спека и уже есть продукт, например бот в tg, то имеет смысл через кодингового агента сгенерировать CJM + экраны и отдать сразу напрямую google stitch для генерации макетов. Потом можно подключить MCP в antigravity и работать через кодингового агента напрямую с макетами.
Большим преимуществом связки является возможность гибридного режима, когда можно и ручками через AI в google stitch поправить дизайн и сразу работать с макетами через кодингового агента, чего не позволяет сделать midjorney и uizard, который нужен вообще для набрасывания мокапов.
продолжение ниже 👇