Транспорт 72
Декабрь 2024 — март 2026 · Ведущий продуктовый дизайнер · iOS · Android
Коротко о главном
Обновил единственное официальное приложение общественного транспорта Тюменской области — интерфейс не менялся 8 лет, рейтинг 2,8★. За 15 месяцев объединили два сервиса в одно приложение, вынесли расписание на первый экран, добавили кэш расписаний, сохранённые маршруты и интеграцию с транспортными картами. В тестах APK переходы «расписание → маршрут» выросли на 40%, задача «найти рейс и запустить маршрут» — 7 из 8 участников за 45 секунд против 2 минут в старом приложении. После релиза рейтинг вырос до 3,7★ на iOS и 3,0★ на Android.
Контекст
Центр информационных технологий Тюменской области выпустил контракт на обновление системы мониторинга общественного транспорта. В эту систему входило мобильное приложение «Транспорт 72». Я подключился до старта работ, собрал команду с нуля и выстроил процесс работы с государственным заказчиком.
С чем обратился заказчик
«Транспорт 72» — единственное официальное приложение общественного транспорта Тюменской области. Интерфейс не обновлялся 8 лет. По данным заказчика на старте приложения было больше 100 000 установок, 35 000 активных пользователей в месяц и рейтинг 2,8★ в Google Play.
Люди не могли быстро узнать, когда придёт автобус. Главные жалобы: «нет расписания», «непонятно, где автобус», «невозможно пополнить карту». При этом параллельно существовало отдельное приложение «Тюменьгортранс» — жителям приходилось держать два приложения и переключаться между ними.
Низкий рейтинг угрожал показателям региона по цифровым сервисам и федеральному финансированию. По контракту нужно было: объединить два приложения в одно, вывести расписание на первый экран, добавить работу без интернета, встроить транспортные карты и продажу межгородских билетов.
Что усложняло работу
Данные поступали из двух источников с несовместимыми форматами. Региональная система «МУОТ» — одна, городской перевозчик «Тюменьгортранс» — другая. У городского перевозчика не было привязки конкретного автобуса к рейсу, номера остановок не совпадали, одни и те же остановки существовали дважды в разных базах. Только на то, чтобы свести эти данные вместе, бэкенд потратил около 480 часов. Это напрямую влияло на проектирование: каждый сценарий нужно было продумывать в трёх вариантах — данные есть, данные неполные, данных нет совсем.
Исследование
Перед проектированием провел конкурентный анализ шести приложений: Тюменский транспорт, Транспорт 72 (старая версия), Мостранс, Яндекс, Moovit, 2ГИС — изучал подходы к расписанию, построению маршрутов и доступности. Я проанализировал 50+ пользовательских сценариев в старом приложении, провёл встречу с диспетчерами и качественное исследование с пользователями. В рамках проекта совместно с Департаментом информатизации Тюменской области провели открытую фокус-группу в «Точке кипения — Тюмень» — жители не просто тестировали обновлённую версию, а предлагали идеи.
70% людей открывают приложение только ради одного — узнать расписание. Значит, расписание должно быть первым экраном, а не спрятано куда-то вглубь.
Каждый третий пользователь увеличивает шрифт на телефоне. Это не мелочь — это треть аудитории, которая не может нормально пользоваться интерфейсом, если его не адаптировать.
Два приложения вместо одного — главная причина плохих отзывов от новых пользователей.
На загородных маршрутах часто нет мобильной связи — офлайн-расписание там не удобство, а необходимость.
Пользователи вручную собирают маршруты из нескольких точек, потому что такого сценария в приложении просто нет.
Первая гипотеза
Если объединить два приложения в одно, вывести расписание на первый экран с кэшем для работы при слабом соединении и добавить сохранение маршрутов из нескольких точек — конверсия «посмотрел маршрут → запустил навигацию» достигнет 25% и выше, а рейтинг вырастет с 2,8★ до 4,0★ за девять месяцев.
Как выглядел успех — до начала работы
Вместе с руководителем продукта и аналитиком зафиксировал цели ещё до старта проектирования.
  • ≥ 25%
    Конверсия «построил маршрут → запустил навигацию»
  • ≥ 60%
    Доля уникальных пользователей, открывших расписание автобусов
  • ≥ 4,0★
    Рост рейтинга Google Play за девять месяцев
  • −30%
    Число обращений «Где автобус?» в контакт-центр относительно периода до релиза
