Сделали MVP приложения и сэкономили клиенту больше 12 000$ на технологиях, но клиент все-таки ушёл. Кейс Settler

К нам в Purrweb после статьи про арабский дизайн пришёл заказчик, который нащупал новую нишу на рынке в Эмиратах — он решил сделать с нами приложение для дистанционного ремонта. В кейсе расскажем, как мы упростили дистанционный ремонт с помощью UX-дизайна, сэкономили больше 12 000$ на технологиях и почему клиент в итоге собрал свою команду.

Сам по себе ремонт квартиры — трудоемкий процесс: надо найти подрядчиков, закупить материалы, быть на связи с бригадиром… Наш заказчик на своём опыте убедился, что делать это дистанционно — в разы сложнее. Он не единственный, кто сталкивается с такой проблемой: некоторые собственники квартир в Дубае живут в другой стране или постоянно заняты, а кто-то инвестирует в недвижимость и не может физически контролировать все объекты. Так родилась идея создать сервис для удаленного ремонта.

Цель Settler — помочь пользователям контролировать процесс ремонта квартиры в Дубае из любой точки мира. Всё, что им нужно сделать — заполнить заявку, рассказать о своих пожеланиях, указать бюджет и передать ключи. Остальным займется команда Settler.

Мы в Purrweb уже делали сервисы, связанные с недвижимостью: Pad для поиска соседей и Post-a-Room для сбора информации про рынок недвижимости Лондона, поэтому понимали специфику этой ниши и знали, что нас ждёт.

Перед нами стояла большая задача — сделать:

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

Чтобы всё успеть, мы решили делать версионный проект. Для этого мы разделили все функции по приоритетам и запланировали 5 версий приложения.

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

Из-за версионного подхода изменился и процесс разработки. После каждого спринта, они обычно у нас длятся две недели, был релиз — мы выгружали обновления в сторы. Так продукт постепенно рос на глазах.

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

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

Решили сделать минималистичный UI, чтобы дизайн не отвлекал пользователя от самого важного — процесса ремонта. Заказчик хотел, чтобы приложение ассоциировалось с теплом и уютом будущего дома, поэтому в качестве акцентного выбрали цвет испанских апельсинов. Да-да, он так и называется — Spanish Orange.

Для Settler мы выбрали Lexend Deca, округлый шрифт без засечек, который смотрится дружелюбно и ненавязчиво. Он читабельный и хорошо подходит для интерфейсов мобильных приложений. А ещё — бесплатный, так что мы смогли немного сэкономить для заказчика. Мелочь, а приятно.

Чтобы спроектировать приложение, мы выделили основные этапы ремонта и постарались упростить пользовательский опыт с помощью UX-дизайна.

Замеры — важная часть подготовительного этапа ремонта. Если на нём что-то пойдёт не так, может не хватить материалов, например, плитки или обоев.

Чтобы снять с пользователя переживания о правильности замеров, наш заказчик решил, что снимать их будет специально обученный человек, а вся информация по планировке — храниться в приложении. Кроме того, сами замеры будут делаться в 3D с помощью стороннего приложения и ссылкой подгружаться в Settler через админку.

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

По задумке заказчика через Settler собственник будет взаимодействовать со всеми подрядчиками, в том числе и с дизайнером интерьера.

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

В итоге пользователь получит дизайн-проект в приложении и сможет при необходимости обсудить его с дизайнером в чате.

Цель Settler — дать пользователям возможность следить за процессом ремонта, где бы они ни находились. Поэтому мы сфокусировались на блоке «Этапы» — именно в нём отображаются основные стадии ремонта: что уже готово, что в процессе и что предстоит сделать.

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

Ремонт — это расходы. Заказчику было важно, чтобы пользователь мог держать их под контролем через Settler. Поэтому мы добавили возможность:

При разработке использовали привычный для нас стек: бэкенд на NodeJS + Nest, мобильное приложение на React Native, панель администратора на React.

