Сценарий использования интерфейса

Когда говорят про сценарий использования интерфейса, многие сразу представляют себе красивую схему в Figma или Miro: пользователь нажимает сюда, попадает туда. Но на практике, особенно в B2B-секторе с его сложным оборудованием, всё упирается в то, как этот сценарий работает в реальной, иногда грязной и срочной, рабочей обстановке. Я много раз видел, как отличный на бумаге flow ломался, потому что проектировщик не учел, что у оператора на складе в мороз могут быть толстые перчатки, или что номер партии на устройстве читается только при определенном освещении. Вот об этих нюансах, которые и составляют суть рабочего сценария, и хочется порассуждать.

От спецификации к реальному действию: где теряется смысл

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

Инженер ищет не просто ?выключатель?, а устройство с конкретными параметрами по току отключения при -40°C для уже существующей ячейки КРУ. В идеальном сценарии фильтры на сайте должны это учесть. Но на деле часто выходит, что параметрический поиск работает только по основным характеристикам из маркетингового листа, а не по тем, что указаны мелким шрифтом на чертеже в приложении к ГОСТ. Пользователь тогда уходит в ?Контакты? и пишет письмо. Это провал интерфейса? С одной стороны, да. С другой — для сложного оборудования такой гибридный сценарий (часть — через интерфейс, часть — через прямое общение) часто неизбежен и даже предпочтителен. Задача — сделать так, чтобы переход был seamless, а не вынужденным.

Мы однажды пытались сделать ?умный? конфигуратор для сборных низковольтных щитов. Красивая 3D-модель, drag-and-drop компонентов. Потратили кучу времени. А ключевые клиенты — монтажные организации — просто слали нам фотографии нарисованной от руки схемы в WhatsApp. Их сценарий использования был не в красивом подборе, а в быстрой оценке ?соберем/не соберем? по эскизу и оперативном расчете. Интерфейс конфигуратора оказался красивой, но бесполезной игрушкой. Пришлось переделывать, сделав упор на быструю загрузку эскиза и чат для уточнений прямо в личном кабинете.

Контекст — король. Особенно на производстве

Вот что часто упускают из виду: интерфейс для выбора электротехнического компонента используется не в вакууме. Человек сидит в проектной организации, у него горят сроки, на втором мониторе — AutoCAD, а в голове — смета. Он не будет с упоением изучать все карточки товаров. Его сценарий — ?найти аналог или замену для указанного в проекте устройства, проверить совместимость по габаритам и присоединительным размерам, и выгрузить спецификацию?. Поэтому ключевое для нас стало не количество кликов, а наличие на карточке товара сразу, сверху, самых критичных данных: габаритный чертеж в PDF, аналоги по ГОСТ или IEC, и кнопка ?Добавить в спецификацию? с выгрузкой в Excel. Всё остальное — вторично.

Была ошибка: мы вынесли чертежи в отдельную вкладку ?Документация?. Коэффициент конверсии в запрос с таких карточек был низким. Проанализировали тепловые карты — до вкладки просто не доходили. Перенесли миниатюру основного чертежа прямо под фото оборудования — количество запросов выросло. Это мелочь, но она решает. Сценарий использования диктуется не здравым смыслом, а рабочим контекстом, который нужно выявлять, иногда методом проб и ошибок.

Еще пример из сервисной части. Послепродажная поддержка. Клиенту нужно найти руководство по эксплуатации на конкретную партию оборудования. На сайте есть поиск по модели. Но у нас оборудование часто дорабатывается под проект, и к базовой модели идут десятки модификаций. Искать по артикулу из паспорта — идеально. Но если паспорт утерян? Мы добавили сценарий поиска по серийному номеру, который выбит на корпусе. Казалось, всё просто. Однако выяснилось, что серийный номер на некоторых силовых трансформаторах находится на боковой стенке, и чтобы его сфотографировать, нужно отключить и отсоединить аппарат. Нереально. Пришлось параллельно вводить сценарий идентификации по визуальным признакам (форма, расположение шин, цвет) через галерею типовых исполнений. Это нестандартный, затратный по разработке путь, но без него интерфейс был бы беспомощен в критичной ситуации.

Провалы как источник правды

Самые ценные инсайты о реальных сценариях приходят не из аналитики Google Analytics, а из провалов. У нас был период, когда мы решили, что все запросы должны идти через форму с обязательными полями: проект, бюджет, сроки. Логично же? Это же помогает менеджерам. На деле количество обращений упало в разы. Позвонили нескольким постоянным клиентам. Ответ был прост: ?Когда у меня срочная поломка и нужно узнать, есть ли в наличии конкретный разъединитель, мне некогда заполнять форму. Мне нужен телефон?. Мы вернули крупный номер телефона в шапку сайта и добавили кнопку ?Срочный запрос по наличию? с предзаполненной темой письма. Трафик в отдел продаж восстановился.

Это показало, что мы спроектировали сценарий под себя (сбор структурированных данных), а не под пользователя, у которого может быть десяток разных ситуаций: от срочной закупки до долгосрочного тендерного планирования. Для каждого — свой оптимальный путь. Теперь у нас на сайте несколько точек входа для связи, каждая для своего сценария использования: форма для коммерческого предложения, чат для оперативных вопросов, телефон для ЧП, email для технических консультаций. И это работает.

Еще один провал связан с терминологией. Мы, как производитель, используем четкие, стандартизированные названия изделий. Но монтажники и закупщики на местах часто используют местный сленг или устаревшие названия из советских каталогов. Человек ищет ?ящик с рубильником?, а у нас в каталоге — ?Низковольтный комплектное устройство управления с ручным приводом?. Поиск ничего не находил. Пришлось серьезно поработать над синонимами и тегами, добавив в поисковую базу просторечные и устаревшие названия. Это невидимая, но vital часть интерфейса.

Интерфейс как продолжение логики оборудования

Работая с OOO Шэньхэн Энергетическое Оборудование, я пришел к мысли, что для промышленного сайта интерфейс должен, в каком-то смысле, отражать логику самого оборудования. Оно надежное, прямое, функциональное. Никаких излишеств. Так и интерфейс: информация должна быть структурирована как технический паспорт — иерархично, с четкими разделами, без воды.

Мы перестали гнаться за модными мега-меню и анимациями. Вместо этого сделали упор на скорость загрузки чертежей (тяжелые PDF оптимизировали, сделали предпросмотр), на корректное отображение на планшетах, которые используют инженеры на объектах, и на оффлайн-доступность ключевых документов. Сценарий ведь часто разворачивается в цеху или на стройплощадке, где с интернетом плохо. Возможность скачать весь пакет документов одной кнопкой — это часть хорошего UX для нашей отрасли.

И последнее. Самый важный сценарий использования интерфейса, который мы долго не замечали, — это сценарий ?вернуться?. Клиент получил оборудование, смонтировал, работает. Через 5 лет ему нужны запасные части. Вернется ли он на сайт? Если да, то как он найдет деталь для устаревшей модели? Мы создали раздел ?Поддержка устаревшего оборудования? с архивом документации и возможностью запроса на изготовление ЗИП. Это не приносит много трафика, но это критично для репутации. Интерфейс в B2B — это на десятилетия, а не на один клик. И сценарии должны это учитывать, закладывая пути не только для первой продажи, но и для всего жизненного цикла изделия. Вот о чем, по-моему, и стоит думать, когда проектируешь взаимодействие для сложного, ?тяжелого? продукта.