Проект — white-label платформа бронирования для SPA, бассейнов, массажных и wellness-центров. Я проектировал клиентскую часть: веб и мобильное приложение, через которые пользователь выбирает услугу, мастера, время и оформляет запись или покупает билет
В системе выделены три ключевые роли, каждая из которых взаимодействует с продуктом на разных уровнях: конечный клиент проходит путь от выбора услуги до оплаты, бизнес-клиент адаптирует решение под свой бренд, а администратор управляет контентом и настройками.
Основной пользователь клиентской части. Его задача — быстро выбрать услугу или билет, понять условия, выбрать удобное время и завершить оформление без обращения к администратору.
Для него важны:
Понятный выбор филиала → прозрачная стоимость → доступные даты и слоты → быстрый сценарий оплаты → сохранение записи или билета в личном кабинете
Компания, которая покупает коробочное решение и настраивает его под себя. Для неё важно, чтобы интерфейс можно было быстро адаптировать под бренд.
Ключевые задачи:
Замена цветов, логотипов и изображений → настройка текстов, услуг и филиалов → адаптация правил бронирования под бизнес-процессы
Настраивает услуги, расписания, ресурсы, бассейны, абонементы и условия бронирования. Его работа происходит в административной части, но напрямую влияет на то, что видит клиент в web и mobile.
Ключевые задачи:
Настройка услуг и расписаний → управление ресурсами и бассейнами → настройка абонементов и условий бронирования
Бизнес-клиент
бренд, цвета, логотип, контент, правила
Администратор системы
услуги, расписания, ресурсы, бассейны, абонементы
White-label система
Web + Mobile
Клиент wellness-сервиса
услуга / бассейн / абонемент
Запись / билет / заказ
оплата, QR-билет, личный кабинет
Wellness Booking охватывает несколько ключевых клиентских сценариев: от записи на SPA до покупки абонемента. Каждый сценарий проектировался с учётом специфики услуги и ожиданий пользователя.
Сценарии
Шесть пользовательских сценариев — от онлайн-записи до white-label настройки. Каждый решает конкретную задачу клиента или бизнеса
01
Клиент выбирает услугу, мастера и удобный слот. На web сценарий сопровождается резюме заказа справа, а в mobile разбивается на последовательные шаги.
02
Выбор бассейна, фиксированного сеанса и типа билета с учётом доступного количества мест.
03
Покупка пакета визитов с выбором типа, срока и условий использования.
04
Просмотр активных записей, история, отмена, перенос и возврат средств.
Обзор
Запись на услугу и покупка билета в бассейн выглядят похожими: пользователь выбирает дату, время и оплачивает заказ. Но внутри это разные модели.
В записи важны услуга, мастер, длительность и свободный слот. В бассейне — локация, сеанс, тип билета, количество и QR-код после оплаты.
Поэтому сценарии были разделены на два самостоятельных потока. Это позволило не перегружать интерфейс лишними шагами и показывать пользователю только те параметры, которые важны для конкретной покупки.
01
Ключевые сущности:
02
Ключевые сущности:
Общий принцип один: выбрать → подтвердить → оплатить.
Но параметры выбора разные, поэтому сценарии разделили.
Обзор
На десктопе сценарий записи шёл пошагово: выбор услуги → мастер → время → подтверждение. Чтобы пользователь не терял контекст, мы вынесли резюме заказа в фиксированную правую колонку. Она обновлялась на каждом шаге и показывала, что уже выбрано
Обзор
Тот же сценарий записи нужно было уложить в мобильный формат. Правая колонка стала сворачиваемой панелью внизу экрана. Шаги остались те же, но навигация стала вертикальной с промежуточными экранами подтверждения.
Обзор
Бассейны работали по другой логике: фиксированные сеансы, ограниченное количество мест, фильтрация по дате и времени. Мы спроектировали отдельный интерфейс с сеткой доступных сеансов вместо выбора мастера и слота.
Обзор
Платформа работала как white-label: каждый клиент получал собственный брендированный интерфейс. Мы заложили систему тем, переменных и модульную структуру, чтобы один и тот же интерфейс мог выглядеть по-разному без изменения кода.
White-label логика в структуре интерфейса
Принцип коробочного интерфейса
Клиентский интерфейс
Брендовый слой
Контент и настройки
Обзор
ЛК объединял все типы активностей: записи на услуги, купленные билеты, абонементы и историю возвратов. Мы сгруппировали их по статусу (активные / прошедшие / отменённые) и добавили быстрые действия: перенос, отмена, повторная запись
Проект развивался итерациями в условиях MVP. Клиентская часть зависела от бэкенда, который изначально проектировался под админ-панель, а не под пользовательский интерфейс. Это накладывало ограничения на гибкость сценариев и потребовало компромиссов.
Коротко в тезисах:
На клиентской стороне не проводилась полноценная регулярная аналитика, но ключевые сценарии тестировались с помощью юзабилити-тестирования и коридорных тестов с членами команды. К сожалению, проверки гипотез не состоялось, так как я покинул проект на этапе его разработки
В результате была спроектирована клиентская часть системы бронирования для двух платформ: web и mobile.
Система закрывала основные сценарии wellness-бизнеса: запись на услуги, покупку билетов в бассейн, оформление абонементов, оплату, личный кабинет, заказы и возвраты.
Главная ценность решения — в коробочной модели. Один и тот же сценарный фундамент можно было использовать для разных клиентов, меняя бренд, цвета и контент, но сохраняя готовую механику бронирования.
Платформа для наставников с треками, заданиями и контролем прогресса.
