Термином Zero UI обозначают интерфейсы, где привычного экрана с кнопками либо нет вовсе, либо он перестаёт быть основным способом взаимодействия. Голосовые команды, жесты, датчики, автоматические сценарии, срабатывающие по событию, — всё это уже применяется в банковских сервисах, рознице, автомобилях и на производстве. Разберём, что за этим стоит с точки зрения проектирования, где безэкранный сценарий действительно уместен, какие сложности он приносит и как компании подступиться к теме, не переписывая свои сервисы целиком.
Что считать безэкранным интерфейсом
Определение шире, чем голосовой ассистент. К этой же категории относят любые способы взаимодействия, где человек не разбирает меню на экране:
- Голос. Команда, вопрос, диктовка вместо ввода с клавиатуры.
- Жесты и движение. Управление без касания там, где руки заняты или грязные.
- Датчики и метки. Считывание кода, метки на пропуске, определение положения — действие происходит по факту события.
- Автоматические сценарии. Система сама выполняет шаг, о котором раньше просили человека: продлевает подписку, формирует документ, отправляет уведомление.
- Разговорные интерфейсы в переписке. Формально экран есть, но привычной навигации нет — есть диалог.
Ключевая мысль здесь такая: безэкранность — не отсутствие интерфейса, а перенос его в другую форму. Проектировать всё равно приходится, просто вместо расположения блоков проектируют формулировки, сценарии, реакции на ошибки и способы подтверждения.
Где это оправдано
| Ситуация | Почему экран мешает | Подходящий формат | На что обратить внимание |
|---|---|---|---|
| Руки заняты: склад, цех, кухня, ремонт | Нельзя взять телефон, экран пачкается | Голосовой ввод, сканирование меток | Шум, точность распознавания терминов |
| За рулём | Взгляд на экран опасен | Голос, крупные жесты | Короткие подтверждения без чтения |
| Повторяющийся типовой запрос | Навигация занимает больше времени, чем сам вопрос | Диалог или голосовая команда | Быстрый переход к оператору |
| Ввод длинного текста | Печатать с телефона долго | Диктовка с последующей правкой | Возможность отредактировать результат |
| Действие, которое можно не делать вручную | Пользователь не должен помнить о рутине | Автоматический сценарий | Понятное уведомление и возможность отменить |
| Проходная, точка выдачи, оплата | Очередь и ограниченное время | Метка, код, датчик | Запасной путь при сбое оборудования |
Что меняется в проектировании
При безэкранном взаимодействии исчезают вещи, на которые обычно опирается интерфейс: видимый перечень доступных действий, состояние системы, возможность вернуться назад. Их приходится восстанавливать другими средствами.
- Обнаруживаемость. Человек не видит списка команд и не знает, что можно попросить. Значит, система должна подсказывать сама: коротким приветствием, примером, ответом на непонятый запрос.
- Обратная связь. После команды должно быть подтверждение, что она принята и понята именно так. Молчание воспринимается как сбой.
- Отмена. Ошибочно распознанная команда должна отменяться одним действием, иначе доверия не будет.
- Подтверждение важных операций. Всё, что связано с деньгами, доступами и необратимыми изменениями, подтверждается отдельно.
- Запасной путь. Не распозналось трижды — переводим на человека или на обычный экран. Зацикливание раздражает сильнее, чем отсутствие функции.
- Терминология. Люди формулируют по-разному, и сценарий должен понимать варианты, а не единственную «правильную» фразу.
Сложности, которые придётся решать
- Точность распознавания. Шум на производстве, акценты, отраслевые термины и артикулы — всё это снижает качество. Обычно требуется собственный словарь и обучение на реальных записях.
- Персональные данные. Голос и изображение человека — чувствительные данные. Нужно понимать, где они обрабатываются, сколько хранятся, кто имеет к ним доступ и на каком основании.
- Согласия и уведомления. Запись разговора и обработка биометрии требуют отдельного основания, и это организационная работа, а не технический флажок.
- Доступность. Голосовое управление удобно не всем: людям с нарушениями речи и слуха нужен альтернативный путь. Безэкранный интерфейс не должен быть единственным.
- Приватность в общем помещении. Произносить вслух номер договора в открытом офисе никто не станет.
- Стоимость поддержки. Сценарии нужно дорабатывать по итогам реальных диалогов, иначе система быстро устаревает.
Как подступиться, не переделывая всё
Полноценный переход на безэкранное взаимодействие большинству компаний не нужен. Разумнее выбрать один сценарий, где выигрыш очевиден, и довести его до рабочего состояния.
- Найдите операцию, которая повторяется много раз в день и сейчас требует ручного ввода.
- Опишите её как диалог: что говорит человек, что отвечает система, что происходит при непонимании.
- Проверьте сценарий вручную, без разработки: один сотрудник играет роль системы, второй — пользователя.
- Соберите минимальную версию и запустите на ограниченной группе, сохраняя записи диалогов.
- Разберите неудачные обращения и дополните сценарий: как правило, десяток формулировок закрывает большинство случаев.
- Только после этого расширяйте охват и добавляйте новые операции.
Что это даёт бизнесу
Выигрыш обычно в трёх вещах: время выполнения операции сокращается, снижается число ошибок ручного ввода, а часть обращений закрывается без участия сотрудника. Отдельный эффект — данные: любая безэкранная система оставляет записи о том, что и как часто у неё спрашивают. Этот материал полезен не только для доработки сценария, но и для понимания, чего людям не хватает в обычном интерфейсе.
Важно не переоценивать эффект. Безэкранный сценарий не заменяет сайт и личный кабинет: он снимает часть рутины, а сложные операции по-прежнему удобнее выполнять глазами и руками. Поэтому проектировать имеет смысл связку, а не замену.
Нужна помощь
Мы начинаем с задач пользователя, а не с макета: разбираем сценарии, проверяем их на людях и только потом переходим к разработке. Так интерфейс не приходится переделывать после запуска — спроектируем интерфейс и сценарии взаимодействия для вашего сервиса.
Мы начинаем с задач пользователя, а не с макета: UX/UI-проектирование помогает не переделывать интерфейс после запуска.
