Дизайн сайта с управлением жестами без Фигмы: как остаться автором, когда руки — ИИ

Я продуктовый дизайнер. Недавно закончил эксперимент, в котором ни разу не открыл Фигму: сайт-портфолио, где вебкамера работает основным вводом. Страница собирает отражение посетителя из частиц, всё управление через жесты. Код писал Claude Code. За мной замысел, дизайн-решения и полевые тесты.

Потрогать: https://dimbo-design.github.io/dimbo_heavy-cv (десктоп, вебкамера)
Код и история решений: https://github.com/dimbo-design/dimbo_heavy-cv

Эта статья про формат работы: что происходит с дизайном, когда исполнитель ИИ, макета нет, а ревьюить код ты не можешь. Формат рабочий. Главный риск в нём не «ИИ нарисует плохо», а незаметно остаться в шаблонных решениях, которые он выдаёт всем подряд. Про это и поговорим.

Техническая статья про грабли отладки жестового управления: https://habr.com/ru/articles/1058358/

Как узнать слоп

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

Отловить такой слоп несложно: достаточно посмотреть два-три проекта, сделанных чисто на генерации, и паттерн начинает читаться. Мои приметы:

• Тайлвинд-сетка и одинаковость блоков. Библиотеки готовых секций поднимают качество, но чем популярнее блок, тем быстрее он примелькается и тем вернее выдаёт генерацию.
• Осторожность. Дизайн на проверенных решениях: главное, чтобы было понятно, куда нажать.
• Шрифты из коробки.
• Фирменные каркасы конкретной модели. У Клода это, например, мелкие надписи-кикеры над заголовками или курсив на одном слове в строгом геометрическом заголовке.
• Маркетинговые и ИИ-шные штампы в текстах.
• Переизбыток системы: всё унифицировано, смелых ходов нет.

Справедливости ради, кикеры есть и в моём проекте. Приёмы не виноваты. Вопрос в том, почему приём используется в проекте, а не в том, попал ли он туда из стандартной обоймы.

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

Метод: эксперимент из дефолта

Теперь — как самому туда не съехать. Сначала общий подход: как я вообще работаю с ИИ, не только в этом проекте. Основа: эксперименты на первых ИИ-генерациях. На старте это похоже на этап работы с контентом: даёшь ИИ собрать безопасный вариант и смотришь, что в нём цепляет как рабочее. Дешёвый способ увидеть, каким проект вообще может быть и что ИИ считает очевидным. Тут же можно поиграть со скиллами-пресетами и библиотеками готовых блоков.

Тяжёлые проекты (этот был таким) начинаются на шаг раньше. Стартовую задумку и технические возможности я собираю в отдельном текстовом чате: обсуждаю с ИИ, формулирую, отмечаю, чем меня не устраивает стандартный результат. Смысл в том, чтобы мощная модель получила весь пул вводных сразу и первая большая итерация поехала в нужном векторе, а не из усреднённых настроек.

Дальше цикл простой. Если в результате видна перспектива (увидеть её это отдельный дизайнерский навык), начинаешь развивать и переделывать. Перерабатывается почти всё, с вниманием к каждой детали. Итерациями идёт отладка проекта, по-дизайнерски это отладка визуала и контента, только вместо проверки кода дизайн-ревью.

Что я вынес: ИИ не угадает то, что у меня в голове, и ждать этого не стоит. В формулировках я оставляю простор, чтобы не сковывать решение, и держу в уме, что упрусь в предел понимания ИИ. Иногда техническая возможность оказывается шире изначальной задумки. А желаемый результат задаю через ключевые моменты, по которым оцениваю «то или не то». Заодно это постоянная проверка задумки на прочность.

ТЗ формируется в процессе

У вайбкодинга есть своя классика: сначала подробная спека, потом код по ней. Для разработки работает — там заранее известно, каким должен быть результат. Дизайну спека не подходит: «правильного» ответа на старте не существует, дизайн ближе к неопределённости, чем разработка. Поэтому чёткого ТЗ у проекта не было, и это осознанная часть метода. Как создание концепции с чистого листа. Требования и ограничения рождались ситуативно: увидел неправильное, сформулировал правило, дальше ИИ держит его как закон. Так появились «UI строго монохромный, цвет только внутри 3D-формы» и «контент не открывается поверх сцены».

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

Два честных следствия. Первое: нужно уметь принимать последствия своих же решений — отменять вчерашнее правило дороже, чем вводить. Второе: формат не подходит, если хочется результата сразу. Итерации стоят времени и лимитов, я на это шёл сознательно.

Пример цены первого следствия, уже после релиза. Правило «на главном экране курсора нет: человек видит своё отражение и сам укажет рукой, куда хочет» я ввёл сам и был в нём уверен. На полевом тестировании, особенно на людях не из ИТ, гипотеза не выжила: пользователи не понимали, где страница считает их руку, и вместо наведения пробовали щипки, захваты, быстрое тыкание пальцем. Точку курсора вернул (ту же, что живёт в главах). Поражение своей гипотезы принял: отменять собственные правила по результатам поля — ровно та часть работы, которую никому не делегируешь.

Что предлагал ИИ и что с этим стало

Дальше конкретные случаи из проекта. История коммитов открыта, и почти все отвергнутые варианты в ней сохранились, так что «до» можно проверить.