Мы решили сделать одно приложение для Android и iOS на React Native — кросс-платформенный подход позволил сэкономить до 30% в сравнении с нативной разработкой. Если хотите больше узнать о плюсах и минусах этих двух подходов в разработке, можете прочитать нашу статью.

Для админки решили не использовать фреймворк React Admin — вместо этого сделали кастомную панель, чтобы заложить возможность её масштабировать.

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

📺 Стримы. Клиент предложил сделать стримы, чтобы пользователь мог наблюдать за процессом ремонта. Мы начали искать подходящий инструмент. Сначала была идея сделать интеграцию с веб-камерами, а потом нашли более простой и дешевый выход — переход на трансляции по ссылке. Ссылку на стрим добавляет администратор, пользователь же может перейти по ней и посмотреть трансляцию на стороннем сервисе. Реализовать это решение стоило в 6 раз дешевле — 500$ вместо 3000$.

💸 Оплаты. Чтобы сэкономить на платежах и ускорить разработку, мы придумали следующий способ оплаты: пользователю приходят реквизиты, по которым нужно перевести оплату в банковском приложении, сделать скриншот чека и прикрепить его в Settler. Это решение стоило в 7 раз дешевле — мы сэкономили клиенту 7250$.

📅 Календарь. Для планирования созвонов пользователю нужен календарь. Сначала мы хотели интегрировать его в приложение, но потом решили реализовать через стороннее приложение — Calendly. На это нам понадобилось 300$, так что мы сэкономили клиенту 2700$.

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

Изначально над проектом работала большая команда, 10+ человек, чтобы успеть в сжатые сроки. Мы предложили клиенту её уменьшить — да, скорость разработки снизилась, но так мы сэкономили порядка 30% ежемесячного бюджета.

Заказчик продолжил сомневаться, поэтому мы провели ещё несколько встреч.

Во-первых, обсудили преимущества работы с нашей студией. К примеру, мы берём на себя риски: если кто-то заболел, всегда находим сотрудника, который подхватит проект. А ещё у нас прозрачные процессы и мы всегда соблюдаем дедлайны.

Во-вторых, мы предложили другой способ оптимизировать расходы — оставить за нами работу над приложением, а инхаус-команду поставить на разработку админской панели.

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

Мы постарались сделать переход проекта к команде клиента максимально бесшовным. Для этого:

1. Актуализировали документацию, подготовили документ со всеми доступами к сервисам и собрали неприоритетные баги в отдельный файл.

2. Обновили UI kit, привязали все стили, варианты и состояния. Собрали файл в Figma со всеми экранами и сделали в нём удобную навигацию по сценариям и ролям.

3. Собрали файл со всеми планами и идеями, которые обсуждали с клиентом. Со стороны клиента был продукт-менеджер — сделали для него документ, в котором описали все сущности в панели администратора, роли и основные флоу. Дали советы по подбору команды.

4. Провели созвоны по процессам внутри проекта и сделали онбординг: рассказали новым сотрудникам о процессах внутри проекта, как все устроено в коде и какие инструменты использовали. Затем ответили на вопросы и передали код.

5. Сделали общий чат с разработчиками, чтобы помогать в случае трудностей.

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

Мы в Purrweb сделали первую версию сервиса: приложение для пользователя, панель для администратора и лендинг, заложили фундамент для его дальнейшего развития и до сих пор поддерживаем связь с командой, которая теперь работает над Settler.

А вы как думаете, что лучше для стартапа: работать со студией или собрать инхаус-команду?

Больше кейсов о дизайне и разработке в нашем блоге:

→Как мы сделали интерфейс «арабским» за один клик и спасли пользователей от бесконечной регистрации: кейс криптобиржи

→Как мы создали омниканальный чат для закупщиков и защитили дизайн перед требовательным заказчиком. Кейс Grecha.pro

→Как разработать сервис онлайн-психотерапии в Англии и не поехать кукухой