Superchat AI - Conversational Assistant Onboarding
Solving a trust problem in AI onboarding: how to get users to grant calendar, contacts, and payment access when they haven't yet seen the product work.
The Problem Before the Design
The Challenge
Superchat AI is a personal assistant that handles bookings, payments, calendar management, and messaging through conversation. It had roughly 3,000 users at the time of the brief. The onboarding problem was not a visual one it was a trust one.
Asking for calendar, contacts, location, and payment access before delivering any value creates a trust cliff: users hit a wall of permission requests before they have a single reason to say yes. The challenge was to redesign the onboarding so that commitment follows proof, not the other way around.
Approach
Discovery started with mapping the current experience not the app, but a real-world task. Following a UAE professional trying to book a restaurant reservation through her existing tools, the journey touched 9 separate apps and touchpoints: Calendar, Google, Instagram, Zomato, WhatsApp, a phone call, a third-party booking site, email, and iPhone Reminders all to complete one task, with no handoff between any of them and no automated follow-through.
That map defined the real opportunity: not a better search tool, not a better booking form removing the need to coordinate between tools entirely. The value proposition became the design brief.
Three Directions That Shaped the Design
New users need to trust the product before committing to it feature tours tell, they don't prove.
Permission requests need to arrive after value, not before otherwise the ask feels extractive.
The empty chat state needs to give users something to react to a blank input with no context loses users before the first message.
Structural Response
The answer to all three: defer everything that creates friction auth, permissions, pricing until after the user has seen the product work. Onboarding demonstrates value first. Permissions surface mid-conversation, framed as a value exchange, only when the action actually requires them. Auth comes after the product has already proven itself.
From Strategy to Interface
The 11 screens translate the strategy decisions directly into interface moments. Each screen resolves one of the three problem statements identified in discovery.
Onboarding-01
Entry point. Full-bleed visual with a single value proposition sets tone before asking anything.
Onboarding-02
Demonstrates the restaurant booking capability through a live chat demo proves the product before asking for commitment.
Onboarding-03
Calendar capability demo shows the AI reading and summarising a real schedule.
Onboarding-04
Payment splitting demo shows the action completing, not just the interface existing.
Sign In / Sign Up
Auth arrives here after four screens of proof. Three options, no friction hierarchy.
Empty State
Resolves the blank input problem. Suggestion chips give users something to react to without prescribing a path.
First Chat
User's first message sent. AI in processing state shimmer loader with visible status text maintains trust during latency.
Permission Request
Location access surfaces here, mid-conversation, framed as a value exchange. Deferred until the action actually needs it.
Response-01
AI begins processing shimmer shows live search query text, not a generic spinner.
Response-02
Streaming response begins. Text reveals progressively, mimicking natural conversation pacing.
Response-03
Full response delivered map widget, restaurant cards, and a structured follow-up prompt replace the free-text input to guide the next action.