Spark AI
GROWTH DESIGN
AI
ONBOARDING
About the Project
By the time Spark launched its AI Assistant, every email client had one. The hard part was never building the feature. It was answering the question every user asks in the first three seconds: why would I use this instead of the ChatGPT tab I already have open? Spark had a real answer — an assistant that sits inside your inbox and can act on it. But an answer is worth nothing if nobody stays long enough to hear it. And Spark handles people's email, which meant asking for trust and money in the same breath was never going to work. I designed the onboarding: what the assistant teaches you, what it shows you, and when it's allowed to ask you for anything.
Research & Direction
I audited more than fifteen products — Superhuman, Shortwave, Notion, Perplexity, ClickUp, Grammarly and others — looking at one thing: how each one demonstrates that its AI is worth paying for, and how long it waits before asking. Three patterns held across the ones that worked: - Quick actions surface value faster than any explanation of it - Gating the high-value features is what actually drives trials - An upgrade prompt inside the conversation feels earned; the same prompt on a wall does not The diagnosis underneath all of it: AI assistants don't fail at answering. They fail at the blank prompt field. A user who doesn't know what to ask will judge the product on their own worst question and leave convinced it can't do much.
Design Process
The flow teaches you what to ask, shows you real value on your own inbox within seconds, and only then offers a trial. Three moves, strictly in that order. Teach. Assistants need a mental model before they need a prompt field. The first thing a user sees is what this thing is good at, framed as things they might actually want. Show. The proof runs on the user's own mail, not a demo account. Showing local, private indexing before selling anything raises consent and lowers the temperature of the whole interaction. Offer. Small wins create buy-in. Once the assistant has found a real email a user was looking for, they feel capable rather than sold to — and "Try Spark Plus" lands after that success, never before it. Responses couldn't be hard-coded, so I worked with engineering to design the business-logic model the Assistant's suggestions are built on. Default prompts adapt to what a user told us during onboarding — use case, pains, goals, seniority — and to what we can observe: calendar activity, a corporate domain. Someone drowning in notifications is offered "Archive unread notifications older than 2 weeks." A manager is offered "Help me plan my week." I specified each prompt end to end: the user-facing wording, the instruction sent to the assistant, the expected outcome, and the follow-up. Every suggestion had to work as a useful action first and a conversion touchpoint second.
RESULTS
The flow shipped on desktop and mobile and rolled out to the full user base. Adoption was close to universal among users who activated Spark AI, and ratings on assistant responses ran overwhelmingly positive — enough that the sequencing question was settled: teaching before showing, and showing before offering, held up in production. The in-chat upgrade prompt outperformed the placements it replaced, which is the part I care about most. It suggests the offer landing after a success moment is doing the work, not the offer itself. Specific figures are covered by my agreement with Readdle.
ROLE
Product Designer — competitive research, onboarding strategy, the Teach–Show–Offer flow, the personalised prompt system, and paywall placement. Desktop and mobile.