Акцентный цвет в интерфейсных надписях. ИИ предложил оживить UI-текст янтарным, тем же цветом, что живёт в 3D-форме. Смотрелось как стандартный ИИ-слоп (колхоз), и причина внятная: у сайта одна выразительная сущность, отражение из частиц. Когда её цвет расползается по подписям, она перестаёт быть главной. Из отказа выросло правило про строгий монохром UI. Было до первого коммита — скрина не осталось.

Модальные окна для глав. Привычный паттерн раскрытия контента, и с ним обычный набор: подложка-оверлей, бордеры, тень. Поверх живой сцены ложится серая плёнка с карточкой, и сцена превращается в фон под окном — сайт перестаёт быть цельным. Решение: контент открывается внутри сцены. Форма отходит в сторону, типографика забирает фокус внимания, ни подложек, ни рамок.

Шрифт. Здесь я поэкспериментировал: описал ИИ характер шрифта, который нужен, и посмотрел, что он подберёт. Подбор дал ерунду. Поставил Fixel Display, который держал в голове, и вопрос закрылся. Случай стандартный, но показательный: описание вкуса словами не заменяет насмотренность.

Шпаргалка по жестам. Изначально хотелось, чтобы посетитель открывал жесты сам, исследованием — на первых реальных тестах это разбилось. Так появилась шпаргалка. Первая версия: технический список, целиком набранный акцентным янтарным. Каждая строка по отдельности читалась, вместе выходил чужеродный блок. Вернул на переделку с одним принципом: у сайта уже есть язык, говори на нём. Во второй версии заголовки групп повторили кикеры глав, а каждая строка собрана так же, как строки метрик на самом сайте: яркая половина про то, что сделать рукой, приглушённая про то, что произойдёт. Единственный янтарь в блоке — метка-переключатель: акцент как метафора прямой связи шпаргалки с 3D-формой.

Выразительность — во взаимодействии

Классическая выразительность через графику здесь сознательно приглушена: UI монохромный и тихий. Выразительность ушла в поведение — в то, как сцена отвечает человеку. И этот слой проектируется так же, как визуальный.

Показательный пример — подсказка для буксующего посетителя. Дефолтное решение: текст или пиктограмма с анимацией. Вместо него сайт проигрывает призрачную руку — запись моего собственного жеста, снятую тем же трекингом, который читает руки посетителей. Подсказка говорит на языке самого ввода: жест объясняется жестом. После первого успеха призрак умирает — научил и ушёл. Решение пришло из геймдева: игры давно умеют учить управлению без слов — призраки в гонках, повторы движений в туториалах файтингов. Это та же насмотренность, что и со шрифтом, только в области решений.

Чьё это, в итоге, решение?

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

Вернее смотреть с другой стороны: ответственность за итог несу я, и в проект не должно пройти ни одного несогласованного со мной решения. По сути это похоже на обычное дизайн-ревью. Типографику контента в главах я не трогал совсем, визуально она ок. А блок подсказок пришлось переиначивать целиком. Можно ли считать результат от ИИ по моим вводным своим решением? Вопрос философский. Ответственность в любом случае не философская.

Кстати, этот текст сделан ровно тем же методом: черновик — ИИ, окончательный текст — мой.

Где я сам съехал в дефолт

Типографика контента из примера выше — ровно такой случай: чистый принятый дефолт. Туда же расстановка элементов по краям экрана; она осталась, но проблему слоёв (контент подъезжал под угловые элементы) я заметил только под конец работы, и её поправили. А стандартную галерею пришлось дорабатывать: изначально согласился на дефолтную, но позже понял, что она не приспособлена к жестам — подкрутил визуальную отдачу под них.

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

Кому подход подойдёт, а кому нет

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

Точно помогут терпение к итерациям и системность собственного видения. Самое сложное во всём формате: не предать свою изначальную задумку.

Про время. Классикой считаю привычный процесс: дизайнер собирает макеты в Фигме и отдаёт их в разработку. За то же время я, наверное, успел бы только в Фигме собрать статичные макеты с текстовым описанием поведения. Здесь же на выходе живой продукт. В новых реалиях ИИ в Фигме умеет оживлять макеты — но сможет ли он из картинки организовать внятную архитектуру проекта, как модель, заточенная под код? Не уверен (надеюсь, у меня на гитхабе не каша).

Если решите попробовать

Инструмент задаёт стиль ровно там, где автор не задал свой.

• Стартовое сообщение с фундаментальными принципами проекта собирайте заранее, в отдельном текстовом чате: мощная модель должна получить весь пул вводных до первой большой итерации.
• Оставляйте простор в формулировках. Жёсткая спецификация сковывает решение; ключевые моменты оценки важнее пикселей. Лучше задавать точечные ограничения: чего не делать.
• Первый результат от ИИ — это черновик. Отвергая, говорите, на что заменить и почему.
• Застряли — обозначьте ИИ проблему, а не решение: он умеет предлагать сам, и это помогает сдвинуться с мёртвой точки.
• Требуйте обоснований в языке вашего продукта и спорьте с ними.
• Новый элемент обязан говорить на языке уже существующих.
• Ответственность за итог на вас: ни одно решение не должно уйти в прод несогласованным.

Что вышло у меня: https://dimbo-design.github.io/dimbo_heavy-cv
История решений: https://github.com/dimbo-design/dimbo_heavy-cv
Кейс на Behance: https://www.behance.net/gallery/252518105/Heavy-CV-with-living-interface
Техническая статья: https://habr.com/ru/articles/1058358/

Читать полностью на источнике