Проект BuduAr появился от идеи о быстром создании 3D-модели с фото через приложение. Это не было бизнесом или даже стартапом, это была просто идея, потом прототип на коленке, и потом постепенное создание небольшого онлайн сервиса.

Далее появился ресурс в виде разработчиков и несколько людей решили попробовать что-то сделать с этой идеей. Наняли продукт менеджера, дизайнера ( меня ) что бы попробовать собрать проект

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

Начали с процессов:

Обсудили что сейчас нам нужно работать недельными спринтами
( для интенсивности и ритма )

Составили бэклог задач
( мы выписали вобще все что было в поле зрения на тот момент )

Приоретизировали задачи
( Разложили кипу задач по приоритетам и времени, накинули примерные сроки )

Оценили по времени
( Поставили примерные рамки когда будут готовы те или иные итерации )

Определили сроки первых версий
( С учетом багов, и вылетов но все же первых примерных версий )

Обсудили как будем тестировать и что хотим понимать
( Мы брали в рассчет опросы, и юзабилити тесты . Это то на что был ресурс )

Определили, что для нас точка А и как в нашем понимании выглядит точка Б, С...
и когда мы к ним придем.
( По сути главной задачей было mvp, а дальше уже развитие )

Финансовые показатели и маркетинг оставили на период первых версий

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

Мы берем вещь (футболку, штаны, платье), мы берем некое приложение, фоткаем вещь, грузим в приложение, приложение делает нам из этой футболки полноценную 3D-модель.

Кому нужна данная технология или кто наша целевая аудитория?
1) Швейная отрасль
2) Fashion дизайнеры и магазины одежды
3) Организации, шьющие спортивную одежду
4) Дома моды отечсетвенного и зарубежного формата
5) Коллежди и институты обучающие студентов по пошиву и дизайну одежды

Пример использования
Клиент приносит материал в ателье → сообщает, что хочет из него юбку или брюки → администратор фотографирует материал → в приложении выберет дефолтную юбку
или по параметрам выберет из каталога нужную модель.

Затем накидывает материал на изделие и в режиме реального времени показывает готовую 3D-модель, как будет выглядеть вещь, клиент быстро дает правки → и после этого материал отправляется на пошив

Продукты
Первое - это мобильное приложение
Второе - это веб сайт

1. Вход в приложение
Под MVP мы заложили только авторизацию через смс-код.

2. Главный экран
4 недели ушло на финальную версию главного экрана, в это вошли обсуждения функуионала, юзабилити тесты, создание 3 моделей, онбординг, адаптивы, тесты на баги, онбординг. В итоге финальная версия была готова

Ретро:
Сделали юзабилити тест на нескольких респондентах и выяснили, что все же покадить корзину переходом на другое окно не очень удобно.

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

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

К слову, когда мы прорабатывали флоу, мы обсудили, что было бы вообще неплохо иметь возможность уведомлять пользователя в момент смены локации (выбора адреса доставки),
что на данном адресе доставки в качестве оплаты допуcтимы такие-то валюты. Но пока это задачка для бэклога.

Ретро
Этот концепт отработал лучше, но с ним появились другие проблемы. Незнакомый пользователю паттерн — выбор валюты через радиокнопки. Пользователь не додумывался после клика на радиокнопку прожать кнопку оплаты. Обычно есть что-то вроде кнопки «Применить», а у нас было «Оплатить». Это сбивало с толку.

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

Да, конечно, тут есть одно маленькое неудобство с тем, что все же данные карты придется вести заново, так как платежные системы не связанны между собой и, разумеется, данные
не передаются

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

Спустя тестовую неделю после запуска мы получили первые позитивные новости:
1) Количеству ошибок в платежных системах стало меньше на 30%.
2) Платежные системы отобразили данные, что число успешных покупок с зарубежных карт увеличилась на 15%. И это только первая неделя.
3) Мы не раскатывали апдейт на остальные локации — у сервиса их 13, и везде была одинаковая проблема. То полагаем, что данный метод показал свою эффективность, и мы ушли внедрять его на остальные.
4) Косвенно мы подняли лояльность клиентского сервиса и дале траеткорию для развития улущения очень крупного направления

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

Экосистема BuduAR

Экосистема для работы с 3D-контентом, созданная для B2B-сегмента
и специально адаптированная для fashion-индустрии