Я продуктовый дизайнер. Недавно закончил эксперимент, в котором ни разу не открыл Фигму: сайт-портфолио, где вебкамера работает основным вводом. Страница собирает отражение посетителя из частиц, всё управление через жесты. Код писал Claude Code. За мной замысел, дизайн-решения и полевые тесты.
Потрогать: https://dimbo-design.github.io/dimbo_heavy-cv (десктоп, вебкамера)
Код и история решений: https://github.com/dimbo-design/dimbo_heavy-cv
Эта статья про формат работы: что происходит с дизайном, когда исполнитель ИИ, макета нет, а ревьюить код ты не можешь. Формат рабочий. Главный риск в нём не «ИИ нарисует плохо», а незаметно остаться в шаблонных решениях, которые он выдаёт всем подряд. Про это и поговорим.
Техническая статья про грабли отладки жестового управления: https://habr.com/ru/articles/1058358/
Как узнать слоп
Главный риск я уже назвал: незаметно съехать в шаблон. Про «дизайн с ИИ» обычно пишут как рекламу — «картинка из текста», «дизайн из промпта», «ретушь за секунду» — разговор про быстрый результат, а не про подход к работе. Итог сформулировали в интернете точнее меня: инструмент стал задавать стиль, а не автор.
Отловить такой слоп несложно: достаточно посмотреть два-три проекта, сделанных чисто на генерации, и паттерн начинает читаться. Мои приметы:
-
Тайлвинд-сетка и одинаковость блоков. Библиотеки готовых секций поднимают качество, но чем популярнее блок, тем быстрее он примелькается и тем вернее выдаёт генерацию.
-
Осторожность. Дизайн на проверенных решениях: главное, чтобы было понятно, куда нажать.
-
Шрифты из коробки.
-
Фирменные каркасы конкретной модели. У Клода это, например, мелкие надписи-кикеры над заголовками или курсив на одном слове в строгом геометрическом заголовке.
-
Маркетинговые и ИИ-шные штампы в текстах.
-
Переизбыток системы: всё унифицировано, смелых ходов нет.
Справедливости ради, кикеры есть и в моём проекте. Приёмы не виноваты. Вопрос в том, почему приём используется в проекте, а не в том, попал ли он туда из стандартной обоймы.
Сильнее всего слоп выдают детали. ИИ из-под капота не умеет нестандартные отступы между схожими элементами. Плох в визуальной подгонке блоков друг к другу. Плохо развивает дизайн-концепцию от блока к блоку: каждый следующий живёт сам по себе, а вариативность элементов растёт по самым предсказуемым траекториям.
Метод: эксперимент из дефолта
Теперь — как самому туда не съехать. Сначала общий подход: как я вообще работаю с ИИ, не только в этом проекте. Основа: эксперименты на первых ИИ-генерациях. На старте это похоже на этап работы с контентом: даёшь ИИ собрать безопасный вариант и смотришь, что в нём цепляет как рабочее. Дешёвый способ увидеть, каким проект вообще может быть и что ИИ считает очевидным. Тут же можно поиграть со скиллами-пресетами и библиотеками готовых блоков.
Тяжёлые проекты (этот был таким) начинаются на шаг раньше. Стартовую задумку и технические возможности я собираю в отдельном текстовом чате: обсуждаю с ИИ, формулирую, отмечаю, чем меня не устраивает стандартный результат. Смысл в том, чтобы мощная модель получила весь пул вводных сразу и первая большая итерация поехала в нужном векторе, а не из усреднённых настроек.
Стартовый промпт для Claude Code / Fable 5 (режим Accept Edits)
язык чата — русский
стартовый промпт сессии — на английском — продолжаем в чате на русском
сразу даю тебе аппрув на все что ты будешь в этой выделенной папке
# Portfolio site with webcam-driven 3D experience
## Project goal
Build a standalone desktop-only portfolio website for Dmitry Togulev, Product Designer. The site uses the webcam as the primary input — the camera feed drives a real-time 3D visual that makes the visitor feel the page is alive and aware of their presence. This is not a gimmick layer on top of a regular portfolio. The camera experience IS the portfolio.
Use the existing portfolio at https://github.com/dimbo-design/Dmitry-Togulev as a content source only (name, role, case studies, bio, contacts). The visual language, structure, layout, and interaction model are entirely your decision — do not replicate the existing site’s aesthetic.
## Core concept: «Living Interface»
The site exists as an abstract system before anyone arrives. When the camera detects a person, the interface reorganises around their presence. The visitor doesn’t trigger the site — the site notices them.
Key feeling to achieve: the visitor should think «this is magic» on first load, and «this person really knows what they’re doing» after 30 seconds. The tone is «serious specialist with taste», not «quirky creative guy».
## Technical approach
The visual is based on depth estimation from the webcam feed — transform the live camera frame into a real-time 3D representation. I’m attaching reference screenshots of a «Depth Anything to 3D» voxel extrusion demo (built with Three.js + Transformers.js + WebGPU) — treat this as a technical proof of concept for the depth pipeline, NOT as a visual reference. The aesthetic, density, geometry, and behaviour of the 3D output should be entirely your own design decision.
Choose the optimal stack for this (depth model, 3D renderer, gesture layer if any) — do not wait for my input on library choices.
## Interaction principles
— The page has no traditional navigation. Content surfaces through presence and motion, not clicks on menus.
— The first meaningful interaction must happen accidentally, not by following an instruction.
— If the visitor moves, the system responds — the response should feel like the site is thinking, not reacting.
— Gesture or body-based navigation is welcome if it serves the experience naturally. Do not force it if it feels contrived.
## Hard constraints — things that must NOT exist
— No onboarding tooltips («raise your hand to navigate», «move closer», etc.)
— No progress bars or loading spinners styled as UI elements — loading must be part of the visual
— No fallback navigation that duplicates content accessible through the camera experience
— No hover states that signal «click here»
— No section headings that label content the way a normal site would («About», «Work», «Contact»)
## Camera access handling
Camera permission is a conscious requirement of this experience — the site should communicate this as an invitation, not a warning. Design a camera permission state that feels like part of the concept, not a browser dialog wrapper.
Two degraded states to handle:
1. Mobile device detected — show a clear, well-designed message that this experience is desktop + webcam only. Not an error page, a considered dead-end.
2. Camera access denied — the site can acknowledge this gracefully but does not need to offer a full non-camera alternative.
## Content requirements
The following must be discoverable through the experience (not necessarily all at once, depth is fine):
— Who Dmitry is and what he does
— Selected case studies / work examples
— A way to get in touch
Language: bilingual Russian / English — choose whichever approach serves the experience better (toggle, auto-detect, parallel, or one primary with the other available).
## Deploy target
GitHub Pages. Single repo, clean structure. Should work without a build step if possible, or with minimal tooling.
## Autonomy
You have full autonomy on all technical and visual decisions. Proceed without asking for confirmation on stack, structure, or aesthetic choices. Build the complete working project. If you hit a genuine blocker that requires my input, flag it — otherwise ship.
—
Attached: 2 reference screenshots showing the depth-to-voxel pipeline concept (for technical reference only, not visual direction).
Дальше цикл простой. Если в результате видна перспектива (увидеть её это отдельный дизайнерский навык), начинаешь развивать и переделывать. Перерабатывается почти всё, с вниманием к каждой детали. Итерациями идёт отладка проекта, по-дизайнерски это отладка визуала и контента, только вместо проверки кода дизайн-ревью.
Что я вынес: ИИ не угадает то, что у меня в голове, и ждать этого не стоит. В формулировках я оставляю простор, чтобы не сковывать решение, и держу в уме, что упрусь в предел понимания ИИ. Иногда техническая возможность оказывается шире изначальной задумки. А желаемый результат задаю через ключевые моменты, по которым оцениваю «то или не то». Заодно это постоянная проверка задумки на прочность.
ТЗ формируется в процессе
У вайбкодинга есть своя классика: сначала подробная спека, потом код по ней. Для разработки работает — там заранее известно, каким должен быть результат. Дизайну спека не подходит: «правильного» ответа на старте не существует, дизайн ближе к неопределённости, чем разработка. Поэтому чёткого ТЗ у проекта не было, и это осознанная часть метода. Как создание концепции с чистого листа. Требования и ограничения рождались ситуативно: увидел неправильное, сформулировал правило, дальше ИИ держит его как закон. Так появились «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/
Дмитрий Тогулев — Senior Product Designer, ex-KazanExpress, ex-Uzum
ссылка на оригинал статьи https://habr.com/ru/articles/1060364/