Согласен, и это как раз хорошо показывает границу между сильной картинкой и сильной системой. Если AI получает точные ограничения, паттерны, компонентную логику и требования к состояниям, результат обычно резко улучшается. А при слишком общей постановке задачи он действительно чаще выдаёт эффектную форму без дисциплины, особенно на hover, active, disabled и других местах, где уже нужна не картинка, а поведение. Собственно, в этом и был мой тезис: ценность не в том, что AI сам по себе хорошо проектирует интерфейс, а в том, что он может быстро принести сильную визуальную гипотезу. Дальше уже всё решают ограничения, проверка и нормализация.
Да, однако, с Pinterest соглашусь только частично. Как библиотека сильных решений он действительно очень полезен. Проблема в другом: Pinterest даёт доступ к уже найденным формам, а генерация позволяет идти в режим активного перебора и смотреть, какие сочетания материала, света, формы и глубины вообще возможны в заданном направлении.
То есть для меня вопрос не в том, где взять красивые картинки. Их действительно уже очень много. Вопрос в том, как сместить поиск из режима выбора в режим управляемого нишевого визуального исследования.
Спасибо, хороший вопрос. Я бы развёл эти вещи по уровню обязательности и по тому, кто и что гарантирует на выходе.
Библиотека компонентов для меня это витрина и удобный способ переиспользовать готовые куски UI. Там может быть Storybook, может быть просто папка с React-компонентами и парой примеров. Её ценность в скорости сборки и в том, что люди видят, что уже есть.
Дизайн-система начинается там, где появляется контракт. Компоненты становятся вторичными по отношению к правилам: токены, состояния, сетка, типографика, принципы. И главное, появляется механизм контроля качества: что считается валидным использованием, кто принимает изменения, как ведётся версионирование, как вы ловите рассинхрон между макетом и кодом. Если витрина есть, а контракта и процесса нет, это библиотека.
Про набор CSS-классов для кнопок на старте я полностью согласен. Более того, я обычно считаю это разумным минимумом: пара базовых токенов + 2–3 компонента, которые встречаются везде (кнопка, инпут, бейдж, возможно модалка). Tailwind как раз подталкивает к этому естественно: в какой-то момент понимаешь, что проще вынести повторяющийся набор утилит в компонент или хотя бы в аккуратный набор классов.
Про степень свободы. Я стараюсь держать её в рамках, чтобы не плодить визуальный шум, но не превращать работу в бюрократию.
☛ Жёстко фиксирую: типографику (2–3 размера, веса), базовые отступы (шаг), радиусы (1–2 значения), нейтральную палитру и семантические цвета для статусов, состояния интерактива (hover, active, disabled, focus). Это та часть, где хаос быстро становится дорогим.
☛ Оставляю свободу: компоновку экранов, структуру блоков, оформление отдельных фич, специфические паттерны под сценарий. На ранней стадии продукт ещё ищет форму, и слишком ранняя унификация тут реально мешает.
Если упростить до одного критерия: пока вы чаще меняете смысл и структуру экранов, чем шлифуете консистентность, вам нужна библиотека и маленький слой токенов. Дизайн-система начинается в тот момент, когда изменения становятся не поиском, а тиражированием и сопровождением.
Тут кажется, вы спорите с тезисом, которого в статье нет. Я не говорю “дизайн система не нужна” и не предлагаю работать “макетами сомнительного качества”.
Я показываю, что AI может ускорить старт: быстро собрать флоу и дать материал для анализа. Дальше начинается взрослая часть, которую вы перечислили: компоненты, токены, состояния, контракты, и это как раз зона ответственности дизайнера.
Если человек не умеет в систему, он и без нейронки сделает мусор. А если умеет, нейронка становится инструментом, который экономит время на первых итерациях, а не заменяет профессионализм.
Спасибо! Я сознательно не писал конкретный детальный промпт. Если сразу задать чеклист полей, ошибок и статусов, получится тест моего умения формулировать, а не тест модели. Поэтому я держал вход максимально общим: попросил модель описать, как бы она задизайнила этот first-time flow, и затем попросил на основе своего же ответа сгенерировать промпты для Nano Banana.
Важно было увидеть, какие элементы она добавит сама, как расставит акценты и где провалится по edge cases. Перед генерацией я почти ничего не допридумывал, только вычищал мелкие артефакты и приводил текст к одному языку.
Вы очень точно сформулировали: “роль валидации” и “живьём проверять паттерн” это и есть рабочая модель. И да, узкое место действительно похоже на дизайнера, потому что кто-то должен принять финальные решения и зафиксировать их в системе.
Но я бы добавил нюанс. Это узкое место можно уменьшить не только “детальными промптами”, а дисциплиной. Один раз фиксируете конституцию: список компонентов, матрицу состояний, набор токенов, правила нейминга, и затем в каждом промпте это повторяется как контракт. Тогда причесывание превращается из бесконечного ручного труда в короткую проверку по списку: где нарушен контракт, где не совпали значения, где текст выбился из тона. То есть дизайнер остаётся, но не как бутылочное горлышко, а как человек, который держит систему в границах.
С тезисом частично согласен: “по умолчанию” генератор будет копировать массовые решения, и массовые решения часто посредственные. Но отсюда не следует, что подход нежизнеспособен. Это означает, что ИИ нельзя использовать как “автодизайнер”, а нужно использовать как ускоритель итераций под контролем критериев.
Я разделяю два слоя. Первый слой: структура флоу, ветки, статусы, тексты, ошибки, логика ролей, что будет дальше. Это можно быстро накидать через ИИ и получить несколько вариантов, как будто ты сделал быстрый desk research по десятку продуктов. Второй слой: качество решения, свежесть паттернов, эстетика, доказательная часть, проверка гипотез. Это остается на дизайнере и продукте.
В статье я не утверждаю, что “ИИ сделает хорошо сам”. Я показываю, что можно за короткое время получить черновик, который затем доводится: консистентность, микро-копи, корректные статусы, устранение “среднего интернета”. Ровно потому, что 90% примеров плохие, нужна фильтрация и редактирование. ИИ дает заготовку, а не финальный дизайн.
Иногда мне кажется, что Хабр это то место, где если в разделе "интерфейсы" ждут посты не про юзабилити, а про то как некоторые провода втыкаются в определенные разъемы...
Согласен, и это как раз хорошо показывает границу между сильной картинкой и сильной системой. Если AI получает точные ограничения, паттерны, компонентную логику и требования к состояниям, результат обычно резко улучшается. А при слишком общей постановке задачи он действительно чаще выдаёт эффектную форму без дисциплины, особенно на hover, active, disabled и других местах, где уже нужна не картинка, а поведение. Собственно, в этом и был мой тезис: ценность не в том, что AI сам по себе хорошо проектирует интерфейс, а в том, что он может быстро принести сильную визуальную гипотезу. Дальше уже всё решают ограничения, проверка и нормализация.
Статья написана самостоятельно и дополнена ... множеством em-dash'ей, чтобы максимально стало похоже на сгенерированную
Да, однако, с Pinterest соглашусь только частично. Как библиотека сильных решений он действительно очень полезен. Проблема в другом: Pinterest даёт доступ к уже найденным формам, а генерация позволяет идти в режим активного перебора и смотреть, какие сочетания материала, света, формы и глубины вообще возможны в заданном направлении.
То есть для меня вопрос не в том, где взять красивые картинки. Их действительно уже очень много. Вопрос в том, как сместить поиск из режима выбора в режим управляемого нишевого визуального исследования.
Спасибо, хороший вопрос. Я бы развёл эти вещи по уровню обязательности и по тому, кто и что гарантирует на выходе.
Библиотека компонентов для меня это витрина и удобный способ переиспользовать готовые куски UI. Там может быть Storybook, может быть просто папка с React-компонентами и парой примеров. Её ценность в скорости сборки и в том, что люди видят, что уже есть.
Дизайн-система начинается там, где появляется контракт. Компоненты становятся вторичными по отношению к правилам: токены, состояния, сетка, типографика, принципы. И главное, появляется механизм контроля качества: что считается валидным использованием, кто принимает изменения, как ведётся версионирование, как вы ловите рассинхрон между макетом и кодом. Если витрина есть, а контракта и процесса нет, это библиотека.
Про набор CSS-классов для кнопок на старте я полностью согласен. Более того, я обычно считаю это разумным минимумом: пара базовых токенов + 2–3 компонента, которые встречаются везде (кнопка, инпут, бейдж, возможно модалка). Tailwind как раз подталкивает к этому естественно: в какой-то момент понимаешь, что проще вынести повторяющийся набор утилит в компонент или хотя бы в аккуратный набор классов.
Про степень свободы. Я стараюсь держать её в рамках, чтобы не плодить визуальный шум, но не превращать работу в бюрократию.
☛ Жёстко фиксирую: типографику (2–3 размера, веса), базовые отступы (шаг), радиусы (1–2 значения), нейтральную палитру и семантические цвета для статусов, состояния интерактива (hover, active, disabled, focus). Это та часть, где хаос быстро становится дорогим.
☛ Оставляю свободу: компоновку экранов, структуру блоков, оформление отдельных фич, специфические паттерны под сценарий. На ранней стадии продукт ещё ищет форму, и слишком ранняя унификация тут реально мешает.
Если упростить до одного критерия: пока вы чаще меняете смысл и структуру экранов, чем шлифуете консистентность, вам нужна библиотека и маленький слой токенов. Дизайн-система начинается в тот момент, когда изменения становятся не поиском, а тиражированием и сопровождением.
и это если китайские учёные опять не начнут "бесследно исчезать" один за другим
любой ценой поддерживать планку потреблятства, даже когда народ затягивает пояса
Тут кажется, вы спорите с тезисом, которого в статье нет. Я не говорю “дизайн система не нужна” и не предлагаю работать “макетами сомнительного качества”.
Я показываю, что AI может ускорить старт: быстро собрать флоу и дать материал для анализа. Дальше начинается взрослая часть, которую вы перечислили: компоненты, токены, состояния, контракты, и это как раз зона ответственности дизайнера.
Если человек не умеет в систему, он и без нейронки сделает мусор. А если умеет, нейронка становится инструментом, который экономит время на первых итерациях, а не заменяет профессионализм.
Спасибо! Я сознательно не писал конкретный детальный промпт. Если сразу задать чеклист полей, ошибок и статусов, получится тест моего умения формулировать, а не тест модели. Поэтому я держал вход максимально общим: попросил модель описать, как бы она задизайнила этот first-time flow, и затем попросил на основе своего же ответа сгенерировать промпты для Nano Banana.
Важно было увидеть, какие элементы она добавит сама, как расставит акценты и где провалится по edge cases. Перед генерацией я почти ничего не допридумывал, только вычищал мелкие артефакты и приводил текст к одному языку.
Вы очень точно сформулировали: “роль валидации” и “живьём проверять паттерн” это и есть рабочая модель. И да, узкое место действительно похоже на дизайнера, потому что кто-то должен принять финальные решения и зафиксировать их в системе.
Но я бы добавил нюанс. Это узкое место можно уменьшить не только “детальными промптами”, а дисциплиной. Один раз фиксируете конституцию: список компонентов, матрицу состояний, набор токенов, правила нейминга, и затем в каждом промпте это повторяется как контракт. Тогда причесывание превращается из бесконечного ручного труда в короткую проверку по списку: где нарушен контракт, где не совпали значения, где текст выбился из тона. То есть дизайнер остаётся, но не как бутылочное горлышко, а как человек, который держит систему в границах.
С тезисом частично согласен: “по умолчанию” генератор будет копировать массовые решения, и массовые решения часто посредственные. Но отсюда не следует, что подход нежизнеспособен. Это означает, что ИИ нельзя использовать как “автодизайнер”, а нужно использовать как ускоритель итераций под контролем критериев.
Я разделяю два слоя. Первый слой: структура флоу, ветки, статусы, тексты, ошибки, логика ролей, что будет дальше. Это можно быстро накидать через ИИ и получить несколько вариантов, как будто ты сделал быстрый desk research по десятку продуктов. Второй слой: качество решения, свежесть паттернов, эстетика, доказательная часть, проверка гипотез. Это остается на дизайнере и продукте.
В статье я не утверждаю, что “ИИ сделает хорошо сам”. Я показываю, что можно за короткое время получить черновик, который затем доводится: консистентность, микро-копи, корректные статусы, устранение “среднего интернета”. Ровно потому, что 90% примеров плохие, нужна фильтрация и редактирование. ИИ дает заготовку, а не финальный дизайн.
Спасибо!
Иногда мне кажется, что Хабр это то место, где если в разделе "интерфейсы" ждут посты не про юзабилити, а про то как некоторые провода втыкаются в определенные разъемы...
Именно. Ключевое слово тут "поддерживать".
По себе знаю этот вызов, когда дизайнер ставит перед собой задачу по созданию портфолио с нуля и сначала долго не может начать.
Потом долго не может закончить, а в итоге и вовсе забрасывает.
Ежели еще чего интересного найдёте — непременно пишите!
Но искать придётся самостоятельно.
А если еще и многократно, пока тестируешь…
Причем тут вообще «4», непонятно…