Unifying signup raised completion
from 54% to 64%

Vedantu is an online learning platform for school students in India, sold through a mix of live classes, recorded courses and offline centres. Almost everything the business does after a student arrives depends on four details: which grade they are in, which board they follow, which exam they are preparing for, and where they live. Those details decide which courses appear, which counsellor calls them, and which centre is offered.

By early 2024 those four details were being collected in at least five different ways. Signup had been added to the product repeatedly, page by page and campaign by campaign, and each addition had been reasonable on its own. Together they had produced a system where the same student could be recorded three different ways depending on the page they happened to land on.

I was the only designer on the project, from the first audit to the rollout. I worked with one product manager, one analyst, and the app and web engineering teams. The flow went live on the app on 18 September 2024 and on the web on 25 September 2024.

The website and the app had grown several separate signup flows, each asking for different details, in a different order, with different wording. The app asked for stream but never for city. The homepage asked for city but never for stream. The course pages asked for academic year, which nothing else did. None of them agreed on what a complete student record looked like.

None of this was the result of a bad decision. Each flow had been built for a specific page, at a specific time, by a team solving the problem in front of them. The cost only became visible once the records were put side by side.

That split cost us twice over.

For the company, grade, board, target exam and city were stored differently in each place, and sometimes not at all. Leads were routed to counsellors on details nobody could fully trust, course recommendations were built on partial records, and any analysis of who signed up had to begin by reconciling five formats. When a team cannot trust its own data about a user, every decision downstream is made with a margin of doubt attached.

For the student, signup was longer than it needed to be and different every time. A student who signed up from a search result, then returned through the app, met two unrelated experiences and was often asked for the same things again. Every extra question sits between a person and the thing they came for, and none of these questions had been reviewed as a set.

The brief was to build one signup flow that asks the same questions everywhere - grade, board, stream, target exam and language - on both app and web, with every answer written to one shared record. The constraint that made it interesting was that the business did not want less data. It wanted more of it, and more reliably. So the flow could not be made shorter by dropping questions.

Two things followed from this table. The first is that unification was a data problem before it was a design problem. The second is that any new flow would have to carry the full set of questions, which meant the only lever left was how those questions were asked.

Six months of data, from February to July 2024, showed the homepage signup completing at a consistently higher rate than the one on our search landing pages. The explanation the team reached for was the page itself: somebody who arrives at the homepage has usually already decided to look at us, while somebody arriving from a search result may only want the one worksheet they clicked on. On that reading, the homepage flow was not better designed, it was better positioned.

It was a reasonable explanation, and it was convenient. It implied the design work was already done and the fix was a matter of placement. That is exactly the kind of conclusion worth being suspicious of, because the two flows differed in more than one way at once: the homepage flow was also shorter and lighter. Position and structure were tangled together in the data, and nothing in six months of reporting could separate them.

So rather than design to the explanation, I wrote it down as a claim that could be proved wrong, and proposed testing it:

Six months of data, from February to July 2024, showed the homepage signup completing at a consistently higher rate than the one on our search landing pages. The explanation the team reached for was the page itself: somebody who arrives at the homepage has usually already decided to look at us, while somebody arriving from a search result may only want the one worksheet they clicked on. On that reading, the homepage flow was not better designed, it was better positioned.

We ran both versions on the same set of search landing pages, splitting traffic evenly across all devices, so that position, traffic source and intent were held constant and structure was the only thing left changing:

Version A, the step-by-step flow: every question asked one at a time, each screen carrying a single decision, with a progress bar running the full length of the journey.

Version B, the homepage flow: fewer screens, fewer clicks, more questions grouped together, and a lighter visual treatment. This was the version the team expected to win.

The gap held at every stage of the funnel, not just at the end, which mattered. A single-stage difference can usually be explained away by one awkward screen. A difference that appears at verification, widens at completion and survives to the overall rate is a property of the flow, not an accident of one step.

The result was more useful to the team than a confirmation would have been. A confirmed assumption would have sent us to work on placement and left the flow untouched. Being wrong told us the structure was the lever we actually had, and that more screens are not the same thing as more effort, as long as each screen asks for one thing and the end stays visible.

These are the five calls I made, and in each case what I was arguing against. Two are about strategy, two about the system underneath, one about the paths in and out. For each: the constraint, my decision, the result, and what it cost.

One entry point handles new and returning users across phone, Google and email. Existing accounts go to login; new ones continue into the onboarding questions. I mapped every branch before designing a single screen, and that map is what kept all seventeen entry points consistent once engineering split the build across two platforms.

This flow has more screens than the version it was tested against, and a higher completion rate. Each screen asks one thing, and the progress bar runs to the final step, so the end stays in sight throughout.

One signup replacing seventeen separate entry points - homepage, search and download pages, course pages, free trials, offline centres and more - only works if every path and every failure has been designed for, not just the one where nothing goes wrong.

In a flow at this volume, these are not edge cases in any meaningful sense. A one-in-fifty failure is thousands of people a week. I specified the six paths and eight messages below myself, and they took longer than the five main screens did. They are the reason the completion figure held once the flow was live for everyone rather than for a test slice.

We could not work out a student's academic year reliably enough to infer it, so the flow asks for it once a year instead. It is the one question in the flow that exists because of a limitation rather than a need, and it breaks the rule the rest of the design follows. I flagged it as a known gap with a proposal to derive it from enrolment and activity data later, rather than leave it as a permanent question.

I would also want a second test on the onboarding questions themselves. The test I ran compared two structures for the same set of questions; it did not tell us which of those questions earns its place. That is the study I would propose next.

A student record is only accurate for one academic year. The Class 10 student we recorded last year is in Class 11 now, has chosen a stream, and may be preparing for a different exam. If the record stays as it was, course listings, recommendations and counsellor calls are all aimed at a student who no longer exists.

As the limitation above explains, we could not work out the new year reliably enough to update records ourselves. Moving everyone up one class would also be wrong for the students it matters most for: those choosing a stream after Class 10, and those finishing Class 12 who may take a drop year. So the platform asks. My job was to design that question for people who had already answered it once, so that it felt like a quick update rather than signing up again.