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