Product Designer
Анастасия
Плотникова
Продуктовый дизайнер. Делаю сложные B2B-интерфейсы, в которых пользователь открывает систему и сразу начинает работать, а не разбираться, как она устроена.
за интерес)
Пишите!
Product Designer
Продуктовый дизайнер. Делаю сложные B2B-интерфейсы, в которых пользователь открывает систему и сразу начинает работать, а не разбираться, как она устроена.
Log Platform МТС — внутренняя платформа, через которую МТС доставляет клиентам свои товары: симки, роутеры, смартфоны. Логисты в ней принимают заказы из разных каналов продаж, собирают маршруты, распределяют их по подрядчикам и следят за доставкой до клиента. До платформы всё это жило в пяти разных ИТ-системах и Excel — единого инструмента для логиста не было.
Моя задача была — спроектировать автоматизированное рабочее место логиста, в котором он ведёт заказ целиком: собирает маршрут, управляет тарификацией и подрядчиками, не прыгая между системами.
Единственный дизайнер на продукте. Разбиралась в логистике с нуля, собирала сценарии, проектировала экраны и состояния, передавала всё в разработку.
Логистика держалась на ручной работе: строки в Excel, переписки в мессенджерах, звонки, чтобы уточнить статус. Данные по заказам, маршрутам и подрядчикам лежали в разных системах и между собой не дружили.
Логист тратил часы, чтобы собрать табличку. А если ошибся при создании маршрута — узнавал об этом уже в доставке, когда исправить сложно и дорого.
Сама превращала техзадачи в продуктовые
Команда инженерная, задачи приходили на языке системных аналитиков — без ответа на главный вопрос: зачем это логисту и что он должен сделать.
Поэтому перед проектированием я сама дособирала задачу: что болит у логиста, в какой момент он приходит на этот экран, что ему нужно на выходе. Иначе в разработку уходили бы экраны, в которых невозможно работать.
Логистам и руководителям постоянно нужно было смотреть одно и то же: что происходит с заказами, где проседает доставка, какие маршруты проблемные, как работают подрядчики. Раньше эту инфу собирали руками из разных мест.
Я собрала её в дашборд: с первого экрана видно, где всё нормально, а куда нужно провалиться и разобраться.
Маршрутов в системе много, и логисты ищут их по-разному — у каждого свой сценарий работы.
Я спроектировала таблицу так, чтобы логист сам настраивал нужные колонки, быстро фильтровал список и открывал нужный маршрут. Главная идея — таблица должна помогать работать, а не просто показывать данные.
В создании маршрута десятки зависимостей и ограничений, которые влияют друг на друга. Если показать всё одной длинной формой, логист легко теряется и пропускает важное.
Я разбила создание на понятные блоки и добавила навигацию слева. Логист видит, где он сейчас, какие разделы уже заполнены, где ошибка и что нужно поправить перед сохранением. Это снижает риск собрать маршрут с неправильными условиями.
Чтобы понять, что происходит с заказом, логисту нужен не один статус, а весь контекст вокруг него.
Я разложила карточку по вкладкам, чтобы на первом экране не было свалки из данных. Главное видно сразу, детали лежат в понятных разделах. Логист не бегает по системам и не собирает заказ по кускам — открывает карточку и сразу понимает, что с ним и где искать проблему.
Маршрут зависит не только от адреса. На него влияет много связанных условий, и раньше эта логика жила в документах, таблицах или просто в голове опытных сотрудников.
Я вынесла эти связи в интерфейс. Логист видит, с чем связан маршрут, какие условия на него влияют и почему он работает именно так. Решение пришло после общения с пользователями, которые жаловались, что сложно держать всё это в голове.
Зоны доставки плохо читаются списком координат. Логисту нужно видеть карту: где проходит граница, какие районы попадают в зону, нет ли пересечений.
Я добавила работу с полигонами: можно загрузить GeoJSON, увидеть зону на карте и проверить, как она связана с маршрутом. География перестала быть набором непонятных чисел и стала рабочим инструментом.