Ракета победила в престижной международной премии в области корпоративных путешествий. Первая российская платформа с таким результатом.
Путешественник должен решать все задачи командировки без доступа к ноутбуку.
Упростить сбор чеков и формирование авансового отчёта прямо в поездке.
Один токен-сет и библиотека компонентов для моб. приложения и веб-платформы.
Выйти на уровень международных конкурентов, Concur, TripIt, по качеству UX.
«У меня 4 приложения: Ракета, почта с ваучерами, заметки с чеками и банк для отчёта. Хочу одно.»
Ваучер в почте, чек в заметках, билет в другом приложении.
Все документы внутри одной поездки, доступны офлайнНужен за 5 секунд, стоя в очереди. В старой версии, 4 клика.
Карточки-модули в деталях поездки, QR открывается с первого тапаФорма из 8 полей отпугивала. Чеки складывали «потом» и теряли.
Форма: 5 полей + фото чека, кнопка всегда в TabbarАэропорт, метро, зона без связи. Приложение должно работать в любом из этих мест.
Локальная БД с синхронизацией при восстановлении связи
Рейтинги, отзывы, ключевые метрики. Пообщался с текущими пользователями, составил список проблем. От бизнеса, перечень нового функционала.
Менеджеры, специалисты по продажам, консультанты. Вопросы о текущих болях, требованиях к новому продукту, конкурентах (TripIt, Concur, Google Trips).
Навигационный модуль, поездки, расходы, поддержка, профиль, офлайн-слой, интеграционные шлюзы, модуль аналитики. Согласовал со стейкхолдерами до первого пикселя.
Токены, компоненты, WCAG. Интерактивный прототип для iOS и Android, кликабельный на реальном устройстве.
Сквозные сценарии от входа до закрытия поездки. CSI по каждому сценарию после каждого теста. После внесения правок, повторный раунд.
Карточка поездки, детали поездки, варианты календаря, кнопка расхода, форма добавления расхода.
Спецификации, граничные случаи, токены. Аудит после имплементации: критичные расхождения, до релиза, остальные, в следующий спринт.
Несколько десятков тестировщиков. Демо-контент. После финальных правок, Google Play, App Store, RuStore, AppGallery.
| Этап | Цель пользователя | Ключевые действия / экраны | Эмоции / боли | Реакция системы | Метрики |
|---|---|---|---|---|---|
| 1. Планирование и согласование | Быстро подать заявку на командировку и дождаться согласования. |
|
Тревога: согласуют ли вовремя до брони. Неопределённость по бюджету. | Таймер автоотмены для руководителя, один тап на согласование, видимый бюджет. | Время согласования <2 мин, доля согласованных с первого касания. |
| 2. Бронирование | Выбрать подходящий рейс и отель в рамках политики компании. |
|
Сомнения в лучшей цене, страх нарушить политику. | Метка «в политике», сравнение с альтернативами, моментальный ваучер. | Конверсия поиск → бронь, доля «в политике», средний чек. |
| 3. Подготовка к поездке | Держать все документы под рукой и не забыть ничего важного. |
|
Стресс сборки: «все ли документы со мной». | Офлайн-пакет всех документов, модульные карточки, напоминания. | Открытия экрана деталей, доля офлайн-сессий, успех подписания УКЭП. |
| 4. В поездке | Быстро найти то, что нужно прямо сейчас, QR, трансфер, отель. |
|
Спешка в аэропорту, страх пропустить рейс, нет сети. | Главный сценарий, на 1-м экране. Офлайн. Поддержка в одно касание. | Время до QR <5 сек, response time поддержки, CSI сценария. |
| 5. Учёт расходов | Добавить расход быстро и не потерять чек. |
|
Лень и забывчивость: откладывают на конец недели, теряют чеки. | Моментальный ввод, 58 сек вместо 2:40, авто-отчёт. | Завершение формы 68% → 96%, доля прикреплённых чеков. |
| 6. Сдача отчёта | Сдать авансовый отчёт без ручной бумажной работы. |
|
Боль конца недели: собирать чеки, сводить цифры. | Отчёт формируется автоматически, остаётся проверить и подписать. | Время на отчёт: полдня → 10 мин, retention после первой поездки. |
Много полей, детали маршрута, несколько строк текста. Труднее сканировать в списке.
Фото направления + статус + даты + маршрут. Время до открытия нужной поездки сократилось, ошибочные открытия снизились.
Я был уверен, что расширенная карточка сэкономит клики — пользователь видит всё сразу и не открывает лишнего. Тест показал противоположное: в длинном списке плотные карточки сложнее сканировать. Пользователи ошибались с выбором поездки чаще, чем с минимальной версией. Это было моё неправильное решение — и тест это доказал.
Всегда видна, независимо от раздела. Завершение формы выросло на 41%. Это было неочевидное решение, бизнес изначально хотел спрятать её глубже.
Пользователи не находили. Расходы добавлялись значительно реже.
Категория, сумма, валюта, дата, проект, статья, комментарий, назначение. Среднее время заполнения: 2 мин 40 сек.
Дата, категория, сумма, валюта, комментарий. Время сократилось до 58 секунд. Доля прикреплённых чеков выросла.
Тест с формой расхода был самым сложным политически. Бизнес хотел 8 полей, чтобы получать максимум данных. Я показал в тесте: 73% пользователей бросали форму на 5-м поле. Сократили до 5 полей, а недостающие данные начали подтягивать автоматически из контекста поездки.
Аналитика, баланс лимитов, последние действия. Казалось, богатый стартовый экран даёт пользователю ценность с первого взгляда.
Пользователи открывают приложение с одной целью — найти нужную поездку. Время до первого действия сократилось вдвое. Дашборд оказался шумом.
Пользователь фотографирует чек, поля заполняются автоматически из OCR. Меньше ручного ввода — доля завершённых форм выросла на 34%.
Логичная последовательность: заполни поля, прикрепи фото в конце. Но чек уже убран в карман — пользователи бросали форму, не возвращаясь к фото.
| Токен | Пример | Размер / LH |
|---|---|---|
| display-2xl | Поездки | 72 / 90 · 600 |
| display-xl | Поездки | 60 / 72 · 600 |
| display-lg | Заголовок H1 | 48 / 60 · 600 |
| display-md | Заголовок H2 | 36 / 44 · 600 |
| display-sm | Заголовок H3 | 30 / 38 · 600 |
| display-xs | Подзаголовок | 24 / 32 · 600 |
| text-xl | Лид-абзац | 20 / 30 · 400 |
| text-lg | Основной текст | 18 / 28 · 400 |
| text-md | Краснодар → Москва | 16 / 24 · 400 |
| text-sm | Подпись | 14 / 20 · 400 |
| text-xs | 20 января 2022 | 12 / 18 · 400 |
| Токен | Пример | Размер / LH |
|---|---|---|
| display-2xl | Поездки | 48 / 60 · 600 |
| display-xl | Поездки | 40 / 50 · 600 |
| display-lg | Заголовок H1 | 36 / 44 · 600 |
| display-md | Заголовок H2 | 30 / 38 · 600 |
| display-sm | Заголовок H3 | 24 / 32 · 600 |
| display-xs | Подзаголовок | 22 / 30 · 600 |
| text-xl | Лид-абзац | 20 / 30 · 400 |
| text-lg | Основной текст | 18 / 28 · 400 |
| text-md | Краснодар → Москва | 16 / 24 · 400 |
| text-sm | Подпись | 14 / 20 · 400 |
| text-xs | 20 янв 2022 | 12 / 18 · 400 |
Токены устроены трёхуровнево, чтобы одно правило меняло и приложение, и веб: примитивы (сама палитра: brand.500, warning.400) → семантика (status.approved, status.pending) → компонент (badge.approved.bg, badge.approved.text). Экраны ссылаются только на семантический слой — если завтра бренд станет не оранжевым, правим один примитив, а все бейджи, кнопки и иконки обновляются автоматически.
Сырая палитра со степами 25–950. Не имеют смысла в UI, только определяют цвет: brand.500, gray.700.
Привязка цвета к роли в продукте: status.approved, status.rejected, text.primary, surface.default. Дизайнер выбирает смысл, а не hex.
Частные токены, собранные из семантики: badge.approved.bg, badge.approved.border. Разработчик подставляет их в код один раз.
Семантика в бейджах ниже подобрана по правилу «цвет = действие пользователя». Warning на «Согласовании» намеренно жёлтый, а не оранжевый, чтобы не конфликтовать с брендовым акцентом. Error (красный) используется только для деструктивных состояний — отклонено, ошибка загрузки. Brand в статусе «В пути» работает как фокус внимания: поездка прямо сейчас активна и к ней приковано зрение. Neutral — фоновые, архивные и пустые состояния, которые не должны отвлекать.
| Бейдж | Токен | Когда применяется |
|---|---|---|
| Черновик | neutral / 500 | Поездка создана, но ещё не отправлена на согласование. |
| На согласовании | warning / 400 | Ждёт действие руководителя — требует внимания, но это не ошибка. |
| Утверждено | success / 500 | Бюджет одобрен, можно бронировать билеты и отель. |
| Отклонено | error / 500 | Руководитель отказал — деструктивное состояние, блокирует поездку. |
| В пути | brand / 500 | Командировка активна прямо сейчас — бренд-цвет как фокус внимания. |
| Отчёт | info / 500 | Нужно загрузить чеки и закрыть авансовый отчёт. |
| Завершено | neutral / 700 | Поездка закрыта, документы проведены — архивный статус. |
Токен → компонент → паттерн. Карточка поездки собирается из атомарных элементов: бейдж статуса, иконка типа, типографика.
Все цветовые пары проверены на контраст. Кликабельные области, минимум 44×44 pt. Поддержка Dynamic Type на iOS.
Мобильное приложение и веб-платформа используют один набор токенов. Изменение в библиотеке отражается на обеих платформах.
Спецификации содержали описание поведений, граничных кейсов и токенов. Разработчики не приходили с вопросами.
Карточка, фото направления + цветной бейдж статуса + маршрут. Сканирование за секунду. Инсайт из A/B: минимум полей = меньше ошибок выбора.
Авиабилет, ж/д, аэроэкспресс, отель, трансфер, встреча, каждый тип в своей карточке. Тап открывает полный экран с QR. Код регистрации, 2 действия.
Кнопка в Tabbar с акцентным цветом. 5 полей + фото чека. Авансовый отчёт формируется автоматически по итогам поездки.
Специальный экран с очередью на согласование. Таймер автоотмены. Одно нажатие, командировка утверждена. Инсайт из JTBD Игоря: без погружения в детали.
Командировочные документы подписываются электронной подписью прямо в приложении. УКЭП без похода в офис.
Интеграция с OpenWeather. Небольшая карточка на экране деталей поездки. Появилась по запросу пользователей во время тестирования, сделали за спринт.
Приложение стало настоящим спутником в командировке. Всё в одном месте, работает даже в метро без связи. Отчёт теперь занимает 10 минут, а не полдня.
