Как работа по модели FBS стала главным сценарием приложения

Суть проекта

В 2021 году Яндекс Маркет запустил мобильное приложение для продавцов. В нём уже можно было начать продавать с телефона; затем появились каталог, DBS и сводка. Но приложение оставалось продуктом с базовыми сценариями и небольшой аудиторией. Главного рабочего процесса в нём не было: 71% продавцов работали по модели FBS, а обрабатывать такие заказы можно было только в веб-версии.

Мы сделали FBS центральным продуктовым запуском приложения. Я отвечал за направление и лично принимал ключевые решения: участвовал в постановке проблемы и исследованиях, задавал подход, проектировал ключевые сценарии и доводил продукт до запуска вместе с продуктовой командой. Это была самостоятельная продуктовая роль в проекте с высокой неопределённостью — решение нужно было собрать практически с нуля. Команда проверила прототипы в трёх сериях RITE-тестов, провела бета-тест с участием более 100 добровольцев на iOS и Android и открывала функцию поэтапно.

С августа 2022 по август 2023 доля продавцов, использующих приложение, выросла с 5% до 53%, DAU — с 2 000 до 20 000, а число обрабатываемых заказов — с 300 до 20 000 в день. FBS был ключевым фактором этой динамики, но не единственным изменением приложения за этот период.

Приложение должно было стать рабочим инструментом

Приложение для продавцов появилось в ноябре 2021 года. Сначала в нём были MVP и базовые сценарии, затем каталог, DBS, сводка и другие функции. Это доказывало, что продавец может решать часть задач с телефона, но ещё не делало приложение основным рабочим инструментом.

Перед запуском FBS приложением пользовались только 5% продавцов. При этом FBS — модель, в которой продавец хранит товары на своём складе, а Маркет доставляет заказы покупателям, — выбирали 71% продавцов. Самый массовый сегмент не мог выполнить в приложении свою главную ежедневную задачу.

Это и определило приоритет: не добавлять ещё одну небольшую возможность, а перенести в телефон полный цикл обработки FBS-заказа.

Моя роль

Я отвечал за направление и лично принимал ключевые решения: участвовал в постановке проблемы и исследованиях, задавал подход, проектировал ключевые сценарии и доводил продукт до запуска вместе с продуктовой командой. Это была самостоятельная продуктовая роль в проекте с высокой неопределённостью — решение нужно было собрать практически с нуля.

Цели вместо абстрактного «улучшить приложение»

1. Больше половины продавцов Маркета используют приложение.
2. Оценка удобства приложения растёт.
3. Растёт число ежедневных активных пользователей.

Сначала разобраться в работе продавца

Обработка заказа выглядит линейной только со стороны. На практике она зависит от статуса заказа, типа товара, маркировки, документов и способа сборки. Если просто уменьшить веб-интерфейс до размера телефона, продавец получит те же сложности на меньшем экране.

Исследование и поиск решения

Мы разложили рабочий процесс продавца на этапы, ограничения и разные сценарии. Это помогло увидеть разрывы не в отдельных экранах, а во всём пути — от мониторинга заказов до доставки.

Прототипирование и проверка

На основе исследования собрали прототипы и проверяли их вместе с продавцами. В Маркете дизайнеры участвуют в исследованиях напрямую — это сокращает расстояние между наблюдением и изменением решения.

Проверку провели в трёх сериях по методу RITE. После проблемного сценария команда не ждала окончания всего исследования, а сразу дорабатывала прототип и проверяла следующую версию на следующих участниках. Так решение становилось точнее прямо по ходу тестов.

Дизайн-критика

Регулярные дизайн-критики помогали находить слабые места до запуска. Мы разбирали сценарии вместе с командой, сравнивали варианты и уточняли, что должно быть заметно продавцу на каждом шаге.

Четыре сценария вместо одного идеального пути

В итоговом решении мы учли четыре разных сценария обработки заказа. Интерфейс подстраивался под текущий статус и показывал действия, которые нужны продавцу именно сейчас.

• Умный сканерНаходил заказ или товар по штрихкоду и помогал заполнить код «Честного знака».
• Контекстные действияНабор действий менялся вместе с текущим шагом сценария.
• Электронные актыМожно было подписать одним нажатием без обязательной печати.
• Чеклист сборкиЗаменял бумажные списки и оставался рядом с заказом в телефоне.

Мы не переносили веб-кабинет целиком. Телефон использовал свои преимущества: камера стала рабочим инструментом, документы и подсказки появились в контексте, а лишние действия исчезли из текущего шага.

Бета до полного запуска

Перед открытием функции для всей аудитории мы провели бета-тест с участием более 100 добровольцев на двух платформах. Это позволило проверить не только отдельные экраны, но и полный рабочий цикл в реальных заказах.

После беты функция выходила поэтапно. Такой запуск оставлял команде возможность наблюдать за поведением и качеством продукта, не перекладывая риск большого обновления сразу на всех продавцов.

Результат

С августа 2022 по август 2023 изменились ключевые показатели:

• 5% → 53%доля продавцов, использующих приложение
• 23% → 38%доля оценок удобства «отлично»
• 2 000 → 20 000DAU
• 300 → 20 000заказов в приложении в день

Запуск FBS напрямую повлиял на эту динамику: приложение получило главный рабочий сценарий самой большой группы продавцов. Одновременно продукт продолжал развивать и другие функции, поэтому было бы неверно приписывать весь годовой рост только одному релизу.