StudySmarter
My role
Senior Product Designer
Year
2024 – 2026
Conversational Onboarding
2026
Signup asked new students to work through a sequence of form steps before they saw anything of the product. I replaced it with a chat: an assistant called Studley asks the same questions one at a time and fills the same fields from the answers. I designed it and built it in our new ways of working.
Problem
Every question is a screen they can abandon, and the sequence sits directly upstream of both the first learning session and the first paywall.
The form front-loaded all the work and delivered none of the value.
The framing was bureaucratic — it read like registration, not like help.
Two recent attempts at this same surface had already been rolled back, so the case for trying again was conviction rather than evidence.
Primary objective: collect exactly the same information, but make the first minute feel like being helped rather than being processed.
Process
The important decision was made early and it was a restraint: the conversation is scripted by the app, not generated by the model. The app owns the questions and their order. The language model does one job — interpreting a typed free-text answer into the current question's structured value.
Each question is a slot with its own input mode — tappable options, searchable lists, chips, or free text where it helps. Answers arrive structured, so the chat produced exactly the data the form did.
Messages appear one at a time, each preceded by a typing indicator. The pacing was a design decision, not an implementation detail.
An avatar travels through the flow with the student, changing emote by moment.
If the conversation stops making sense, it falls back to the original static flow instead of trapping the student.
Design insight: a conversational interface does not need a conversational engine. Scripting the questions and using the model only to interpret answers gave the warmth of a chat with the reliability of a form — and made the failure modes designable rather than emergent.
Outcomes & Impact
Live to half of new users across five markets, and stopped after two and a half days on a clearly negative read — roughly six thousand lines added on the tenth of August and the same six thousand taken back out on the twentieth, by the same person.
Reaching the onboarding paywall fell 13.5% — the only result strong enough to survive correction, and a direct commercial loss.
Mid-flow abandonment rose 22%. Completion fell about 10%, but the test stopped short of the sample it was sized for, so that one can't be called.
Every chat question fired the same analytics events as the screen it replaced, so both arms shared one funnel. Without that there would have been a negative result and no way to locate it.
The finding worth keeping: abandonment rose on all three platforms, but only iOS recovered from it — completion there was flat while web and Android each lost more than 11%. Baseline completion is far higher on iOS, so lengthening the flow cost most where there was least slack. Nothing about the interface explained which.
New Homepage Built Around Progress
2026
The homepage was organised around a student's material — a library of study sets. Once structured Learn Paths existed, that was the wrong organising idea.
Problem
The homepage hadn't been rethought in over a year and the product had moved underneath it. Learn Paths had replaced study plans as the structure students learned inside, but the page was still built around AI shortcuts that converted almost nobody.
Traffic from the homepage into a learning session had fallen roughly ten points since Learn Paths launched. The page had stopped being a way in.
Students weren't returning to browse their files; they were returning to continue something.
Survey work said students valued Learn Paths for orientation but resisted a fixed sequence — so progress had to be shown without reading as an instruction.
Process
I rebuilt the page around Learn Path progress, then tested two treatments of the same idea against each other: a task list showing what was coming up, against a single next task card that removed the choice entirely.
Outcomes & Impact
We kept the task list. The test didn't identify a clear winner — learning activation and engagement were flat between the two designs. What decided it was week-one retention running lower on the single-next-task version, and the explanation we landed on for why.
Post-learning Experience
2026
Finishing a study session produced a congratulations modal. You dismissed it and were returned to exactly where you started. The highest-intent moment in the product was being spent on a box you closed.
Problem
A student who has just finished something and feels good about it is the easiest person in the product to give a next step to. We were giving them a dead end — well over a third of students who finished a first session never started a second one.
Nothing communicated what the session had moved. The stats were generic study-set percentages designed before Learn Paths existed.
No next action, so momentum ended with the modal. The exit was a button marked "Done".
Progress lived elsewhere in the app, disconnected from the moment it was earned.
Primary objective: turn the end of one session into the start of the next.
Process
I replaced the modal with a full page that plays back progress against the student's Learn Path, shows what moved, and offers one clear next action.
Design insight: a modal is something you close; a page is somewhere you are. Only one of those can carry a next step convincingly — the container was doing more damage than the content.
Outcomes & Impact
Students reaching two or more days of real learning activity in their first week rose about 13% against control, statistically significant, on roughly 6,500 users over three weeks.
The team's headline retention conversion metric moved about +10%, also significant.
Time in learning modes and total sessions both rose around 8–9%, directionally consistent.
Two variants tested; the one tied explicitly to Learn Path chapters and lessons won.
Eight of ten metrics moved positive. The two that didn't were the monetisation ones — the moment drove learning, not purchases.
Oral Practice
2025
Oral Practice let students revise by speaking, and almost nobody used it. I rebuilt it around the material the student was already studying, split it into two distinct AI personalities, and designed the paywall that made it viable to run — the strongest commercial case I made at StudySmarter, and the one that shipped on judgement rather than significance.
Problem
The MVP had answered the hard question — students who used it came back, and it cost far less to run than we'd budgeted. The problem was that almost nobody got that far. Barely three in a hundred eligible students ever started a session, and two in three of those who opened it abandoned the settings modal before speaking a word.
Three setup decisions — a topic, a mode, a microphone check — stood between the student and the first question.
Nearly half the sessions that did start were ended early, most inside thirty seconds.
The AI had no access to the study set, so its questions were generic.
Speaking aloud is socially costly, and nothing in the design earned that cost.
Primary objective: make the first spoken question relevant and arrive within one tap — before asking the student to configure anything.
Process
I worked from the study set outward rather than from the feature inward, and tested the two modes as genuinely different characters rather than a toggle.
Entry moved into the study set the student was already in — no topic entry, no setup screen.
Conversations were grounded in the student's own flashcards, so question one was always on-topic.
Tutor is patient: it offers hints, lets you think out loud, and lets you recover.
Examiner asks, waits, and moves on.
Design insight: the difference between a tutor and an examiner lives almost entirely in copy, pacing and how interruption is handled — not in the interface. Designing a conversation is mostly designing behaviour.
Outcomes & Impact
Tested against a no-Oral-Practice control on roughly 56,000 users over five weeks. About one in thirteen exposed students started a session unprompted, with no promotion behind the feature at all. Premium activation was up around 17% and paid conversion around 23% — but neither cleared statistical significance across the whole population, and the analysis tool's own recommendation was to roll back.
We rolled it out anyway, and I think that was right. The uplift was significant among existing users in core markets, the AI cost was a few cents a session against a comfortably larger revenue return, and the downside was bounded. The decision was written up with the caveat attached: don't extrapolate this to segments where it wasn't significant.
Roughly three in four chose Tutor over Examiner — the patient persona was the real product, the strict one was the option.
Three in four kept the default session length, and almost nobody touched the filters.
Design insight: the clearest vindication of the redesign was in the settings nobody changed. The modal the first version insisted on was collecting answers that were, almost without exception, its own defaults.
Design insight: the paywall after three full sessions is what made the economics work — late enough that students knew what they'd be paying for, early enough to matter.
AI Podcast
2025
Every learning mode we had assumed a student sitting down and looking at a screen. The podcast was for the other times — commuting, walking, washing up — turning a student's own study set into an episode they could listen to instead.
Problem
All the value in the product was locked behind looking at it.
Asked what would make a subscription worth paying for, free users put audio and listen-and-learn formats near the top — above more of the AI practice we were already selling them.
An audio format has no interface to lean on. There is nothing to look at, so the design lives entirely in structure, pacing and what gets said.
Process
Generating a listenable episode from the student's own study set — the length, the shape, and what a generated script should and shouldn't try to cover.
Design insight: the interesting problem was not playback, it was selection. An episode has to promise something specific a student will get out of listening, and then honour it. Get that wrong and you've built a slower version of the study set they already had.
