Tracktice Flow
Настройка оборудования подсчёта пассажиропотока — интерфейс калибровки и системных настроек комплекса видеоаналитики.
Обложка кейса — экран калибровки крупно
Коротко
О компании
Tracktice — компания, занимающаяся видеоаналитикой для транспортной инфраструктуры. В компании я также делала корпоративный сайт.
Контекст
Tracktice.Flow считает вошедших и вышедших пассажиров: над каждой дверью транспортного средства стоит камера, ПО отслеживает пересечение виртуальной линии в кадре. Перед вводом машины в эксплуатацию инженер калибрует систему — задаёт положение линии для каждой двери и настраивает параметры устройства.
Заглушка — нужны данные от автора. Одной строкой: чем не устраивал интерфейс, который был до меня — было тяжело читать, параметры лежали вперемешку, устарел визуально?
Задача
Спроектировать интерфейс настройки так, чтобы инженер справлялся с большим объёмом технических параметров и мог проверить результат, не выходя из экрана.
Я была единственным дизайнером и отвечала за оба модуля целиком — от структуры экранов до передачи в разработку и ревью реализации.
Что сделала
- Свела параметры и живой видеопоток на один экран. До этого проверка результата требовала перехода в другое место
- Разложила экран калибровки по шагам инженера: подключиться → разметить линию → проверить. Три постоянно видимые зоны вместо сворачиваемых блоков
- Работала внутри ограничения разработки: способ ввода линии был задан — числовые поля в пикселях. Компенсировала шаговым вводом и близостью кадра
- Заложила логику зависимостей: при синхронизации времени по NTP ручной ввод даты и времени отключается — поле видно, но недоступно
- Собрала UI Kit продукта — до этого модули делались без общей библиотеки, компоненты расходились между экранами
Роль и команда
Продуктовый дизайнер, единственный дизайнер в команде. Команда: продакт-менеджер, стейкхолдер, разработчики.
Результат
Интерфейс внедрён и работает в эксплуатации. На ревью реализации я обнаружила расхождения вёрстки с макетами и передала список правок команде.
Количественных замеров мы не делали — это ограничение кейса, и ниже я пишу, что замеряла бы сейчас.
Как работает подсчёт
Камера смотрит вниз на дверной проём. В кадре проходит виртуальная линия: пересечение в одну сторону — вход, в другую — выход. От того, где стоит линия, зависит, будет счётчик считать верно или начнёт терять и задваивать проходы.
Отсюда главное свойство задачи: правильность настройки видна только на живом кадре. Ни одно число само по себе не говорит инженеру, что линия стоит хорошо.
Второе свойство: настройка выполняется один раз при установке машины. Инженер не возвращается в интерфейс и не вырабатывает привычек — каждый раз он в нём как впервые.
Схема: камера над дверью → линия в кадре → счётчик in/out
Ограничения
Способ ввода линии задавала разработка. Параметры уходят в устройство числами в пикселях, и формат ввода был определён до меня. Перетаскивание линии по кадру в тот момент не обсуждалось как вариант.
Заглушка — нужны данные от автора. Причина, по которой перетаскивание не рассматривалось: не было интерактивного слоя над видеопотоком / задержка видео / не было ресурса на фронте. Если причина не вспоминается — «формат был задан» остаётся честной формулировкой как есть.
Состав параметров задан устройством. Что показывать на экране, определялось прошивкой, а не продуктовым решением.
Заглушка — нужны данные от автора. Другие ограничения проекта — сроки, легаси, ресурс фронтенда — можно добавить сюда одной строкой каждое.
Экран калибровки
Логика раскладки
Три вертикальные зоны, повторяющие порядок действий инженера: подключение и режим работы → разметка линии → проверка на живом кадре.
Зоны сделаны постоянно видимыми, а не сворачиваемыми блоками. Инженер смотрит в третью зону, продолжая править вторую: аккордеон заставлял бы раскрывать блоки заново на каждой итерации.
Что я решала внутри ограничения
Раз способ ввода изменить было нельзя, я работала с тем, что могла контролировать — стоимостью одной итерации.
Кадр вплотную к полям. До этого проверка результата требовала перехода. Сведение на один экран убрало это переключение — единственное изменение, которое реально сокращало цикл правки.
Шаговый ввод стрелками. Подстройка на пиксель — один клик, без выделения и перенабора значения. Для правки «чуть выше» это точнее, чем ввод с клавиатуры.
Переключение дверей в шапке экрана. Все камеры машины настраиваются в одном месте, без возврата в список.
Экран калибровки целиком
Зона линии рядом с кадром
Шаговый ввод
Системные настройки
Параметры устройства — сеть, сервер, время, GPS — разложены на четыре независимых блока по зоне ответственности. Внутри блока порядок полей повторяет порядок, в котором их обычно заполняют.
Одно решение, которое считаю здесь главным: поля «Дата» и «Время» отключаются при выборе NTP. Устройство синхронизирует время само, и ручной ввод в этом режиме ничего не изменит. Отключённое поле честнее скрытого: инженер видит, что параметр существует, и понимает, почему сейчас недоступен. Скрытое поле оставило бы его гадать, куда делась настройка.
Блок «Системное время» с отключёнными полями
Что я вижу в этой работе сейчас
С тех пор прошло время. Я разобрала свои экраны заново — вот что сделала бы иначе и почему.
1. Линия должна задаваться в кадре
Ограничение по формату ввода я приняла как данность и оптимизировала вокруг него: приблизила кадр, добавила шаговый ввод. Сейчас я бы это ограничение сначала оспорила.
Числовой ввод при видимом кадре — это угадывание. Инженер не знает, сколько пикселей ему не хватает; он видит, что линия чуть выше, чем надо. Каждая правка стоит цикла «ввёл — посмотрел — вернулся», и цикл повторяется для каждой двери.
Как сделала бы. Линия рисуется поверх кадра и тянется мышью за концы и за середину. Числовые поля остаются и синхронизированы в обе стороны — потянул линию, обновились числа; ввёл число, сдвинулась линия. Ручной ввод нужен для удалённой поддержки: значение можно продиктовать по телефону.
Что бы это стоило. Интерактивный слой поверх видеопотока — реальная работа для фронта, и разработка могла отказать снова. Но тогда у меня был бы посчитанный аргумент: сколько итераций правки экономит прямая манипуляция на каждой из 2–4 дверей каждой машины. Я его не приносила — просто приняла формат.
Главный вывод для меня: ограничение стоит принимать после того, как понял его цену, а не вместо этого.
До/после — перетаскивание линии мышью
2. Модель линии не совпадает с тем, что видно
«Отступ от левого края», «Отступ от правого края», «Положение по вертикали» — три независимых числа, из которых инженер собирает в голове один отрезок.
Как сделала бы. Линия как единый объект с двумя точками. Это соответствует и тому, что человек видит в кадре, и тому, что он хочет сделать.
3. Двери — табы, а не дропдаун
Я вынесла переключение дверей наверх, но оставила дропдаун. При этом дверей на машине 2–4 — весь набор помещается, и прятать его незачем.
Как сделала бы. Табы с индикатором готовности — настроена, не настроена, в работе. Инженер видит объём работы по машине целиком и не держит в голове, что уже сделал.
Оговорка: решение привязано к автобусу. Для трамвая или сочленённой машины набор может вырасти, и тогда нужен список с прогрессом.
4. Состояния
Оба экрана спроектированы под сценарий, в котором всё работает. Но инженер приходит в интерфейс наладки именно тогда, когда что-то не так.
Что добавила бы:
- Нет потока с камеры — вместо кадра сообщение и следующий шаг: проверить питание, проверить ссылку, повторить подключение
- Неверная RTSP-ссылка — валидация в момент ввода, а не после сохранения
- Настройки применяются — устройство перезагружается, показано, сколько это займёт. Без этого инженер думает, что зависло
- Несохранённые изменения при переключении двери — сейчас правки теряются молча
- Смена сетевых параметров — предупреждение, что устройство станет доступно по новому адресу и текущая сессия прервётся
Почему это важнее визуала. Ошибка калибровки стоит повторного выезда на объект. Интерфейс, который не умеет объяснить, что пошло не так, перекладывает эту стоимость на инженера.
Нет потока с камеры
Неверная RTSP-ссылка
Настройки применяются
Несохранённые изменения
5. Единица работы — машина, а не экран
Первичное действие на экране — «Сохранить настройки». Но задача инженера не в том, чтобы сохранить экран, а в том, чтобы настроить машину и сдать её.
Как сделала бы. Действие ведёт дальше — «Сохранить и перейти к двери 2». Когда настроены все двери — экран завершения: что настроено, что проверить перед сдачей.
Это самое существенное из того, что я упустила. Остальное — про удобство отдельных элементов, а это про то, совпадает ли структура интерфейса с задачей человека.
6. Чего мы не сделали до начала работы
Мы не поговорили ни с одним монтажником и не замерили, сколько занимает настройка машины. Я исходила из своего понимания сценария.
Что бы замеряла сейчас: время калибровки одной двери, число итераций правки линии до сохранения, доля машин, где калибровку переделывали после приёмки. Последняя метрика — самая честная: она показывает, ошибается инженер или нет.
Без этих цифр я не могу сказать, стало ли лучше. Могу сказать только, что было сделано и почему.
Выводы
Ограничение стоит взвесить, прежде чем принять. Формат ввода линии пришёл от разработки, и я оптимизировала вокруг него, не спросив о цене. Это главное, что я вынесла из проекта: «так сказала разработка» — это начало разговора, а не конец.
Структура интерфейса должна совпадать с единицей работы пользователя. Инженер настраивает машину, а не экран. Я спроектировала экраны — и не заметила, что между ними нет истории.
Состояния — не финальная отделка. В инструменте наладки они и есть основной сценарий, и закладывать их надо в начале, а не после того, как готов благополучный случай.
