iTAB — сервис консультаций специалистов внутри магазина БАДов
iTAB — российский магазин товаров для здоровья: БАДы, скидки на анализы, экспертный контент. Для той же экосистемы я спроектировала мобильный сервис консультаций: у специалиста появляются кабинет, расписание и анкета, которая выводит его в каталог; клиент находит, записывается и платит, не выходя из магазина. Позже я перенесла ту же продуктовую модель в веб-сервис, который и запустился.
- Роли
- Специалист и клиент в одном аккаунте
- Объём
- 60+ экранов · пять сценариев
- Условие
- Правовой статус до публикации
Проблема
iTAB продавал БАДы, но те, кто их на самом деле рекомендует — нутрициологи, терапевты, врачи превентивной медицины — жили за пределами приложения. За советом клиент уходил в мессенджер или в клинику, а рекомендация возвращалась в лучшем случае скриншотом. Провести консультацию в магазине было негде, а специалисту незачем было приводить туда клиентов.
Задача
Спроектировать сервис консультаций внутри существующего приложения: как специалисту попасть в каталог и получать деньги, как клиенту найти, записаться и оплатить, и весь операционный слой между ними — расписание, подтверждения, отмены, чат. Всё это должно было работать как один аккаунт с двумя контекстами, а не как второе приложение.
Пользователи
Две роли с противоположными интересами. Специалисту нужны клиенты и как можно меньше бумажек — но платформа может ему заплатить, только когда сойдутся правовой статус и квалификация. Клиенту нужно доверить постороннему человеку вопрос о здоровье, поэтому регалии, цена и ближайший свободный слот должны идти впереди всего остального.
Что изменилось
Вместо отдельного приложения для врачей я сделала сервис вторым контекстом внутри того же аккаунта: кабинет появляется после анкеты, каталог наследует язык карточек магазина, а запись заканчивается в его же оформлении заказа.
Ограничения
Внутри iTAB у сервиса не было предшественника, поэтому я разложила оба ролевых пути и их ограничения: что по закону нужно платформе, прежде чем публиковать специалиста и платить ему; что нужно увидеть клиенту, прежде чем платить незнакомому человеку; и где два пути пересекаются — запись, подтверждение, отмена. Эти четыре ограничения и определили обе стороны сервиса.
Правовой барьер
Платформа может платить только оформленному специалисту, поэтому статус и документы идут раньше публикации
Два контекста, один аккаунт
Специалист — ещё и покупатель, поэтому кабинет должен стоять рядом с профилем магазина, а не вместо него
Доверие до оплаты
Регалии, формат и цена должны читаться прямо в списке, а не только в профиле
Расписание как оно есть
Специалисты отменяют, клиенты переносят, слоты сталкиваются — операционные состояния нужны с первого дня
1. Как специалист попадает в каталог
Точка входа — анкета. Она открывается причинами её заполнить: рекомендации клиентам, поток клиентов, выплата каждый месяц — и обещает пятнадцать минут. Форма нарезана на короткие шаги с прогресс-баром, а на любой попытке закрыть предлагает сохранить прогресс, а не потерять его.
Шаги повторяют то, что нужно платформе до публикации: личные данные, профессиональные данные с дипломами и членствами, формат консультаций, услуги с ценой за каждую и правовой барьер. Без оформленного статуса занятости платформа не может заплатить специалисту, поэтому анкета спрашивает о нём раньше, чем каталог его покажет. Результат уходит на модерацию и возвращается в течение рабочего дня.
2. Один аккаунт, два контекста
Специалист — ещё и покупатель магазина, поэтому кабинет стал вторым контекстом того же аккаунта, а не вторым логином. До анкеты в нём один призыв к действию и реферальный код; после модерации добавляются консультации, расписание и рекомендации, а одна кнопка возвращает в клиентский профиль с заказами и записями.
Профессиональный профиль сохраняет структуру анкеты — основная и профессиональная информация двумя вкладками, — так что ничего не вводится дважды и любое поле правится там же, где заполнялось.
3. Как клиент находит и записывается
На клиентской стороне сервис наследует язык магазина: лента специальностей, сортировка, быстрые фильтры «онлайн», «очно» и «рядом» и подробный фильтр по званию, категории, цене и опыту. Карточка специалиста выносит наверх регалии, типы пациентов и ближайшие свободные слоты и заканчивается одной ценой — ровно тем, что клиент проверяет, прежде чем доверить незнакомцу вопрос о здоровье.
Запись — это дата, время и формат, дальше оформление с комментарием для врача, офертой и правилом отмены, названным заранее. Оплата закрывается шторкой, которая ведёт прямо в консультации клиента, а главная магазина объявляет новый раздел рядом с товарами.
4. Как идут консультации
Для специалиста сервис — это расписание и список. Расписание начинается пустым и собирается в два движения: выбрать даты, открытые для записи, затем слоты на каждый день, с повтором для типовой недели. Список консультаций делит запланированные и проведённые; запланированную можно подтвердить, увести в чат или отменить с причиной, которую увидит клиент.
Чат живёт рядом с записью, поэтому перенос консультации — это разговор внутри приложения, а не звонок за его пределами.
5. Вспомогательный сценарий: партнёрская программа
Специалисты приводят клиентов в магазин личным промокодом: клиент получает скидку на каталог, специалист — кешбэк с каждого заказа и бонус, когда сумма за месяц переходит порог. Вступление — своя короткая анкета: город, откуда узнали о программе, личные данные и код, — с единственной по-настоящему важной ошибкой прямо в поле: такой код уже занят.
Код попадает в кабинет рядом с консультациями. Ради этой петли сервис и строился: совет на консультации, рекомендация с кодом, покупка в том же приложении.
6. Поздний аудит: состояния, которых не хватало
Поздний аудит для кейса показал: счастливый путь собран целиком, а восьми состояний отказа нет — тех самых, с которыми настоящий сервис сталкивается сразу. Я дорисовала все восемь в существующей системе компонентов и текстов. Три показанных здесь несут наибольший операционный риск: анкета вернулась на доработку, на выбранную дату нет свободного времени и занятый слот, который нельзя просто удалить.
7. Что запустилось в вебе
Мобильное направление осталось продуктовым концептом, но его логика легла в основу веб-сервиса, который запустился. Эту версию я тоже спроектировала, перенеся ту же двустороннюю модель в рабочее место специалиста и клиентскую запись.
Результат
Работа задала связный сервис консультаций внутри экосистемы iTAB. Специалист проходит путь от анкеты и модерации до управления доступностью и консультациями в одном аккаунте; клиент находит, сравнивает, записывается и платит, не выходя из магазина. Эта же модель легла в основу запущенного веб-сервиса.
Одна продуктовая модель на два пути: допуск, расписание, оплата и отмена живут по общим правилам и на стороне специалиста, и на стороне клиента.
Расширение магазина, а не второй продукт: сервис переиспользует существующий аккаунт, язык каталога и оформление заказа вместо ещё одного логина и оторванного опыта.
От концепта до релиза: основной путь я перенесла в запущенную веб-версию — от анкеты и расписания специалиста до записи и оплаты клиентом. Поздний аудит дополнил мобильную модель состояниями отказа и краевыми случаями, показанными в кейсе.