iTAB — adding a specialist consultation service to a supplements store

iTAB is a health and wellness store on the Russian market: supplements, lab discounts, expert content. I designed a mobile consultation service for the same ecosystem — specialists get a cabinet, a schedule and a questionnaire that puts them in a catalogue; clients find, book and pay without leaving the store. The mobile direction remained a product concept, but its logic became the web service that shipped, and I designed that version too. The web screens sit next to the mobile ones below.

Roles: Specialist + client, one account
Scope: 60+ screens · five flows
Gate: Legal status before listing

Team: PM, iOS and Android developers, backend
My Role: Product designer. Owned the end-to-end specialist and client flows, from onboarding and scheduling to booking and payment.
Status: Mobile concept + shipped web service

Problem

iTAB sold supplements, but the people who actually recommend supplements — nutritionists, therapists, preventive-medicine doctors — lived outside the app. A client who wanted advice left for a messenger or a clinic, and the recommendation came back as a screenshot at best. The store had no way to host a consultation, and a specialist had no reason to bring clients into it.

Task

Design a consultation service inside the existing app: a way for specialists to get listed and paid, a way for clients to find, book and pay for a consultation, and the operational layer in between — schedules, confirmations, cancellations, chat. It had to work as one account with two contexts, not a second app.

Users

Two roles with opposite needs. A specialist wants clients and as little paperwork as possible, but the platform can only pay them once their legal status and qualifications check out. A client wants to trust a stranger with a health question, so credentials, price and the next free slot have to come before anything else.

What changed

Instead of designing a separate app for doctors, I framed the service as a second context inside the client’s own account: a cabinet that appears after a questionnaire, a catalogue that inherits the store’s card language, and a booking flow that ends in the store’s own checkout.

Design constraints

The service had no predecessor inside iTAB, so I mapped the two role journeys and the constraints around them: what the platform legally needs before it can list and pay a specialist, what a client needs to see before paying a stranger, and where the two journeys meet — booking, confirmation and cancellation. Those four constraints shaped both sides of the service.

Legal gate

The platform can only pay a registered specialist, so status and documents come before the listing

Two contexts, one account

A specialist is also a customer, so the cabinet has to live next to the store profile, not replace it

Trust before payment

Credentials, format and price have to be readable in the list, not only on the profile

Schedule reality

Specialists cancel, clients move bookings, slots collide — the operational states have to exist from day one

1. Getting a specialist into the catalogue

The entry point is the questionnaire. It opens with the reasons to fill it in — recommendations for clients, a flow of clients, a payout every month — and promises fifteen minutes. The form is cut into short steps with a progress bar, and closing it at any point offers to keep the progress rather than lose it.

The steps follow what the platform needs before it can list anyone: personal data, professional data with diplomas and memberships, the consultation format, services with a price for each, and the legal gate. Without a registered employment status the platform cannot pay a specialist, so the questionnaire asks for it before the catalogue ever shows them. The result goes to moderation and comes back within a working day.

Questionnaire start screen — why fill it in: recommendations for clients, a client flow, monthly payouts — Value first, professional proof next, legal eligibility last: the form earns the effort before it asks for the gate that determines whether a specialist can be listed and paid.

Questionnaire step two — professional information with specialty, courses, memberships and diplomas — Value first, professional proof next, legal eligibility last: the form earns the effort before it asks for the gate that determines whether a specialist can be listed and paid.

Web specialist questionnaire — a five-step form with the progress on the left, the professional information step with specialty, experience, education, patient types and document upload, and the reasons to join on the right — Shipped on the web: the same questionnaire as a five-step form. Professional data with documents comes second, and the legal gate stays last, with the reason it exists stated on the step itself.

Web specialist questionnaire — the employment status step: self-employed, sole proprietor or LLC, the tax ID and payout card fields, and the note that a registered status is required to be listed and paid — Shipped on the web: the same questionnaire as a five-step form. Professional data with documents comes second, and the legal gate stays last, with the reason it exists stated on the step itself.

2. One account, two contexts

A specialist is also a customer of the store, so the cabinet is a second context of the same account, not a second login. Before the questionnaire it holds one call to action and the referral code; after moderation it gains consultations, the schedule and recommendations, and a single button switches back to the client profile with its orders and appointments.

The professional profile keeps the structure of the questionnaire — main and professional information as two tabs — so nothing is typed twice and every field can be edited where it was entered.

Specialist cabinet before the questionnaire — a single call to action and the referral code — The account keeps one identity and changes context: the specialist cabinet grows after moderation, while the client profile remains one tap away.

