Flawery: нашли решение, которое позволило сократить стоимость разработки на 30%

Главное о кейсе

Наш клиент — цветочный маркетплейс Flawery. Пару лет назад он запустил мобильные приложения под iOS и Android. Они давно не обновлялись, работали с ошибками, а большая часть функционала, реализованного в веб-версии, в них и вовсе отсутствовала. Перед нами стояла задача разработать новые приложения под обе платформы.
При этом у клиента была определённая сумма, выделенная на проект. И разработка двух нативных приложений для iOS и Android выходила за её пределы. Мы нашли решение, которое позволило уменьшить смету на 30% без урезания функционала. Уложились в сроки и вместе с командой Flawery запустили цветочный маркетплейс.

Как проект изменил жизнь пользователей

Мы начали с исследования и выяснили, что люди покупают цветы очень по-разному. Кто-то подходит к выбору более педантично и выставляет все фильтры: цену, цвет, размер и др. Кто-то смотрит варианты из ближайших магазинов для самовывоза. А кто-то оформляет доставку, и здесь тоже разные сценарии — заказать на свой адрес, чтобы затем подарить лично, или отправить курьера с цветами конечному получателю.
Далее в ходе анализа конкурентов поняли, что частая проблема сервисов доставки — перегруженная главная страница. На ней пытаются отразить все возможности, которые есть в приложении. Но пользователь, видя это многообразие, быстро утомляется и уходит.
Мы постарались избежать избыточности фичей и сделать так, чтобы человеку приходилось совершить как можно меньше действий и быстрее получить желаемый результат. В итоге главный экран приложения превратился в разводящую страницу. С неё, как с «железнодорожного вокзала», человек может сразу уехать в нужном направлении.
В рамках нашей концепции каждый экран отвечает за определённый сценарий. И, даже используя приложение первый раз, человек не теряется и быстро понимает, что делать.

Бизнес-задача и ее решение

Задача звучала примерно так: «У вас нет никаких ограничений. Давайте с нуля придумаем идеальный сервис по доставке цветов».

НАЧАЛИ С АНАЛИТИЧЕСКОЙ РАБОТЫ
Доставка цветов — довольно нишевый рынок. Чтобы разобраться во всех нюансах, мы начали с исследования. Составили список вопросов, отобрали респондентов и провели анкетирование. В совокупности опросили более ста человек из разных регионов России, проанализировали их ответы и начали формировать первые гипотезы. А дополнительно провели ещё несколько глубинных интервью.
На их основе подготовили подробные CJM, составили список фичей, а затем рассортировали их на три группы: must have, nice to have и backlog.

РАЗУМЕЕТСЯ, НЕ ОБОШЛОСЬ БЕЗ АНАЛИЗА КОНКУРЕНТОВ
Мы старались смотреть шире просто цветочных приложений и заимствовать лучшие практики из разных сервисов. Изучили, изучили, как работают сервисы доставки и в России, и в мире. Смотрели и на гигантов рынка, и на довольно нишевые решения. В совокупности это помогло глубже погрузиться в сферу и понять, что и как мы будем делать в своём продукте.

ПРОРАБОТАЛИ КЛЮЧЕВЫЕ СЦЕНАРИИ
Главный экран — железнодорожный вокзал, а пользователь сам выбирает, куда отправиться. Если хочет посмотреть весь ассортимент всех магазинов, он нажимает кнопку «Все цветы», попадает в общий каталог и ищет нужный букет.
Если хочет оформить самовывоз, нажимает кнопку «Букеты рядом» и смотрит, какие цветочные композиции есть в ближайших к нему салонах.
Если хочет заказать цветы, но не знает какие, нажимает кнопку «Подбор букета». Затем отвечает на несколько вопросов, и приложение составляет для него подборку из четырёх букетов. Пользователь может выбрать один из предложенных вариантов либо обновить подборку.

НАШЛИ РЕШЕНИЕ, КОТОРОЕ ПОМОГЛО УМЕНЬШИТЬ СМЕТУ НА РАЗРАБОТКУ
У клиента была определённая сумма, выделенная на проект. И разработка двух нативных приложений для iOS и Android выходила за её пределы. Предстояло найти решение, которое бы позволило уменьшить смету и уложиться в бюджет.
Самым простым вариантом было бы отказаться от части фичей, но это не устраивало заказчика. Тогда мы предложили внедрить Kotlin Multiplatform Mobile — технологию, которая позволяет использовать единую базу кода для бизнес‑логики приложений.

ПРОВЕЛИ ТЕСТИРОВАНИЕ НА РЕАЛЬНЫХ ДАННЫХ
На настройку тестового окружения пришлось бы потратить много времени и ресурсов, Поэтому мы выбрали стратегию тестирования на реальных данных. Работали с настоящими магазинами и букетами. Но, конечно, для проверки фичей, связанных с покупкой и оплатой, создали демо-город. А для более полной картины качества проекта использовали Charles. Это инструмент для сниффинга трафика, который позволяет смотреть, уходят ли запросы с мобильного клиента, с какими параметрами они отправляются и как отвечает backend. А что самое главное — редактировать ответы backend.

ПРОДОЛЖАЕМ ДЕРЖАТЬ РУКУ НА ПУЛЬСЕ
После релиза работа над приложением не заканчивается. Важно найти способ держать руку на пульсе и отслеживать, что происходит у пользователей.
Мы хорошо подготовились и настроили систему уведомлений об ошибках. Она помогает отслеживать любое неожиданное для нас поведение приложения, оперативно предпринимать меры и выпускать обновления. Скажем, если вдруг перестанет работать эквайринг, мы тут же об этом узнаем. И информации будет достаточно, чтобы понять, в чём проблема и как всё исправить.

ИТОГ
Нам удалось реализовать весь функционал, заложенный на этапе проектирования. Приложение Flawery добавлено в App Store и Google Play — пользователи активно заказывают цветы и радуют близких с его помощью.

Крафт (мастерство), реализация, технические детали

Flawery — проект, на котором мы внедрили Kotlin Multiplatform Mobile. Это технология позволяет использовать единую базу кода для бизнес‑логики приложений и тем самым уменьшает стоимость разработки.
KMM работает примерно так: Android‑команда пишет стандартное мобильное приложение, но при этом учитывает логику iOS‑приложения. iOS‑команде остаётся сверстать экраны и подключиться к логике Android. Мы не тратим время на разработку отдельной логики для iOS, но всё равно получаем приложение с нативным поведением.
Для наглядности: первую версию iOS-приложения мы сделали за 2,5 месяца, в то время как на Android‑разработку потребовалось 5. Мы сократили часы работы iOS‑команды, за счет чего и произошло уменьшение сметы на 30%.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Наш клиент давно в цветочном бизнесе, у него большая экспертиза и насмотренность. И ему было важно найти не просто подрядчика, а настоящего партнёра, который будет готов разобраться в специфике ниши и дополнить его знания свежими идеями и инсайтами. Поэтому на этапе проектирования над приложением параллельно работали две команды: мы и ещё одна студия. Клиент осознанно решил удвоить затраты, чтобы посмотреть, кто и как мыслит, понять, чей подход ему ближе.
В конце 2022 года мы представили дизайн-концепцию и проектирование. Такие же артефакты клиент получил от другой студии и ушёл думать. А в январе 2023 вернулся с обратной связью и сообщил, что ему понравилось работать с нашей командой. После мы вместе приступили к разработке приложения.

Скриншоты