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

Опыт продуктового дизайнера Дмитрия Тогулева показывает важную вещь: живой интерфейс собирается из связанных решений и полевых проверок. Код для эксперимента создавал Claude Code, однако направление, ограничения и отбор вариантов остались задачей автора. Этот подход полезен командам, которые добавляют в сайт камеру, жесты, 3D или генеративные инструменты и хотят сохранить понятный пользовательский опыт.

Камера меняет сценарий первого контакта

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

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

Правила интерфейса держат концепцию

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

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

Подобные правила полезно фиксировать короткими формулировками и проверять при каждом изменении. Они могут касаться не только графики: скорости реакции, поведения ошибки, слов в подсказках, состояния загрузки. Чем необычнее способ ввода, тем важнее согласованность реакции системы. Пользователь запоминает не только отдельные экраны, но и логику переходов между ними.

Первую версию стоит считать материалом для ревью

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

Затем работа шла итерациями. ИИ предлагал вариант, дизайнер смотрел на него в контексте всей сцены, принимал или менял правило. Так были отброшены янтарные интерфейсные надписи: цвет работал в 3D-форме, но расползался по UI и ослаблял единственный визуальный акцент. Подбор шрифта по словесному описанию тоже дал слабый результат; для проекта выбрали Fixel Display, который соответствовал исходному замыслу.

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

Полевой тест отменяет даже любимое правило

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

Этот эпизод хорошо описывает границу между концепцией и продуктом. Замысел может быть сильным, а наблюдаемое поведение пользователя — противоположным ожиданию. Убрать красивое правило после теста бывает сложнее, чем ввести его с нуля, поскольку за ним уже выстроены другие детали. Однако интерфейс существует для человека, который впервые его видит, а не для защиты первоначального решения команды.

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

Подсказка может говорить жестом

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

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

Что проверить перед запуском необычного интерфейса

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

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