Specialist cabinet after moderation — consultations, schedule, recommendations and the referral code — The account keeps one identity and changes context: the specialist cabinet grows after moderation, while the client profile remains one tap away.

3. Finding and booking a specialist

On the client side the service inherits the language of the store: a strip of specialties, sorting, quick filters for online, in person and nearby, and a detailed filter for rank, category, price and experience. The specialist card puts credentials, patient types and the next free slots above the fold and ends in a single price — the things a client checks before trusting a stranger with a health question.

Booking is date, time and format, then a checkout with a comment for the doctor, the offer agreement and the cancellation rule stated up front. Payment closes with a sheet that leads straight to the client’s consultations, and the store home announces the new section next to the products.

Choose date and time — format toggle, calendar and free slots — Once trust is established in the catalogue and profile, the booking flow narrows to three decisions: when, what exactly is being purchased, and where the confirmed consultation now lives.

Booking checkout — specialist, consultation details, comment for the doctor, offer agreement and the cancellation rule — Once trust is established in the catalogue and profile, the booking flow narrows to three decisions: when, what exactly is being purchased, and where the confirmed consultation now lives.

Shipped on the web: the catalogue keeps the card language of the store, and the profile keeps credentials, services and the cancellation rule on one screen with the price.

4. Running consultations

For the specialist the service is a schedule and a list. The schedule starts empty and is built in two moves — pick the dates open for booking, then the slots for each day, with a repeat option for a regular week. The consultations list separates planned from completed; each planned entry can be confirmed, taken to chat or cancelled with a reason that the client receives.

Chat lives next to the booking, so moving a consultation is a conversation inside the app rather than a phone call outside it.

Schedule — choosing the dates open for booking on a calendar — Availability is built before appointments arrive; each booked slot then leads to the same operational actions — confirm, contact the client or cancel with a reason.

Schedule — time slots per day with a repeat option — Availability is built before appointments arrive; each booked slot then leads to the same operational actions — confirm, contact the client or cancel with a reason.

Web specialist cabinet — the list of upcoming consultations with client, request, payment status and the actions to confirm, message or cancel, next to a schedule summary and the personal promo code — Shipped on the web: consultations carry their status and the three actions from the mobile model, and the schedule is set once as open days and time slots, repeated weekly.

Web specialist schedule — a month calendar with the days open for booking, the time slots of the selected day, a weekly repeat toggle and the save action — Shipped on the web: consultations carry their status and the three actions from the mobile model, and the schedule is set once as open days and time slots, repeated weekly.

5. Supporting flow: the partner programme

Specialists bring clients into the store through a personal promo code: the client gets a discount on the catalogue, the specialist gets cashback on every order and a bonus when the month’s total crosses a threshold. Joining is a short questionnaire of its own — city, how you heard about the programme, personal details and the code — with the one error that matters handled inline: a code that is already taken.

The code lands in the cabinet next to consultations. That is the loop the service was built for: advice in a consultation, a recommendation with a code, a purchase in the same app.

Partner programme — a short questionnaire to join — A personal code closes the commercial loop inside the same product: consultation, recommendation and purchase.

Choosing a personal promo code — A personal code closes the commercial loop inside the same product: consultation, recommendation and purchase.

6. A later audit: the states the flow was missing

A later case-study audit found the happy path complete and eight failure states missing — the ones a real service meets early. I designed all eight in the existing component and content system. The three shown here carry the highest operational risk: a profile returned for fixes, a date with no available time, and a booked slot that cannot simply be removed.

Cabinet when the questionnaire comes back — the reason and a way to fix it — The audit keeps the original delivery separate from the later case-study work, while showing how the product model handles real operational exceptions.

No free time on the chosen date — the nearest slot is offered instead — The audit keeps the original delivery separate from the later case-study work, while showing how the product model handles real operational exceptions.

Result

The work defined a connected consultation service inside the iTAB ecosystem. Specialists move from application and moderation to managing availability and consultations in one account; clients discover, compare, book and pay without leaving the store. The same model became the foundation for the web service that shipped.

One product model for two journeys: eligibility, scheduling, payment and cancellation follow shared rules across the specialist and client sides.

An extension of the store, not a second product: the service reuses the existing account, catalogue language and checkout instead of introducing another login and a disconnected experience.

From concept to release: I carried the core journey into the shipped web version, from specialist onboarding and scheduling through client booking and payment. A later audit expanded the mobile model with the failure and edge states shown in this case.