Диджитализируем ремонт
Сам по себе ремонт квартиры — трудоемкий процесс: надо найти подрядчиков, закупить материалы, быть на связи с бригадиром… Наш заказчик на своём опыте убедился, что делать это дистанционно — в разы сложнее. Он не единственный, кто сталкивается с такой проблемой: некоторые собственники квартир в Дубае живут в другой стране или постоянно заняты, а кто-то инвестирует в недвижимость и не может физически контролировать все объекты. Так родилась идея создать сервис для удаленного ремонта.
Цель Settler — помочь пользователям контролировать процесс ремонта квартиры в Дубае из любой точки мира. Всё, что им нужно сделать — заполнить заявку, рассказать о своих пожеланиях, указать бюджет и передать ключи. Остальным займется команда Settler.
Мы в Purrweb уже делали сервисы, связанные с недвижимостью: Pad для поиска соседей и Post-a-Room для сбора информации про рынок недвижимости Лондона, поэтому понимали специфику этой ниши и знали, что нас ждёт.
Нам предстояло оцифровать весь процесс ремонта и собрать его под крышей одного сервиса
Вдумчивое планирование
Перед нами стояла большая задача — сделать:
- пользовательское приложение под Android и iOS
- приложение для дизайнера интерьеров,
- административную панель для веба
- лендинг для приёма заявок
К тому же у нас был строгий дедлайн — клиент пришёл к нам в сентябре и хотел, чтобы к новогодним праздникам приложение появилось в сторах. Он планировал в это время показать сервис своим знакомым и в спокойной обстановке начать искать инвесторов. Важно было учитывать, что сторы могут рассматривать приложение до двух недель — нужно было закончить с запасом времени.
Чтобы всё успеть, мы решили делать версионный проект. Для этого мы разделили все функции по приоритетам и запланировали 5 версий приложения.
Версионный подход в действии
Сначала мы максимально сжали список функций и сделали MVP, благодаря чему смогли вовремя опубликовать его в сторах. Затем мы стали работать над обновлениями приложения, постепенно расширяя возможности сервиса.
При версионном подходе каждая следующая версия приложения — усовершенствованная версия предыдущей, с новыми функциями и дополнениями
Из-за версионного подхода изменился и процесс разработки. После каждого спринта, они обычно у нас длятся две недели, был релиз — мы выгружали обновления в сторы. Так продукт постепенно рос на глазах.
Благодаря версионности у клиента была возможность регулярно актуализировать приоритетность функций: он мог повлиять, какая появится в приложении следующей.
Минимум визуального шума, максимум уюта
Из брифа мы узнали, каким клиент видит дизайн сервиса. Заказчик прислал референсы, некоторые из которых были из проектов нашей студии, так что мы быстро нашли общий язык.
Решили сделать минималистичный UI, чтобы дизайн не отвлекал пользователя от самого важного — процесса ремонта. Заказчик хотел, чтобы приложение ассоциировалось с теплом и уютом будущего дома, поэтому в качестве акцентного выбрали цвет испанских апельсинов. Да-да, он так и называется — Spanish Orange.
Минималистичный дизайн снимает нагрузку с пользователя и помогает сосредоточиться на главном
Для Settler мы выбрали Lexend Deca, округлый шрифт без засечек, который смотрится дружелюбно и ненавязчиво. Он читабельный и хорошо подходит для интерфейсов мобильных приложений. А ещё — бесплатный, так что мы смогли немного сэкономить для заказчика. Мелочь, а приятно.
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$.
В Settler нужно загрузить чек после оплаты через банковское приложение
📅 Календарь. Для планирования созвонов пользователю нужен календарь. Сначала мы хотели интегрировать его в приложение, но потом решили реализовать через стороннее приложение — Calendly. На это нам понадобилось 300$, так что мы сэкономили клиенту 2700$.
Переход клиента на инхаус-команду
Работа над проектом планировалась почти на год, но спустя несколько месяцев заказчик задумался о переходе на инхаус-команду. Ему нравилась наша скорость и качество работы, но хотелось сэкономить, потому что у него пока не было инвесторов и проект делался только за его деньги.
Изначально над проектом работала большая команда, 10+ человек, чтобы успеть в сжатые сроки. Мы предложили клиенту её уменьшить — да, скорость разработки снизилась, но так мы сэкономили порядка 30% ежемесячного бюджета.
Заказчик продолжил сомневаться, поэтому мы провели ещё несколько встреч.
Во-первых, обсудили преимущества работы с нашей студией. К примеру, мы берём на себя риски: если кто-то заболел, всегда находим сотрудника, который подхватит проект. А ещё у нас прозрачные процессы и мы всегда соблюдаем дедлайны.
Во-вторых, мы предложили другой способ оптимизировать расходы — оставить за нами работу над приложением, а инхаус-команду поставить на разработку админской панели.
Однако заказчику важно было кардинально ужать бюджет. И он был готов потратить время и силы на подбор и координацию фрилансеров, чтобы сэкономить. К тому же у него было понимание, как будет работать продукт и что нужно делать для его развития — к этому моменту мы уже заложили фундамент проекта и распланировали его разработку. Поэтому клиент решил полностью перейти на инхаус-команду.
Готовим проект к передаче
Мы постарались сделать переход проекта к команде клиента максимально бесшовным. Для этого:
1️⃣ Актуализировали документацию, подготовили документ со всеми доступами к сервисам и собрали неприоритетные баги в отдельный файл.
Например, вот так выглядит часть ER-диаграммы базы данных, на которой показано, как взаимосвязаны основные объекты и как между ними перемещаются данные. Благодаря ей разработчикам в инхаус-команде будет легче разобраться в структуре проекта
2️⃣ Обновили UI kit, привязали все стили, варианты и состояния. Собрали файл в Figma со всеми экранами и сделали в нём удобную навигацию по сценариям и ролям.
В UI kit хранятся основные компоненты дизайна — это облегчает создание новых страниц дизайнерам и экономит время разработчикам
3️⃣ Собрали файл со всеми планами и идеями, которые обсуждали с клиентом. Со стороны клиента был продукт-менеджер — сделали для него документ, в котором описали все сущности в панели администратора, роли и основные флоу. Дали советы по подбору команды.
4️⃣ Провели созвоны по процессам внутри проекта и сделали онбординг: рассказали новым сотрудникам о процессах внутри проекта, как все устроено в коде и какие инструменты использовали. Затем ответили на вопросы и передали код.
5️⃣ Сделали общий чат с разработчиками, чтобы помогать в случае трудностей.
Мы остались на связи с инхаус-командой и отвечаем на возникающие вопросы
Во многом процесс был похож на то, как мы обычно передаем законченный проект клиенту.
В итоге
Мы в Purrweb сделали первую версию сервиса: приложение для пользователя, панель для администратора и лендинг, заложили фундамент для его дальнейшего развития и до сих пор поддерживаем связь с командой, которая теперь работает над Settler.
А вы как думаете, что лучше для стартапа: работать со студией или собрать инхаус-команду?