Решение и макеты
Техническое задание зафиксировало список требований. Моя задача — превратить этот список в рабочие сценарии с приоритетами и состояниями.
Расписание как первый экран. Я обосновал приоритет расписания через данные исследования: 70% сессий начинаются с вопроса «когда». Добавил сохранение последнего открытого раздела — пользователь возвращается туда, где остановился. В разделе расписания: список ближайших остановок по геолокации, рейсы отсортированы по времени прибытия, цветовая маркировка размера автобуса — маленький, средний, большой, очень большой, — иконки для маломобильных пассажиров: низкий пол, специальные условия для входа. Если нет интернета — показывается плановое расписание вместо прогноза в реальном времени.
Офлайн-кэш. Предложил бэкенду схему обновлений, при которой приложение скачивает только изменения, а не всё расписание целиком. Это важно там, где интернет медленный или нестабильный. Потребность из исследования закрыта частично: на загородных маршрутах показывается кэшированное расписание, но полный офлайн-режим не реализован — реализовали кэш части данных и уведомление об отсутствии сети. Полный пакет расписаний на 14 дней по всей области не уложился в приемлемый размер — это был осознанный компромисс, зафиксированный до релиза.
Карта с живыми автобусами. Раздел карты при выборе остановки показывает, где сейчас находится транспорт. Значки остановок появляются в зависимости от масштаба. При нажатии на остановку — панель с маршрутами и прогнозом: показываются только те автобусы, которые реально проходят через эту остановку, прямо из этой панели можно построить маршрут. Такой подход не держит пользователя в полном контексте движения автобусов, это осознанный компромисс — без такой фильтрации каждый запрос уходил по всем ~900 единицам транспорта одновременно и ронял сервер с ошибкой 502.
Выбор карты под собой и кэш тайлов. После подключения 2ГИС добавил возможность выбирать картографическую подложку в настройках: либо официальная карта региональной системы, либо 2ГИС. Проблему «мозаики» из разнородных кусочков карты при переключении предложил решить отдельным кэшем для каждой подложки с временем жизни — при возврате к старому варианту карта уже есть, ничего не перегружается. Кнопку «сбросить кэш» решили не делать: это техническая история, не пользовательская.
Маршруты и их сохранение. Спроектировал структуру объектов, логику ежедневных маршрутов с быстрым доступом с главного экрана. Покупка межгородских билетов встроена в раздел «Сервисы». Сценарий «построил маршрут с пересадкой на межгород → купил билет прямо здесь» спроектировал, но в релиз он не вошёл — API перевозчика не позволил. Ушёл в список задач на следующую версию.
Сервисы. Добавление и просмотр карт ТТС, история транзакций, пополнение через web-view сервиса оператора ТТС — деньги зачисляются на карту не мгновенно: платёж фиксируется на сервере, а баланс обновляется на чипе карты при следующем прикладывании к валидатору в автобусе. Я предложил перейти на открытый API АСОП, но реализовать не удалось из-за ограничений на стороне оператора. Проектировал сценарии деградации: что показывает приложение если шлюз недоступен, карта заблокирована, история не загружается.
Доступность — отдельно, не как дополнение. Добился того, чтобы доступность стала отдельным приоритетом с первого спринта. Курировал проектирование отдельных макетов компонентов для увеличенного шрифта — 120–140% от стандартного, режим высокой контрастности, поддержку голосового управления на Android и iOS.
Системные состояния. Уведомления об отсутствии геолокации, о некорректном времени на устройстве, о потере соединения. Подсказки при первом запуске. Список изменений — показывается один раз после обновления. Полное покрытие состояний сократило количество вопросов на этапе тестирования.
Тесты до релиза
Кликабельный прототип, восемь участников. Задача — «найти ближайший рейс и запустить маршрут»: семь из восьми справились меньше чем за 45 секунд. В старом приложении тот же сценарий занимал в среднем больше двух минут — по данным анализа сессий. По данным журнала событий нового приложения: переходы «расписание → построить маршрут» выросли на 40% по сравнению со старым. Два запроса от участников зафиксированы как приоритетные: отображение направления движения у ближайших остановок — чтобы пользователь понимал с какой стороны дороги садиться на автобус — и уведомления об изменениях маршрутов.
Мой личный вклад
Собрал команду с нуля, выстроил процесс работы с государственным заказчиком, определил этапы сдачи.
Инициировал и провёл пользовательское исследование до старта проектирования — инсайты легли в основу IA и приоритизации фич.
Спроектировал структуру приложения; приоритет функций обоснован данными, а не интуицией.
Полностью закрыл сценарий сохранённых маршрутов из нескольких точек: структура объектов, все состояния, нестандартные ситуации.
Добился приоритизации доступности с первого спринта; курировал дизайнера по сложным случаям.
Предложил push-уведомления о прибытии транспорта и виджет для домашнего экрана — оба решения спроектированы и добавлены в беклог следующей версии.
Проектировал сценарии с учётом технических ограничений двух источников данных.
Курировал мидл-дизайнера, компонентную работу и нестандартные ситуации. Синхронизировался по каждому экрану перед передачей в разработку.
Работа с командой
С руководителем продукта и аналитиком. Участвовал в формировании списка задач с нуля — не получал готовые задачи, а совместно определял приоритеты. На каждом этапе фиксировал письменно, что входит в релиз, и добивался подтверждения перед передачей в разработку.
С бэкендом. Согласовал формат обновлений, версионирование, контроль размера данных. Согласовал ограничение одновременных запросов на стороне приложения. Формулировал технические требования к программному интерфейсу: логика направлений, сценарии деградации платёжной системы, обработка незаполненных полей от «Тюменьгортранс».
С мидл-дизайнером. Разделил зоны ответственности: взял на себя IA, ключевые сценарии и нестандартные ситуации, передал компонентную работу и корнер кейсы под своим контролем. Синхронизировался по каждому экрану перед передачей в разработку.
С платёжной стороной. Согласовал окна обновлений системы оплаты и спроектировал сценарии на случай проблем: что показывает приложение, если шлюз недоступен, карта заблокирована, история не загружается.
С «Тюменьгортранс». Фиксировал сообщения об ошибках в данных расписания начиная с осени 2025. До релиза реакции не было. После релиза это стало главной причиной негативных отзывов в январе 2026. Внешние поставщики данных без обязательств по качеству — это контрактный риск, который нужно решать на уровне договора, а не в рабочем порядке.
С государственным заказчиком. На предварительной приёмке часть функционала — построение маршрутов и ежедневные маршруты — была зафиксирована как нереализованная. Команда устранила все замечания до финальной сдачи. Контракт закрыт в срок.
С Департаментом информатизации. Совместно организовали открытую фокус-группу с жителями Тюмени — заместитель губернатора Станислав Логинов лично участвовал в сборе обратной связи.
Результаты
Приложение вышло. К январю 2026 — версия 1.1.2, несколько обновлений после релиза.
Рейтинг в Google Play вырос с 2,8★ до 3,0★. На iOS приложение появилось впервые и сразу получило 3,7★.
Рост есть, но на небольшой выборке и в условиях нерешённых проблем на стороне подрядчика.
Целевые метрики по конверсии и активным пользователям в процессе сбора — продукт ещё не стабилизировался.
Риски и ошибки
Технический долг при сдаче. Названия маршрутов не отображались в поиске, масштабирование значков работало некорректно, сортировка избранного не была реализована. Проблемы были известны команде и намеренно не показывались заказчику при приёмке. Они стали первой волной негативных отзывов в январе 2026. Если бы зафиксировали открыто с планом устранения — часть отзывов не появилась бы.
Расписание не показывалось у части пользователей. Жалобы в январе 2026: «нет данных», «нет транспорта на линии». Причина — на стороне «Тюменьгортранс»: они не реагировали на сообщения об ошибках ещё с осени. Я фиксировал обращения начиная с осени 2025, рычага влияния не было. Правильное решение — эскалировать отсутствие реакции на уровень контракта, а не разбираться в рабочем порядке.
Приложение не работало в отдельных городах области. Заводоуковск, Ишим — жалобы в феврале–марте 2026. Причины: адреса серверов не были добавлены в разрешённые списки операторами через Минцифры до релиза; ограничения «суверенного интернета». Первое — зона ответственности заказчика, но команде стоило настойчивее закрыть это до публикации.
Поиск работал через внешний сервис геокодирования. До релиза было известно: при реальной нагрузке токен не выдержит. Приняли как осознанный риск с планом перехода на другой геокодер. Переход не был реализован до релиза. Дополнительно — команда не договорилась о логике ранжирования результатов до разработки. Задержки в поиске зафиксированы в системе мониторинга ошибок. Ошибка постановки задачи, не реализации.
Карта. После публикации переехали с прямого подключения к картографическому сервису на прокси — растровая подложка стала грузиться медленнее. При переключении подложек у пользователей появилась «мозайка» из кэшированных кусочков карт разных версий. Я предложил решение через раздельный кэш для каждой подложки с временем жизни — при переключении обратно карта уже есть, ничего не перегружается. Но картографический сервис начал блокировать запросы — все шли с одного адреса. Собственный тайловый сервер, который закрыл бы эту зависимость, всё ещё в работе.
Пополнение карты не мгновенное. Пользователи ожидают что деньги зачислятся сразу после оплаты в приложении — но баланс обновляется на чипе карты только при следующем прикладывании к валидатору в автобусе. Это архитектурное ограничение закрытой схемы ТТС, не ошибка приложения. Часть негативных отзывов связана именно с этим — пользователь заплатил, а проехать не может. Предложил решение с переходом на открытый API, но это изменения на стороне оператора.
Выводы
Для задач «когда придёт автобус» время важнее места. Перестройка первой вкладки под расписание дала рост переходов «расписание → маршрут» на 40% ещё до релиза — данные тестов приложения подтвердили гипотезу из исследования.
Технический долг при сдаче — это отложенный репутационный риск. Обойдённые при приёмке проблемы становятся первой волной отзывов. Лучше зафиксировать публично с планом, чем скрыть и получить 1★.
Внешние поставщики данных без обязательств по качеству — контрактный риск, не рабочий. Отсутствие реакции «Тюменьгортранс» на сообщения об ошибках нужно было эскалировать в условия контракта заранее.
Логику поиска нужно согласовать до разработки. Если команда по-разному понимает как должны ранжироваться результаты — пользователи почувствуют это сразу.
Осознанный технический долг лучше неожиданного. Риск с геокодером был известен до релиза и зафиксирован. Это лучше, чем обнаружить проблему в продакшне.
Нагрузочные тесты нужны на полном наборе данных. На урезанном количество запросов и вес кэша не проявляются.
Потребность из исследования не всегда закрывается полностью — и это нормально. Офлайн-режим был критичен по данным исследования, но полный пакет не уложился в приемлемый размер. Важно зафиксировать компромисс до релиза и честно описать его пользователям — а не обнаружить несоответствие в отзывах.
Архитектурные ограничения внешних систем — это тоже UX-проблема. Пополнение карты не мгновенное не потому что плохой дизайн, а потому что баланс хранится на чипе. Такие ограничения нужно выявлять на этапе исследования и либо проектировать обходные пути, либо объяснять пользователю что происходит — до того как он заплатил и не смог проехать.
Беклог — это не список провалов, а управляемый объём. Покупка билета из маршрута, виджет, push-уведомления — всё это спроектировано и зафиксировано. Фиксировать что не войдёт в релиз так же важно как фиксировать что войдёт — это снижает хаос после запуска и даёт команде чёткий старт для следующей версии.
Что дальше
До релиза команда сформировала список задач для следующих версий, часть из них прямой ответ на проблемы, которые уже проявились.
Навигация и переходы. Сейчас пользователь не может вернуться на экран остановки после выбора маршрута — только закрыть и начать заново. Сохранение позиции при переходах и логика кнопки «назад» по всему пути пользователя спроектированы, в списке задач.
Push-уведомления о прибытии автобуса. Заблаговременное уведомление когда транспорт подъезжает к выбранной остановке.
Виджет для домашнего экрана. Быстрый доступ к сохранённым маршрутам — «Домой», «На работу» — без открытия приложения. Одно нажатие запускает навигацию по нужному маршруту.
Интерактивная схема маршрута. Остановки на схеме — белые кружки без действия. Нельзя нажать на остановку и перейти к её расписанию. Спроектировано, в списке задач.
Система масштабирования карты. Детально проработана логика видимости объектов: остановки скрыты до 14, точки до 16, иконки до 19, с названием от 20. Сейчас объекты появляются резко, без промежуточных состояний.
Единая терминология для «маршрута» и «автобуса». В интерфейсе эти понятия смешаны — одно слово используется и для схемы маршрута, и для конкретного автобуса с номером. Требует системного переименования.
Уведомление о неподдерживаемом регионе. Прямой ответ на жалобы из городов, где приложение не работает. Пользователь должен знать, что приложение работает не везде, — а не получать пустой экран.
Оплата проезда через GEOPay. Идея от заказчика: сервис определяет ближайший транспорт по геолокации и позволяет оплатить проезд без валидатора — автоматическая идентификация смартфона пассажира в транспортном средстве.
Покупка билета из построенного маршрута. Сценарий «построил маршрут с пересадкой на межгород → купил билет прямо здесь» спроектирован, но не вошёл в релиз из-за технических ограничений на стороне перевозчика — доступна только через раздел «Сервисы».
Открытый API АСОП и мгновенное пополнение. Текущая интеграция работает через web-view закрытой схемы — деньги попадают на карту только при следующем прикладывании к валидатору. Переход на открытый API убрал бы этот разрыв в пользовательском опыте, но требует изменений на стороне оператора.
Направление движения у остановок. Пользователи на тестировании попросили показывать у ближайших остановок в какую сторону идёт транспорт — чтобы точно понимать с какой стороны дороги садиться.
На главную
Следующий проект
Новости о проекте
7+ лет опыта работы · от первых идей до разработки продукта
Давайте работать вместе!