Комментарии 5
Мне кажется эти подходы не жизнеспособны, потому что из того что я увидел ИИ научился дизайну 2015 года +-, сейчас подходы, эстетика и в целом паттерны меняются. Хороший дизайнер рисует, пробует, экспериментирует, проводит доп исследования если необходимо, это процесс который ИИ не сможет сделать кроме как копировать плохие решения. Ярки тому пример базовый даже сценарий входа по телефону, который отвратительно сделан у 90% продуктов, а ии просто его копирует и плодит еще больше плохое, потому что какому то васи захотелось собрать MVP на коленке с курсором
С тезисом частично согласен: “по умолчанию” генератор будет копировать массовые решения, и массовые решения часто посредственные. Но отсюда не следует, что подход нежизнеспособен. Это означает, что ИИ нельзя использовать как “автодизайнер”, а нужно использовать как ускоритель итераций под контролем критериев.
Я разделяю два слоя. Первый слой: структура флоу, ветки, статусы, тексты, ошибки, логика ролей, что будет дальше. Это можно быстро накидать через ИИ и получить несколько вариантов, как будто ты сделал быстрый desk research по десятку продуктов. Второй слой: качество решения, свежесть паттернов, эстетика, доказательная часть, проверка гипотез. Это остается на дизайнере и продукте.
В статье я не утверждаю, что “ИИ сделает хорошо сам”. Я показываю, что можно за короткое время получить черновик, который затем доводится: консистентность, микро-копи, корректные статусы, устранение “среднего интернета”. Ровно потому, что 90% примеров плохие, нужна фильтрация и редактирование. ИИ дает заготовку, а не финальный дизайн.
Я правильно понимаю что при должном подходе к промптингу, можно даже создать отдельные страницы с компонентами, стейтами, зафиксировать параметры в json, чтобы токены сформировать. То есть фактически оставить себе роль валидации дизайн системы, чтобы уже с этими параметрами можно было вайб кодить продукт, и уже в живую смотреть насколько паттерн адекватный.
Я тоже эту историю изучаю сейчас, и мне пока показалось что вот даже если можно накидать такие концерты, то остаётся дизайнер как бутылочное горлышко который должен будет это все вручную причесать и сформировать токены.
А глядя на это кажется и вот это можно оптимизировать... дело только в детальных промптах.
Вы очень точно сформулировали: “роль валидации” и “живьём проверять паттерн” это и есть рабочая модель. И да, узкое место действительно похоже на дизайнера, потому что кто-то должен принять финальные решения и зафиксировать их в системе.
Но я бы добавил нюанс. Это узкое место можно уменьшить не только “детальными промптами”, а дисциплиной. Один раз фиксируете конституцию: список компонентов, матрицу состояний, набор токенов, правила нейминга, и затем в каждом промпте это повторяется как контракт. Тогда причесывание превращается из бесконечного ручного труда в короткую проверку по списку: где нарушен контракт, где не совпали значения, где текст выбился из тона. То есть дизайнер остаётся, но не как бутылочное горлышко, а как человек, который держит систему в границах.
Сам же написал "ты крутой дизайнер", вот гемени и стал выделываться, все просто.

Тестирую Nano Banana на реальной UX-задаче → создать workspace и пригласить коллегу (B2B SaaS)