Компания Ракета – российский разработчик цифровой платформы и мобильного приложения для организации командировок и управления расходами.
Платформа была создана в 2011 году, став первым онлайн-инструментом, который предлагал корпоративным клиентам быстрое и простое решение для организации бизнес-поездок под ключ.
2019 компания стала финалистом Disrupt Launchpad & Award на Business Travel Show в Лондоне, а также технологическим партнером крупного международного сообщества тревел-агентств Travel Leaders Network.
В 2022 году победила в престижной премии Buying Business Travel Awards в номинации «Технологии».
Мобильное приложение
Мобильное приложение «Rocket in your pocket» от Ракеты - это спутник и помощник, который будет с вами 24/7.
В нем всегда можно забронировать билеты, отели, трансферы и любые другие тревел-услуги, получить информацию об уже оформленных бронях.
Также в приложении удобно хранить карты лояльности, визы и документы - они всегда будут под рукой.
Бизнес-путешественники по достоинству оценят и другую полезную опцию мобайл-приложения: прямо в него можно загружать чеки, квитанции по расходам во время командировок и по окончании деловой поездки легко и быстро передавать информацию и отчетность финансовому департаменту.
Кроме того, в Ракете можно подписывать командировочные документы электронной подписью прямо на смартфоне благодаря интеграции с "Госключом". Это удобно и безопасно.
Возможности:
• забронировать билеты, отели, трансферы и любые другие тревел-услуги
• получить информацию о рейсах, билетах и трансферах
• скачать ваучеры отелей и брони апартаментов
• посмотреть интерактивные карты городов, геолокации и места размещения
• визы, карты лояльности
• составить авансовый отчет и подписать его электронной подписью (ЭП) благодаря интеграции с "Госключом"
• загрузить чеки и квитанции по расходам в командировке
• узнать погоду в месте назначения
Кейс
Разработка мобильного приложения — «Rocket in your pocket»
В течении нескольких месяцев я работал над созданием продукта для деловых путешественников — мобильного приложения «Rocket in your pocket».
Расскажу, какие шаги я предпринял и как пользователи получили пользу от моего решения.
Описание приложения и ссылки на Appstore, Google play, Rustore, Appgallery можно посмотреть тут.
Команда
Product Owner
Product Manager
Product designer (Моя роль)
Команда разработки IOS, Android
Оценка существовавшего приложения
Оценка существовавшего приложения включала оценку его технической реализации, удобства использования и бизнес-потенциала, а также измерение пользовательской удовлетворенности через рейтинги, отзывы пользователей и ключевые метрики.
Я пообщался с несколькими пользователями и составил список основных проблем приложения.
От бизнеса у меня был перечень нового функционала, который необходимо было разработать в новом приложении.
1. Исследование потребностей
Я провёл двенадцать глубинных интервью с пользователями, которые регулярно находятся в командировках: менеджеры среднего звена, специалисты по продажам, консультанты и сотрудники международных проектов. В ходе разговоров выяснилось, что их основные «боли» — это сложность планирования маршрутов, необходимость хранить билеты, чеки и отчёты в одном месте, а также отсутствие мгновенных уведомлений о изменениях рейсов. Эти проблемы говорят о том, что пользователи ищут экономию времени и единый контроль над всеми аспектами поездки.
Выводы:
• Пользователю нужен один инструмент, без переключения между разными сервисами.
• Можно увидеть детали поездки с привязкой к календарю.
• Билеты, расходы и отчётность.
• Поддержка и возможность управлять бронированием в реальном времени.
• Приложение должно работать быстро даже в условиях плохого интернета (например, в аэропорту).
Вводные вопросы – «разогрев» и понимание контекста
• Расскажите немного о себе: должность, отрасль, сколько командировок у вас в среднем в год?
• Какие типы поездок вы обычно совершаете (внутренние, международные, короткие/длительные)?
• Какими устройствами и приложениями вы сейчас пользуетесь для организации деловых путешествий (билеты, отели, расходы)?
Проблемы текущих решений
• Опишите типичный процесс планирования одной командировки от начала до конца. Какие шаги вам приходится выполнять вручную?
• Какие задачи вызывают у вас наибольшие трудности или раздражение (поиск билетов, хранение чеков, согласование расходов и т.д.)?
• Бывали ли случаи, когда из‑за проблем с текущими инструментами вы опоздали на рейс, потеряли документ или получили штраф за неверный отчёт? Расскажите подробнее.
Требования к новому продукту
• Какие функции в идеальном приложении для деловых путешествий были бы «must‑have» (обязательные)?
• Насколько важна для вас возможность работать офлайн (например, в аэропорту без Wi‑Fi)? Почему?
• Какой уровень детализации отчётов о расходах вам нужен: простая сводка или полные сканы чеков с категоризацией?
Взаимодействие и пользовательский опыт
• Опишите ваш обычный способ ввода расходов (ручной ввод, фото чека, интеграция с корпоративным банком). Что в этом процессе вам нравится/не нравится?
• Как часто вы проверяете статус рейса во время поездки? Какие уведомления (изменения времени, гейты, погода) вам нужны в реальном времени?
• Насколько важна для вас персонализация интерфейса (тёмная тема, размер шрифта, быстрый доступ к часто используемым функциям)?
Безопасность и конфиденциальность
• Какие данные вы считаете чувствительными в контексте деловых поездок? Какой уровень защиты/шифрования вам нужен?
• Какой способ аутентификации (пароль, биометрия, SSO) вы предпочитаете для доступа к корпоративным данным в приложении?
Интеграции и экосистема
• С какими внешними сервисами (авиакомпании, отели, такси, корпоративные ERP/HR‑системы) вам было бы удобно интегрировать приложение?
• Используете ли вы уже какие‑то корпоративные инструменты для согласования расходов? Как они работают и чего им не хватает?
Оценка текущих альтернатив
• Какие приложения (например, TripIt, Concur, Google Trips) вы пробовали? Что вам понравилось, а что – нет?
• Если бы вам пришлось выбрать одно приложение для всех своих деловых поездок, какие критерии стали бы решающими?
Заключительные вопросы
• Какой один совет вы бы дали команде разработчиков, чтобы их продукт стал действительно полезным для вас?
• Есть ли ещё что‑то, о чём мы не спросили, но что, по вашему мнению, важно учитывать при создании приложения для деловых путешественников?
Эти вопросы помогли собрать качественную информацию о реальных потребностях и болевых точках пользователей, а также сформулировать набор требований, которые впоследствии легли в основу блок‑схемы, UI‑дизайна и функций мобильного приложения «Rocket in your pocket».
2. Блок‑схема приложения
Для того чтобы визуально согласовать структуру продукта со стейкхолдерами, я создал блок‑схему приложения. В ней выделены основных части:
Навигационный модуль – таб‑бар с разделами «Поездки», «Новости», «Расходы», «Чат поддержки» и «Профиль».
Новости – новости компании и не только.
Поездки – страница приложения отображающая список командировок и их статусы.
Детали поездки – отображает список запланированых билетов и событий в поездке, возможность детально просматривать билеты, отельные ваучеры, трансферы с привязкой к календарю.
Поддержка – связь с личным менеджером и возможность изменять бронирование в реальном времени.
Модуль управления поездками – для пользователей с административным доступом.
Слой данных – локальная база, синхронизируемая с облачным API, что обеспечивает работу в офлайн‑режиме и быстрый доступ к информации.
Интеграционные шлюзы – соединения с API «Ракета» и корпоративным SSO для единого входа.
Модуль аналитики – сбор событий о действиях пользователей, который позволяет позже улучшать продукт на основе реальных данных.
3. Дизайн‑система и прототип
Дизайн‑система «Raketa»
Для обеспечения консистентности я разработал собственную дизайн‑систему. В ней определены фирменные цвета компании Ракета (Color tokens разделены по группам: текст, иконки, кнопки, статусы, разделители, фоны, тени, состояния), типографика (Inter со стилями заголовков и текста), набор переиспользуемых компонентов — кнопки, таббар, модальные окна, кастомные SVG‑иконки и тд. Все токены и компоненты дизайн системы должны соответствовать стандарту WCAG (Руководства по доступности веб-контента) — это набор рекомендаций по созданию доступных цифровых продуктов, которые применяются и к мобильным приложениям, а не только к веб-сайтам. Принципы WCAG — Воспринимаемость, Управляемость, Понятность и Надежность — помогают обеспечить равный доступ к информации для пользователей с ограниченными возможностями, включая нарушения зрения, слуха, моторики и когнитивных функций.
Прототипирование в Figma
Я создал интерактивный прототип из 60+ экранов и их состояний, который можно было кликать на реальном устройстве. Прототип включал адаптивные варианты для iOS и Android.
4. Пользовательское тестирование прототипа
Кликабельный прототип + интервью
Я пригласил 10 представителей целевой аудитории протестировать интерактивный прототип на их смартфонах. Сессии записывались, а участникам предлагалось ответчать на вопросы и излагать свои мысли. После каждой сессии я фиксировал замеченные боли и создавал гипотезы по улучшению.
Портреты пользователей
Алексей, 34 года, менеджер проекта в консалтинговой компании
Часто ездит в командировки, управляет несколькими проектами одновременно.
• Требует быстрый доступ к расписанию рейсов и возможность мгновенно менять бронирования.
• Нужен единый журнал расходов для последующей отчётности перед бухгалтерией.
Марина, 29 лет, специалист по продажам
Проводит встречи с клиентами в разных городах.
• Ценит возможность хранить электронные билеты и чеки в одном месте, чтобы не искать их в почте.
• Хочет получать push‑уведомления о задержках рейсов и изменениях в отелях, а так же оперативно общаться с личным менеджером компании Ракета.
Игорь, 41 год, руководитель отдела продаж крупной компании
Управляет поездками для команды из 50 человек.
• Нужен инструмент для группового планирования и управления командировками, контроль бюджета.
Юзабилити тестирование
Я провёл интервью через серию сквозных сценариев – от входа в приложение до закрытия поездки. После каждого сценария участнику предлагалось коротко ответить на вопрос и дать несколько оценок по небольшой шкале удовлетворённости, чтобы приблизительно оценить CSI (Customer Satisfaction Index) приложения на этапе прототипа.
Общее восприятие и первая реакция
• Что вы ожидаете увидеть сразу после входа в приложение?
• Насколько быстро вам удалось понять, какие задачи решает приложение?
Навигация по разделам
• Какой путь вы выбрали, чтобы перейти от списка текущих поездок к деталям конкретной командировки? Было ли это интуитивно понятно?
• Где находится кнопка «Отчёты»? Сколько кликов потребовалось, чтобы открыть её?
Работа с подтверждёнными рейсами
• Вы видите информацию о рейсе. Насколько полно она отображается (номер рейса, время вылета/прилёта)?
• Как быстро вы смогли открыть электронный билет»?
Ввод и классификация расходов
• Попробуйте добавить новый расход. Какие поля вам пришлось заполнять? Было ли понятно, в какую категорию относится каждый тип расхода (транспорт, проживание, питание)?
• Как вы проверяете, что расход успешно сохранён? Что показывает система подтверждения?
Просмотр и согласование расходов
• Какие данные вы считаете чувствительными в контексте деловых поездок? Какой уровень защиты/шифрования вам нужен?
• Какой способ аутентификации (пароль, биометрия, SSO) вы предпочитаете для доступа к корпоративным данным в приложении?
Уведомления и push‑сообщения
• С какими внешними сервисами (авиакомпании, отели, такси, корпоративные ERP/HR‑системы) вам было бы удобно интегрировать приложение?
• Используете ли вы уже какие‑то корпоративные инструменты для согласования расходов? Как они работают и чего им не хватает?
Работа без интернета
• Какие приложения (например, TripIt, Concur, Google Trips) вы пробовали? Что вам понравилось, а что – нет?
• Если бы вам пришлось выбрать одно приложение для всех своих деловых поездок, какие критерии стали бы решающими?
Обратная связь по визуальному дизайну
• Какой один совет вы бы дали команде разработчиков, чтобы их продукт стал действительно полезным для вас?
• Есть ли ещё что‑то, о чём мы не спросили, но что, по вашему мнению, важно учитывать при создании приложения для деловых путешественников?
Итоговое впечатление
• Оцените общую удобность работы с приложением от 1 до 5. Что бы вы изменили в первую очередь?
A/B-тесты
Так же на этапе юзабилити тестирования я проводил A/B тесты, опрашивая пользователей, просил проголосовать за тот или иной вариант. Фиксировал влияние на целевые события и CSI затронутых сценариев.
Вариант A – текущая карточка с расширенным набором полей.
Вариант B – только фото направления, статус поездки, даты начала/завершения и «из какого города >> в какой».
Метрики – время до открытия нужной поездки, конверсия «список >> детали», количество возвратов назад, доля неверных открытий, CSI по сценарию «поиск нужной поездки».
Гипотеза – модульная подача сократит путь к нужной информации.
Вариант A – длинный экран с прокруткой и смешанными блоками.
Вариант B – краткие карточки сущностей — авиабилет, ж/д билет, аэроэкспресс, трансфер, отельный ваучер, деловая встреча, тап открывает полный экран сущности с подробностями и кодом для автоматической регистрации в случае билетов.
Метрики – время до кода регистрации, доля открытий нужной сущности с первой попытки, число возвратов, CSI по сценарию «детали поездки».
Гипотеза – использование календаря с горизонтальной прокруткой более удобно пользователям.
Вариант A – использование календаря в виде Date picker.
Вариант B – календарь с горизонтальной прокруткой.
Метрики – CSI по сценарию «детали поездки».
A/B-тест 4 — Добавление расхода (карточки-модули)
Гипотеза – кнопку добавления расхода лучше разместить в Tabbar.
Вариант A – кнопка добавления расхода размещена вверху, на экране детали поездки.
Вариант B – кнопка добавления расхода размещена в Tabbar.
Метрики – кол-во кликов, доля открытий нужной сущности с первой попытки, CSI по сценарию «детали поездки».
A/B-тест 5 — Добавление расхода
Гипотеза – сокращение полей увеличит завершение и снизит ошибки.
Вариант A – расширенная форма которая предлагалась бизнесом.
Вариант B – только дата, категория, сумма, валюта, комментарий и прикрепление чека/документа.
Метрики – завершение формы, среднее время заполнения, доля прикреплённых чеков, доля повторных действий после ошибки ввода, CSI по сценарию «добавление расхода».
Проблемы и решения
• Пользователи не находили кнопку «Добавить расход» на экране поездки. Я переместил её в таббар, сделав кнопку яркого акцентного цвета, чтобы она была всегда под рукой.
• В списке поездок было трудно отличать подтверждённые от ожидающих или отклоненных. Добавил визуальные метки — цветовую индикацию и небольшую иконку статуса в каждой карточке поездки.
• К деталям поездки у пользователей были вопросы, пользователи предлагали различные варианты улучшений. Сделал улучшеную версию таймлайна, изменил карточки билетов, отельных ваучеров, событий и тд., с учетом замечаний и пожеланий пользователей.
• Пользователи захотели видеть прогноз погоды в пункте назначения. Интегрировал небольшую карточку прогноза с OpenWeather, разместив её на экране деталей поездки.
• Userflow модуля управления поездками вызывал вопросы у некоторых пользователей, не хватало части функционала, который появился в процессе работы над приложением позднее. Добавил требуемый функционал, улучшил userflow.
После внесения правок провел повторное тестирование: уровень удовлетворённости CSI (Customer Satisfaction Index) вырос.
5. Передача в разработку и тестирование QA
После согласования дизайна я подготовил передачу в разработку: спецификацию экранов и состояний, описание поведений, список граничных кейсов, токены и компоненты дизайн-системы. Сопровождал имплементацию на iOS и Android, отвечал на вопросы, уточнял взаимодействия и при необходимости оперативно вносил правки. После завершения реализации продукт прошёл тестирование у QA: функциональные сценарии, обработка ошибок, офлайн-режим, стабильность и производительность.
6. Аудит соответствия дизайну
По итогам тестирования я провёл аудит соответствия: сравнил реализованные экраны с макетами, проверил навигацию, отступы и типографику, состояния загрузки и пустые состояния, кликабельные области. Все расхождения описал в задачах с приоритетами; критичные исправили до релиза, остальные запланировали в ближайшие спринты.
7. Тестирование приложения
Для теста приложения на IOS мы использовали testflight и рассылали ссылку на скачивание по корпоративным каналам, для Android использовали apk. Приложение работало в тестовом режиме с установленым демо контентом. В тесте участвовало несколько десятков человек.
На этапе тестирования, так же проводились A/B тесты.
8. Аналитика
Вместе с продактом я перешёл к анализу ключевых показателей по основным сценариям: онбординг, создание и просмотр поездок, работа с деталями билетов и ваучеров, добавление расходов, офлайн-режим, поиск документов и обращение в поддержку.
Отдельно использовал CSI (Customer Satisfaction Index) как индикатор восприятия качества. Оценку собирали внутри приложения после завершения ключевых действий по 5-балльной шкале удовлетворённости; значения нормировал в диапазон 0–100 и считал средневзвешенное по сценариям (вес — доля трафика и критичность для бизнеса):
CSI = (Σ оценкаᵢ / (N × 5)) × 100.
Что мы отслеживали
Онбординг и активация – конверсия установки >> первый запуск, завершение онбординга, время до первой ценности (Time-to-Value) — получение деталей билета/ваучера.
Навигация и поиск информации – время до открытия нужного билета, доля пользователей, нашедших код для регистрации с первого экрана, количество возвратов назад, глубина скролла на экране деталей.
Работа с поездками – конверсия «список поездок >> детали поездки», скорость считывания карточек, доля ошибок выбора.
Расходы и отчётность – завершение формы добавления расхода, среднее время заполнения, доля прикреплённых чеков/документов, доля повторных правок, доля успешно отправленных отчётов.
Уведомления и реакция – доля открытий по push/внутреннему баннеру, время до просмотра деталей изменения рейса/брони.
Качество и производительность – crash rate, доля успешных операций в офлайн-режиме с последующей синхронизацией.
Поддержка – доля чатов, открытых из сценариев «проблема с билетом/расходом», время до первого ответа, удовлетворённость обращением.
Удовлетворённость – CSI по сценариям (детали поездки, добавление расхода, поиск документов), общий CSI по приложению и его динамика.
9. Публикация
После проверки гипотез на основе A/B тестов, я внес финальные правки и мы опубликовали приложение в Google Play и App Store.
10. Итоги
От исследования и прототипирования, до релиза и экспериментов я последовательно построил продуктовую работу: сформулировал задачи по результатам интервью, разработал дизайн-систему и прототип, проверил решения на пользователях, передал и сопроводил разработку, провёл аудит соответствия, выпустил приложение в сторах. На основе данных запустил A/B-тесты и итеративно улучшил ключевые сценарии. В результате приложение отлично решает задачи целевой аудитории, а возросшая бизнес ценность, как и рост метрик подтверждает улучшение пользовательского опыта.
