CASE STUDY · TEAM PROJECT · ONBOARDING & REGISTRATION
Kitravia
Two very different sign-ups, one trustworthy AI travel platform.
PROBLEM
A single registration flow can't serve a traveler who wants in fast and a hotel partner who needs to be verified before going live.
SOLUTION
Two differentiated flows built on progressive profiling a light, quick path for travelers, and a guided, trust building verification path for business partners.
IMPACT
Both flows shipped to hi-fi and handed off dev ready inside a 5-week sprint for client.
MY ROLE
Interaction & Tech Lead owned onboarding & registration for travelers, partners and admins, end to end.
.png)
Team: Ron · Monika · Elke
Client: Kitravia (CEO Yannick)
Product Design
Onboarding · Figma · ~2 min
2
3
differentiated onboarding flows
user types designed for
6
5
wks
sprint, research → dev handoff
user interviews informing trust patterns
1
Discovery & Definition
DISCOVERY · EMPATHIZE · DEFINE
One platform, three very different people signing up.
Kitravia needed to onboard leisure travelers, hotel
& business partners, and internal admins — each with different urgency, risk, and information needs. Treating registration as one generic form would either overwhelm travelers or under-vet partners.
→ Travelers want in within seconds, friction kills conversion
→ Partners are handing over a real business, they expect
scrutiny, not just a form
Business partner onboarding
→ Business goal: frictionless, differentiated flows using
progressive profiling
Onboarding · Figma · ~2 min
Trust is earned in stages, for both sides.
"I would want to review every single step first. I'm also very doubtful of giving a platform access to my bank."
JACQUES · TRAVELER
"Simple navigation, no hidden clauses, no bunch of ads, that's what makes a platform trustworthy."
RYAN · TRAVELER
15 interviews across the design team (Ron, Monika, Elke). Users grant trust incrementally, and a platform asking for too much too soon reads as risky. The same instinct partners bring to handing over a real business.
The insight that shaped both flows.
"
KEY INSIGHT
Trust has to be built in stages, asking for everything up front breaks it on either side of the platform.
Nadia Ferreira
B2C TRAVELER · WANTS CONTROL, NOT FRICTION
Plans her own trips, compares 3–4 sites every booking. Wants to move fast without handing over more than she has to, up front.
Marcus Bennet
BOUTIQUE HOTEL PARTNER · 32 ROOMS, CAPE TOWN
Resents paying OTA commission without ever seeing real guest data. Needs a partner path that feels credible enough to trust with his business.
2
Design
IDEATION · WIREFRAMES · PROTOTYPE
Two paths, minimal asks, right on time
Registration branches at the very first screen: "I'm looking to travel" vs. "I want to list my business." From there, each path uses progressive profiling, collect the minimum to get someone in, then request more detail contextually, later, when it's actually relevant.
TRAVELER PATH
Fast in, profile grows over time
Email/social sign-in, name, travel intent. Preferences,
payment and documents are requested later, at the point they're actually needed.
PARTNER PATH
Guided, verification led
Business details, property info, ownership verification, then a review step before the listing can go live. Each stage shows what's next and why.
Built on Kitravia's real design system.
Every screen uses the shared Kitravia design tokens, so onboarding feels native to the rest of the product from the very first screen, not like a bolted on form.
Primary Blue
#004AAD
Dark
Navy
#0E1B30
Verified/success
#16A34A
Pending review
#DDA12B
.png)
Partner verification
Progress and status, always visible.
Multi-step forms show a clear step indicator throughout, and partner verification uses colored status so nobody wonders where they stand.
Choose your path
.png)
Business partner
Traveler sign-up
.png)
Minimal fields, fast entry
Partner verification
.png)
Colored status clear next step
3
Validation
TESTING · ITERATION · OUTCOME
Validated through research themes and design critique, not a dedicated onboarding test.
Within the 5-week sprint, formal usability testing was prioritized on the Traveler Dashboard. Onboarding was validated against the 15 interviews and heuristic review with the team, directly applying the trust and decision gate findings from research.
Being upfront: a dedicated moderated test of both onboarding flows, especially partner verification, with real hotel owners is flagged as a next step, consistent with the team's broader recommendation to test the Partner Dashboard before development.
Small clarity fixes, big confidence gains.
1
Removed upfront trust-damaging language
Interviews flagged that leading with caveats (e.g. AI disclaimers) creates doubt before a user even starts, applied the same logic to onboarding copy.
2
Decision gates before any commitment
Users wanted to review before proceeding, never be auto enrolled, with each onboarding stage requires explicit confirmation to move forward.
3
Status visibility for partners
Verification stages show exactly what's pending vs. approved, addressing partners' need for transparency after handing over real business data.
OUTCOME
Two flows, one platform that treats different users differently.
Splitting the path early let travelers move fast, and gave partners the verification their business actually needs. Both shipped hi-fi and
dev-ready. Next: test the partner flow with real hotel owners
2
differentiated flows shipped
3
person design team
5 wks
research → dev handoff
ROADMAP
Where Kitravia goes next.
COMPLETE
NEXT
ONGOING
1
2
3
✓ COMPLETE
Discover
Research with travelers and partners to map three distinct user needs.
✓ COMPLETE
Design​
Two onboarding flows, from wireframes to dev-ready hi-fi.
✓ COMPLETE
Validation
Research themes and design critique applied directly to onboarding.
Moderated sessions with real hotel owners on verification.
4
→ UP NEXT
Test the partner flow
∞
ONGOING
Test, learn, iterate
Keep refining both flows as travelers and partners grow.