Испытательное задание в#nbsp;Яндекс: проектирование аналитического дашборда для роботов-доставщиков
В конце 2025 года я откликнулся на вакансию продуктового дизайнера в Яндекс. После первого этапа меня пригласили дальше и предложили выполнить тестовое задание.
Задача показалась интересной: нужно было спроектировать аналитический дашборд для отслеживания эффективности роботов-доставщиков. Ниже — разбор того, как я подошёл к этой работе и какие решения принял.
Цель — создать дашборд для анализа эффективности роботов компании. Интерфейс должен помогать аналитикам:
анализировать статистику поломок,
оценивать загрузку роботов,
понимать эффективность работы отделов.
Работу требовалось выполнить в дизайн-системе Яндекса — Gravity UI, а результат предоставить в виде макета в Figma.
Ниже на изображении само задание:
Ux и прототипирование
Начал с логики интерфейса. Основная идея — лёгкий и понятный дашборд, в котором можно гибко настраивать отображение статистики и быстро работать с большими массивами данных.
Верхняя панель
В верхней части интерфейса расположены системные элементы, с которыми пользователь взаимодействует редко: название сервиса, профиль пользователя, настройки и справка. Они не отвлекают от основной работы, но всегда остаются под рукой.
Левая панель — работа с роботами
Левую часть интерфейса я выделил под взаимодействие с роботами. Здесь аналитик может:
искать роботов,
фильтровать их по модели, поколению или району,
сортировать по ключевым параметрам.
Это позволяет быстро сфокусироваться либо на определённой группе машин, либо перейти к статистике конкретного робота (к этому сценарию я вернусь позже).
Центральная часть — аналитика
Центральную область интерфейса я разделил на два смысловых блока:
Статистика простоев
Загрузка и эффективность
По умолчанию отображается статистика по всем роботам. Если в левой панели применён фильтр, графики автоматически перестраиваются под выбранную группу.
В блоке статистики простоев аналитик может оценить частоту поломок, их причины и при необходимости отфильтровать данные по конкретному типу неисправностей.
В блоке загрузки и эффективности отображается объём выполненных задач и ошибки, возникшие в процессе доставки. При необходимости аналитик может быстро перейти к конкретной проблемной задаче, чтобы разобраться в её причинах.
Над графиками расположен общий набор инструментов:
фильтр по дате,
кнопка обновления данных (с индикатором актуальности),
возможность экспорта статистики.
Сценарий использования аналитиком
Путь пользователя в системе выглядит следующим образом:
В левой панели выбираю фильтры по модели, поколению и району
Сортирую роботов по нужному параметру
Выбираю группу роботов или конкретную машину
Нажимаю «Показать статистику»
В центральной части задаю период анализа (по умолчанию — текущие сутки)
Работаю с настройками графиков:
— фильтрую поломки по типу — группирую данные — изменяю единицы измерения
Экспортирую подготовленную статистику и формирую отчёт
UI и дизайн в Figma
Цвета, шрифты и системные элементы были выполнены строго в соответствии с Gravity UI. Перед началом работы я подробно изучил дизайн-систему, чтобы использовать компоненты в корректном контексте и не нарушать принципы платформы.
Цветовую иерархию я строил по принципу: чем важнее информация — тем она заметнее.
Ошибки и предупреждения сразу привлекают внимание, в то время как системные элементы остаются нейтральными и не перегружают интерфейс.
Дополнительное задание: статистика одного робота
В дополнение к основному заданию я спроектировал отдельный сценарий — детальную аналитику по конкретному роботу. Аналитик попадает в него, кликнув по машине в левой панели.
Логика работы остаётся прежней, меняется только наполнение центральной части. Интерфейс делится на два блока:
Эффективность робота
История
Слева аналитик видит график эффективности, на котором отмечены дни с ошибками и сбоями.
Справа расположена лента истории робота. В ней можно отследить:
текущее местоположение,
возникавшие ошибки,
способы их решения,
выполненные задачи и временные промежутки.
Историю можно фильтровать по категориям, например — только заказы или только ошибки.
Чтобы фронтенд-разработчику не приходилось додумывать поведение интерфейса, в макете я показал:
крайние значения данных,
состояния при наведении,
поведение графиков при критических показателях.
Например, видно, как выглядит график эффективности в день, когда произошёл сбой и показатель упал до 0%.
В верхней части экрана размещена кнопка «Назад», которая возвращает пользователя к общей статистике по всем роботам.
Заключение
Если смотреть на дальнейшее развитие концепта, я бы предложил несколько улучшений:
добавить сравнение групп роботов (по районам или поколениям),
реализовать сохранение наборов фильтров и быстрое закрытие тегов,
внедрить переключатель «Учитывать свободных роботов» в графике эффективности, чтобы видеть полную картину загрузки и избегать простоев.
К сожалению, по этому проекту я не получил обратной связи от Яндекса.
Тем не менее, рад был поделиться этим кейсом с вами 🤍