A product designer with 4+ years of experience turning complex problems into products that people love to use.
Reimagined the candidate onboarding journey, smoothing first-time setup so seekers reach their first meaningful action faster and with less drop-off.
Turned an AI screening SKU into an embedded hiring workflow — making AI explainable evidence recruiters can act on, not a black-box verdict, while keeping them in control of every decision.
Redesigned the job search results page into a clearer, personalized experience with Match Score insights and richer job details.
Designed a source-agnostic, enterprise-grade AI hiring platform that screens and interviews candidates across every sourcing channel — built solo from concept to launch, with humans kept in control of decisions.
"Preeti is born curious and has been very crucial in defining and building user experience at Foundit. She has an eye for detail for the work. She is a go-getter and asks the right questions. She is really quick with iteration and absorbing feedback."
"Preeti began her career at Foundit, successfully transitioning from an intern to a full-time role. Over her two-year journey, I witnessed her remarkable growth, which gave us the confidence to entrust her with multiple key projects. She consistently delivered outstanding results with minimal guidance, handling them single-handedly."
"Had the privilege of working with Preeti at the start of her UI/UX design journey. Her rapid growth and dedication were evident from day one. She has evolved into a skilled designer, showcasing a keen eye for user-centric solutions. Her passion and work ethic make her a standout professional in the field."
"Preeti is one heck of a hardworking youngster in Foundit's Product Design team. I have literally seen her exponential growth curve before my eyes — from intern to full-time, driven by sheer passion, hard work, and curiosity to improve. She constantly comes up with new ideas and never shies away from a healthy debate."
"Preeti is one of those people you can trust with a problem and be confident it will be driven to a thoughtful, high-quality outcome. At Apna, she consistently demonstrated strong ownership, handled complex initiatives independently."
"Worked with Preeti at Apna and honestly she's one of the best designers I've collaborated with. Her design and product thinking is really sharp — she never rushes to solutions. She digs deep into the problem first, asks the right questions, and challenges assumptions before touching Figma."
View the chapter on my interests, stories
and life outside of work.
I'm a Product Designer currently designing AI products at Apna, owning end-to-end experiences across candidate and recruiter platforms. I love exploring how design can tell stories, spark emotion, and make everyday moments a little more meaningful.
With 4+ years of experience, my work spans UX audits, research, critique, and prototyping — turning complex problems into intuitive, thoughtful experiences.
My journey started with a love for painting and sketching, and that curiosity still drives how I approach design today — with creativity, empathy, and a genuine interest in people.
Away from the screen, you'll usually find me watching movies, painting, sketching, café hopping, or getting lost in a good series — always collecting little bits of inspiration along the way.
Currently based in Bengaluru, India. If you're building something with heart, let's talk!
My story so far is about learning to see people, patterns, and possibilities, and using design to turn that understanding into something that makes a difference. ✦
Digital experiences that feel effortless, considered, and genuinely useful.
Redesigned the existing job search results page, where seekers view job listings and job descriptions, for both mobile and desktop platforms.
About Foundit: Formerly known as Monster, Foundit is a talent management platform that not only facilitates connections between job seekers and companies but also offers services to enhance candidate skills. It also offers comprehensive solutions for businesses, facilitating the discovery and recruitment of top talent.
Foundit users face several challenges that hinder their job search experience and diminish engagement:
The primary objective of redesigning the job search results page is to create a streamlined, personalized, and user-friendly experience that addresses current issues of cluttered layout, lack of personalization, broken UX, and insufficient job information. By enhancing visual clarity, incorporating smart insights like a Match Score, and ensuring comprehensive and user-friendly job details, we aimed to significantly improve user satisfaction, engagement, and provide more job applications after the revamp.
Drivers:
Key Metrics:
We began by segmenting the job search result page into three parts: job cards, job descriptions (JD), and filters. Our initial focus was on enhancing the job card section.
Current Job Card Analysis — The current job card included: Job Title, Company Name, Job Type, Job Location, Years of Experience, Salary, Skills, Date Posted, Tag (e.g., Great Place to Work), Save Icon, GPTW Banner.
Initial Questions and Considerations:
To understand how we can enhance the job card experience, we conducted comprehensive user research using a mixed-methods approach including Surveys, In-depth Interviews, and Usability Testing.
Key Findings:
The revamped job card includes: Job Title, Location, Experience, Estimated Salary, Company Logo, Smart Tags (Early Applicant, Quick Apply, High Match), Job Posting Date, and Save Job Feature.
After Redesign: The redesigned job card for the same position maintains the essential details but presents them in a more streamlined and visually appealing manner:
After finalizing the job card, we proceeded to redesign the job description (JD) section. Initial analysis revealed job titles lacked prominence, job descriptions were presented in long paragraphs making it challenging for users to scan, and overall UI improvements were needed.
JD Research Key Findings:
The existing filter functionality was riddled with inconsistencies, creating confusion for users. Many available filters were underutilized by job seekers. Our goal was to redesign the filter functionality to align with industry standards, simplifying the job application process and enhancing user experience.
Revamp of the existing seeker profile page of Foundit (formerly Monster.com) to improve usability and significantly boost job seeker engagement, encouraging more frequent and seamless profile updates.
About Foundit: Formerly known as Monster, Foundit is a talent management platform that not only facilitates connections between job seekers and companies but also offers services to enhance candidate skills. It also offers comprehensive solutions for businesses, facilitating the discovery and recruitment of top talent.
The current seeker profile isn't user-friendly and has a fragmented, broken experience. This issue is adversely affecting the frequency of profile updates.
By revamping the profile page, we aimed to improve usability and significantly boost job seeker engagement, encouraging more frequent and seamless profile updates. Our goal was to create an enhanced and intuitive user experience that increases user interaction and satisfaction.
Current M-site and App experience showing the pain points:
Participants: 6 users, mixed gender, age 22–34 years. We conducted moderated usability testing over 1 week.
Tasks given to participants:
Priyanka Sharma, 32, Finance Manager — Main Goal: Secure a role with ample growth opportunities. Pain points: Annoyed by excessive pop-ups disrupting smooth profile navigation. Believes the profile score is not easily visible. Finds prominent banners distracting, mistaking them for ads. Finds it difficult to navigate between different sections.
Ansh Thakur, 25, Software Engineer — Main Goal: Obtain a senior engineering position at a leading tech company. Pain points: Frustrated by numerous pop-ups that interfere with seamless profile navigation. Finds the navigation between profile sections cumbersome and time-consuming. Notices inconsistencies in the design that make the user experience less professional.
Avg traffic on profile page (Sep 23 – Jan 24):
The user feedback analysis highlights crucial redesign priorities for the job seeker profile page. Streamlining intrusive pop-ups, prioritizing seamless mobile access, and enhancing profile score visibility are focal points. Addressing banner inconsistencies and emphasizing the work experience section align with user preferences. The redesign will integrate robust resume parsing, clear prompts, and early skills placement in the visual hierarchy. Introducing multiple resumes and refining job recommendations aim to accommodate diverse needs. The overarching goal is a user-friendly, visually cohesive profile page tailored to the unique preferences of job seekers in India, fostering a positive and efficient user experience.
A source-agnostic, enterprise-grade AI hiring platform that screens, interviews, and coordinates candidates across every sourcing channel, while keeping humans in control of the final decision. Built solo from concept to launch.
Enterprise hiring teams handle huge volumes of candidates from many channels at once: job portals, ATS, databases, referrals. OnlyRounds is a source-agnostic, enterprise-grade AI screening and interviewing platform that lets teams screen, interview, and coordinate candidates consistently using AI agents, no matter where those candidates came from.
What it is not: not limited to apna-sourced candidates, not a single static chatbot, and not a hiring-decision engine. Final calls always stay with humans.
apna's earlier AI screening product (AISKU) worked well for SMBs because apna was their primary sourcing channel. For enterprises, apna contributed only a fraction of total sourcing, so most candidates still fell back to slow, manual screening and the ROI of automation collapsed.
Design a platform that unifies all sourcing channels into one pipeline, lets recruiters configure trustworthy AI agents for screening and interviewing, and orchestrates outreach at enterprise scale, all without taking the hiring decision out of human hands.
JD ingestion, structured job creation, interview-round setup, and evaluation-criteria editing.
Configuring voice/video agents, language, persona, and reviewable scripts, with a test-before-go-live step.
Multiple entry points converging into one pipeline, with distinct inbound and outbound (consent-first) experiences.
Status tracking, recordings, AI summaries, and credit/usage reporting for the workspace.
Recruiters paste, upload, or AI-generate a JD; an LLM extracts and cleans it into a structured job that becomes the source of truth. They then set up interview rounds (screening, interview, or human-led tasks), edit AI-generated evaluation criteria, configure each agent (voice/video, language, persona), and test the agent before going live.
A single source-of-truth JD plus editable, AI-generated criteria makes setup fast without giving up recruiter control, and the test step builds trust before a real candidate is ever called.
Candidates enter via bulk upload, embedded apply links, direct interview links, or auto-sourcing from ATS and job platforms, and all of them land in a single pipeline per job. Inbound candidates (who have intent) go straight into screening with a short intro; outbound candidates (contacted from a database) get an interest check and give consent first. The screening criteria stay identical across both; only the entry script changes.
Keeping evaluation criteria constant while varying only the entry script gives fair, comparable results across sources, and consent-first outbound respects candidates who never asked to be contacted.
An orchestration engine coordinates multi-channel outreach, deciding when to contact a candidate, through which channel (call, WhatsApp, email), for what objective (interest, screening, interview, scheduling), and what to do on response or silence. It optimises for time-of-day and honours retry limits and night-time policies. The design principle: agents decide what task; the workflow decides when and how.
Separating "what" (agents) from "when/how" (workflow) kept the system understandable to configure and dramatically lifted reach; automated coordination hit candidates at the right moment on the right channel.
After each interaction, the data is scored by an evaluation agent against the recruiter's criteria and resolved to a clear status: Fit, Not Fit, Partial Fit, Not Interested, No Response, or In-Progress. In the recruiter portal, teams see status at a glance, listen to recordings or watch videos, and read AI-generated summaries, plus credit and usage reporting for the workspace.
A tight set of well-defined statuses plus one-click access to the recording and summary lets recruiters act in seconds, and keeps the final judgment human, backed by the actual evidence.
Letting agents own the task and the workflow own timing and channel kept an inherently complex system configurable and legible.
Every source has a different candidate state; the UI had to normalise them into one pipeline without hiding what mattered.
Editable criteria, test-before-go-live, recordings, and summaries let recruiters hand work to AI while keeping the decision, and the accountability, human.
Outbound candidates never asked to be contacted, so an interest-check-first flow wasn't a nicety; it was the design.
Recruiters hiring frontline roles receive hundreds, even thousands, of applications per job. AI Recruiter interviews candidates, evaluates answers against recruiter-defined criteria, summarises every conversation, and recommends qualified candidates before any human interaction. It was never meant to replace recruiters. It removes repetitive first-round screening while recruiters keep complete control of the final decision.
The shipped product in action: AI Agent evaluation inside the recruiter dashboard.
apna is India's largest hiring platform for frontline roles: telecalling, delivery, customer support, sales. Volume is the defining problem. Every candidate still needs manual screening, repetitive qualification checks, and follow-up calls before a recruiter can identify the right fit.
AI Hiring Assistant exists so that hours of daily calling stop delaying hiring. The AI conducts the first screening interview automatically. Recruiters open the dashboard to qualified, explained recommendations instead of a raw pile of applications.
Pricing and Monetization was owned by the Monetization team. I collaborated closely with them, along with Product Managers, Engineers, AI teams and Business stakeholders, through research, design, validation and launch.
This chapter covers the journey up to Iteration 2. Launch results and Phase 2 come later.
Recruiters hiring at scale repeatedly told us the same thing:
Instead of helping recruiters screen candidates faster, what if the first screening round was already completed before recruiters even opened the dashboard? That became the foundation of AI Recruiter.
They wanted it to remove repetitive work while giving them enough evidence and control to make the final decision.
Help recruiters use AI screening to make faster hiring decisions while preserving trust, control, and confidence?
The legacy flow, end to end, from checkout to candidate list:
The recruiter journey
The candidate journey
Mapping this made one thing obvious: AI Recruiter was not a single feature. It touched multiple products across the hiring ecosystem.
Introduce AI Recruiter as an add-on while making its value immediately understandable.
Help recruiters configure interview criteria with minimal effort.
Present AI recommendations in a way recruiters trust and can confidently act upon.
An interview flow that feels conversational rather than intimidating.
Rather than attempting to perfect the experience immediately, we built a set of initial concepts covering all four touchpoints. The goal was not visual polish. The goal was learning, before investing heavily in development.
These became our first hypotheses. The early explorations below became our Phase 1 prototype.
Hypothesis: recruiters will pay for AI at checkout if the value is obvious at the moment of posting a job.
We slotted a Smart-AI tier beside Classic and Premium, priced above Premium, with an inline demo so recruiters could experience a screening call before paying. What we expected to learn: whether checkout is where conviction happens.
The first pricing concept: a third AI tier with a demo interview entry, straight into checkout.
The demo: recruiters talk to the AI before they buy it.
Problem: configuration effort kills adoption. Assumption: if AI drafts the questions from the job details, recruiters only need to review, mark deal-breakers, and continue.
Questions pre-drafted by AI from the job post. Deal-breaker toggles make criteria decisive.
Full control on tap: answer types, preferred answers, remove.
Setup opens right after the job goes live, while intent is high.
Expected behaviour: recruiters accept most AI questions, edit a few, and finish setup in minutes.
The riskiest questions lived here. Cards or tables? Depth or speed? Rather than commit, we explored four dashboard concepts and let the trade-offs surface. No final direction yet. The purpose was divergent thinking.
Rich cards: maximum transparency per candidate.
Table: maximum scanning speed.
Master-detail: list beside full AI evidence.
Filter-first: control for high-volume pipelines.
Approach: conversational, not intimidating. The AI screening call reached candidates right after applying, with a simple in-call layout: duration, mic and volume controls, nothing to learn.
Iteration 1: the call arrives immediately after applying, while intent is hot.
We wanted completion and comfort. Whether an instant call delivers either was exactly what testing had to answer.
With Iteration 1 in front of recruiters, we needed evidence, not opinions. We wanted to understand how recruiters actually screened, what information they trusted, which UI elements they ignored, whether AI influenced decisions, and where friction lived.
Insight: AI was not convincing as a standalone purchase; recruiters wanted to experience it first. Problem: the demo lived too deep in checkout. Change: the AI card moved to the centre with a Recommended tag, value props on the card, and the AI recruiter introduced on the dashboard itself, before posting, with a walkthrough and real voice clips. Expected impact: higher demo engagement and premium attachment.
The AI tier moves centre. Framing does the selling.
Value props and the voice waveform, on the card itself.
Meet your AI recruiter, before you even post.
The walkthrough, plus selectable pre-recorded voices.
Insight: recruiters said setup felt like configuring an employee. They wanted to hear the voice and control the company pitch. Problem: Iteration 1 read as a form. Change: voice avatars in English, Hindi and regional languages, an editable company pitch, and AI-generated questions to review. Expected impact: setup completion up, drop-offs down.
Pick a voice, shape the pitch, review the questions.
Progressive feedback while the agent gets ready.
Insight: hidden insights were ignored; five signals drove every decision. Problem: reasoning sat two clicks deep. Change: an AI Agent Fit tab in the pipeline, with the evaluation, criteria checks and key signals visible directly on the candidate, and recordings one tap away as the tie-breaker. Expected impact: faster shortlists, higher trust in Fit.
The direction after testing: a fast list, AI evaluation at the surface, proof one tap away.
Insight: instant calls made candidates anxious; they wanted preparation time. Problem: the interview started the moment they applied. Change: a transition state, "your interview is about to begin", with preparation cues before the AI connects. Expected impact: higher completion, lower drop-off.
Iteration 2 shipped. What follows is what six months of live numbers told us.
Every number below comes from the live metrics tracker, from launch week through the end of January.
And the numbers that told us the truth:
We read the data and the complaints case by case. Five fixes shipped while Phase 1 was still live.
Mid-interview drop-offs died as "inconclusive". Restarting meant repeating everything.
No-response climbed toward 35 to 44%.
Candidates with several AI applications could not tell the calls apart.
Some recruiters wanted only top matches, others a broad pool.
Shortlists stayed at 4 to 6%. Recruiters verified everything.
Overview
Onboarding was built as a single linear data collection flow applied uniformly to every user, whatever role they came for. A delivery partner and a software developer complete the same number of steps, at the same depth, before either one reaches the job feed. It converts at 67%, takes ~12 minutes, and asks for 6 to 12 steps of input before delivering any value.
The fix is role based branching plus progressive enrichment: split onboarding into a Fast Track Flow for gig roles and a Deep Profile Flow for regular roles, and recover the deferred data later, at moments when the user is already motivated.
01 · Problem statement
Onboarding asked every user the same questions, in the same order, to the same depth. A delivery partner looking for gig work and a software developer complete the same number of steps before either of them reaches the job feed — even though what we need to know to match them could hardly be more different. One needs a licence, a vehicle and an area. The other needs a title, a stack and a salary band. We asked both for all of it.
That flow runs 6 to 12 steps and about twelve minutes, and none of it returns anything on the way: no job, no salary, no sign that employers are hiring. Applying the deepest profile we might ever need to every user, regardless of role, is what pushes people out. A third of everyone who logs in never finishes.
It did branch, but only on education level and work status. It never branched on the thing that decides how much we actually need to know: the job the person is doing today.
02 · Who our users are
The flow they landed in was built around credentials, which is not what a gig job needs. The sharpest version of that mismatch sits inside this third.
Delivery, driving, logistics, security. A third of the base has low tolerance for form filling.
Which routes almost half of them into the longest experience subflow we have.
The sharpest wedge. They want a gig job but get routed through the deepest, most credential heavy flow, because we branch on education instead of role.
A graduate applying for a delivery role is treated as a graduate first and a gig seeker second. They absorb 10 to 12 steps of profiling for a job that needs almost none of it.
03 · Objectives
Fewer fields people misread, and a flow that feels shorter than the one it replaces. Read from dropoff per step, and from what users say in testing.
Baseline qualitative · Target qualitative04 · The current flow
After login, every user got the same screens in the same order. Only two answers changed anything: education level and work status. Those two splits made four different paths: the shortest was seven screens, the longest sixteen.
How to read this: the percentage on a screen in the funnel sheet is how many people landed on it, so the shortfall belongs to the screen before. 95.3% land on basic details, which means 4.7% gave up on language. Only 90.5% reach language at all, so a further 9.5% leave between login and the first question.
05 · Qualitative baseline
The most common and most direct complaint across the initial round.
Fields like Job Role and Industry. The taxonomy is ours, not theirs.
Questions are irrelevant and not personalised. Gig workers get white collar questions.
Visuals are not explanatory, and are actively confusing in places.
What this leads to: 33% funnel dropoff, and widespread incorrect data in role, industry and similar taxonomy driven fields.
06 · What was going wrong in the data
Roughly 3,800 people a cycle log in and never finish. The resume path and the graduate experienced branch are the two weakest routes in the product.
How to read the funnel: the figure on a screen is the share of the previous screen’s users who arrived. So the loss belongs to the screen before it: 88.94% reaching the work status screen means 11% gave up on the education screen. Below are the screens people were actually standing on when they left.
Company and industry is the single worst screen in the product; it loses nearly a quarter of the 10th/12th experienced branch. Education costs 11% of everybody. And barely anyone gets as far as the resume screen: 22% of graduate freshers and 31.6% of graduate experienced users drop on the step immediately before it. Every one of these is typing heavy; the screens people tapped through held above 97%.
What the data was telling us
People weren’t dropping off because of who they were. They dropped off because of how far we made them walk.
07 · Defining the problem
Better copy and better buttons don’t help a flow that is simply too long for the person walking it. The path itself had to get shorter, and it had to get shorter for the people who need it shorter, without flattening it for the people who don’t.
The usual objection is “we’ll lose match quality.” But users were already filling role and industry wrongly because they didn’t understand what was being asked. We were already losing data quality. Collecting fewer fields people actually understand may produce a better database than collecting many they guess at.
Show jobs as early as possible. Value precedes data.
Input required should be proportional to intent and role complexity. A delivery role should not cost the same as a developer role.
Collect only what is essential upfront. Defer the rest to a moment where the user has a reason to give it.
08 · How we decided to work
The tempting move was to redraw the whole flow in one release. We deliberately didn’t. Change fifteen screens at once and you get one number and no explanation: if completion moves, you have no idea which change earned it, and no way to know you left points on the table.
Three test variants on a single question: how much education do we need upfront? Nothing after education is touched.
Built on whichever variant wins. Persona branching, and the experience section reworked per persona.
After the two rounds of measured change, sit with the people the flow is for, and find the problems the funnel could never explain.
Scope set by the findings rather than by inference.
Each phase inherits the previous one’s answer instead of relitigating it. Onboarding is also the only gate into the product, so a regression here suppresses every downstream metric at once, another reason to move in measurable steps.
09 · Phase 1 · Milestone 1
Scope was cut deliberately: the language screen removed, basic details and location reworked, and nothing after education touched. All three variants carry those same front half changes, so any difference between them is down to education handling alone.
No structural change. Carries only the front half improvements; everything after Location is identical to production. Isolates the value of those changes, and acts as control for the other two.
Tests whether the dropoff follows the screen or is caused by its position. It distinguishes “education is hard” from “education is hard this early.”
Education sits at the final step of onboarding and can be skipped outright, then asked later when the user applies to a job and the field’s purpose is self evident. The most aggressive test, and a dress rehearsal for the enrichment model Milestone 2 depends on.
Test 3 is the cheap proof. If deferring education to job apply works without collapsing data completeness, the whole progressive profiling thesis gains evidence for the price of one variant.
Test 2 is the safety net. If Test 3 wins on completion but craters education capture, Test 2 offers most of the gain at much lower data risk.
In Test 3 the education screen is skippable during onboarding. The fields come back inside the job application, bundled with the document checks that job already requires. By then the candidate has found something they want, so the question has an obvious reason behind it.
All three variants ran for two weeks against a held back control. The completion read is in the next section; education capture and day one apply rate are still to come.
Designs: Figma: experiment milestone 1 & 2
As usual !! :)
NOW COMES THE FUN PART
DID USERS ACTUALLY USE IT?
Milestone 1 · Results
Every variant carried the same front half changes, so Test 1 is the honest control for the other two: whatever separates Test 1 from Test 2 and Test 3 is education handling alone. Read that way, the result is sharper than the headline number suggests.
Completion is login success through to interest selected. 94,710 logins over two weeks, roughly 23,600 per arm, with traffic split evenly across the four arms.
Language screen removed, basic details and location reworked. Control to Test 1.
Same screen, same fields, final position. Test 1 to Test 2. Nothing moved.
Identical position to Test 2. The only difference is that answering became optional.
10 · Phase 2 · Milestone 2
Milestone 2 picks up everything after the work status screen, on top of the Milestone 1 changes: the front of the flow reworked to location, education moved to the end. This is where the ~20% drop across the experience section lives.
| Screen | Drop |
|---|---|
| Years of experience | 2% |
| Company & industry name | 9% |
| Job details | 10% |
| Job role | 1.5% |
| Skills | ~1% |
| Salary | 2% |
| Preferred role | ~1% |
Two screens carry almost all of it: company and industry, and job details.
We do not ask for a job title on the first screen. The classification happens later, from a question we were already asking.
Delivery · Driver · Logistics · Cook · Security. The experience detail screen becomes optional or disappears entirely, and no notice period is asked of anyone already employed.
Everything else. The detailed work history stays, but industry is gone and salary is asked monthly.
The gig list is configurable, and it is the most load bearing definition in the project; every branching decision and measurement cut depends on it. For the initial rollout it is Delivery, Driver, Logistics, Cook and Security. It needs to hold the titles people actually type, including vernacular and spelling variants.
Industry selection is removed. It was a 9% drop on a field already being derived from the company name.
Salary is asked monthly, not as annual CTC. Someone paid per delivery or per shift can answer monthly without doing arithmetic first.
Three shared screens, then the split. Scroll a lane sideways to see it all. A gig driver clears four groups; a non gig graduate clears five plus a resume.
| Gig | Non gig | |
|---|---|---|
| Control | Flow as it is today | Flow as it is today |
| Test 1 | Experience details skippable; no notice period if employed | Experience details skippable; anything skipped is asked in the assessment flow |
| Test 2 | No experience screen at all, captured in the assessment flow instead | Experience details mandatory |
Allocation is by user ID: Test 1 on IDs ending 00 to 29, Test 2 on 30 to 59, control on 60 to 99. Variant 2 also asks for expected monthly salary rather than current.
The first read on these variants is in the next section. Step level dropoff, time to first job view and D1 apply rate are still to come.
Milestone 2 · Results
Milestone 2 tested the experience block: remove those screens for gig roles, or leave them in but let people skip and answer later. Both beat control, and the effect is far larger inside the gig cut than across everyone — which is what the branching was built to do.
Profile completion against control. The all users row is 76% against a 70% control, so +6 pp. Removing the screens outright beats making them optional by roughly 3 pp inside the gig cut.
The baselines are not the same number. Milestone 1 measured a 78.74% control on login to interest selected. This reads a 70% control on profile completion. Different gate, different population, so the two gains cannot be added together or compared directly — each one only means something against its own control.
What Milestone 1 established still holds. There, moving a required screen changed nothing and making it optional moved everything. Here the same shape appears again, one step further in: the biggest gain comes from removing the ask entirely for people it was never serving, not from repositioning it.
Sample size and significance were not reported with this read, so treat the three figures as directional until the cut sizes are attached. Step level dropoff, time to first job view and D1 apply rate are still outstanding for this milestone, as is the size of the post apply drop on the deferred questions.
11 · Then we talked to users
Two rounds of measured change in, we still hadn’t sat with a real user since the original pain point interviews. Seven moderated sessions, in person, think aloud, on the interactive prototype. The first field research on this flow in a long time.
User research
Seven participants, one at a time, on a clickable prototype of the shortened flow. Each was asked to sign up as themselves while thinking aloud, and we recorded where they hesitated, what they misread, and the screen they stopped on. The question was never whether people liked the design. It was whether a real jobseeker can get to the end of it without help.
Two decisions about how we ran the sessions did a disproportionate amount of the work, because each one exposed a failure the obvious setup would have hidden.
We moderated in Hindi but left the prototype in English, exactly as it ships. Translating it for the test would have been the comfortable choice, and it would have concealed the single most severe finding in the study: a participant who could not read the flow at all, and so never started it. Testing the real language is what made that visible.
We asked people to define CTC, Specialisation and School medium only after they had finished, without showing the screens again. Mid-task, someone who guesses and moves on looks identical to someone who understands — both just tap Next. Asking afterwards, from memory, is what separates comprehension from a lucky guess.
We explicitly did not test visual polish. Aesthetic feedback was redirected to function: “would that change whether you could finish signing up?” That is why every finding below is structural.
| # | Profile | Language | Outcome |
|---|---|---|---|
| 1 | Delivery agent, college dropout | Reads Hindi + English, limited spoken | Reached final screen, ~11 min |
| 2 | Delivery agent, graduate | Fluent both | Dropped off: current company details |
| 3 | Security supervisor + delivery | Fluent both | Stopping point not recorded |
| 4 | Security personnel | Speaks Hindi · cannot read Hindi or English | Could not start |
| 5 | Delivery agent | Basic both | Dropped off: current job details |
| 6 | Sales executive, 3 yrs (contrast case) | Fluent both | Completed smoothly: no confusion |
| 7 | 12th pass, no experience (fresher path) | Not recorded | Completed easily: few minutes |
Two clean completions: one white collar, one on the short fresher path. One reached the end with heavy friction, two dropped at the same screen, one couldn’t start. Every clean completion came from either a white collar profile or a shortened path.
12 · What we found
One participant (graduate, sales executive, fluent, tech savvy) completed the whole flow with zero confusion. Every critical and high finding in the study came from the six blue collar participants.
It validates the branching thesis from the qualitative side, and tells us the Deep Profile flow should be protected, not redesigned. Evidence for what to leave alone is rarer than evidence for what to change.
One participant speaks Hindi fluently but cannot read Hindi or English. He could not start at all. He is not technology averse; he uses a gated community app competently. The barrier is literacy.
A different category of problem: everyone else struggled through, he couldn’t begin. It’s also upstream of the router: he can’t enter a job title, so he can’t be classified at all. Our architecture has no answer for him.
The participant on the fresher path, which skips Experience Info and Skills entirely, finished easily in a few minutes. Three others complained, unprompted, that the flow was too long.
The first direct causal evidence that length itself is the problem rather than field wording. A shorter path produced a clean completion in the same segment where longer paths produced dropoffs.
Entering a title that isn’t in the suggested list failed in almost every session, regardless of literacy, education or English comfort. That independence points at the interaction, not the audience.
This is the finding that most threatens our own architecture. The router classifies on current job title, and the most broken interaction in the product is the router’s own input. So it is a Milestone 2 blocker, not an M3 line item, and it has to be rebuilt as guided, low typing selection.
Three participants hesitated or lost interest here. A college dropout was still asked for college details. One holding both 12th pass and a diploma couldn’t tell which applied, and that step took him longer than anything else. Another’s degree was missing from the list entirely.
This independently validates the Milestone 1 hypothesis from a different evidence base. We inferred education was the bottleneck from the funnel; users confirmed it and said why: the schema doesn’t describe them. That favours Test 3 or a conditional form.
Two participants abandoned at the identical step, independently. A third was confused but continued. Gig work often has no single traditional employer, so the question has no clean answer.
Two independent dropoffs at one screen is a signal, not a coincidence, and it needs a gig shaped version of work history, not a shortened version of the white collar one.
When a field took effort, people picked the first suggestion or entered something rough. Three defaulted to the first suggestion on title or skills. Two entered inaccurate values: a random salary, and a company name that was simply made up.
Empirical confirmation that we are already losing data quality. Profiles built by satisficing underrepresent what these users can do, which degrades matching, which produces fewer calls.
Two participants were existing users, already frustrated at getting no calls, and said so unprompted. One had found his current job through a competitor instead.
“We are asking so many fields but still we are not getting any calls.”
Every field is being judged against existing disappointment, not a blank slate. This validates Value First but also bounds what onboarding can fix: a shorter form will not repair a broken value exchange; it just gets users to the disappointment faster.
Occasional gig work is not a regular job, but it isn’t inexperience either. The same forced single choice appeared at qualification for someone holding both 12th pass and a diploma.
Our funnel branches on this binary and Milestone 2 layers persona branching on top of it. If the categories don’t match how users see themselves, we are branching on noise, and it may explain the unattributed users who exit at work status.
Four of the five whose location behaviour was recorded kept their current location, tapping “Yes” without reading, then adding the same city again. One read it and deliberately declined. Nobody used the picker as designed.
A screen with effectively zero successful engagement doesn’t justify its prominence. Two dead ends surfaced here too: a missing residential area, and no path forward at all when location permission was denied.
Three spent longer on the email field than on almost anything else. One filled it carefully despite it already being optional; he never noticed it was skippable, and was disengaged everywhere else.
Optional isn’t optional if it doesn’t look optional. Cheap fix, meaningful time saving.
The progress bar didn’t appear to inform pacing or motivation, and the resume nudge was ignored entirely.
Neither is earning its screen space in this segment.
13 · The verdict on our own plan
| Finding | Effect on the plan | |
|---|---|---|
| Confirmed | Segmentation is the right frame | Validates the whole branching thesis: proceed with confidence |
| Confirmed | Education is a genuine bottleneck | Validates Milestone 1; favours Test 3 or a conditional form |
| Confirmed | Length itself is the problem | Validates Fast Track’s ≤2 step goal |
| Confirmed | We already have a data quality problem | Removes the main objection to deferral |
| Changed | The router’s own input is the most broken interaction | Promotes custom title redesign from M3 to an M2 blocker |
| Changed | Literacy is a hard blocker upstream of routing | New workstream: the architecture has no answer for it |
| Changed | Don’t redesign the non gig flow | Deep Profile is a preservation job, not a redesign job |
| Bounded | Onboarding can’t fix the value exchange | Sets a limit on what any milestone can claim |
14 · Phase 3 · Milestone 3
Every item below started as something we watched a person struggle with, and is described the way they described it. Nothing here is inferred from the funnel alone.
Almost nobody could enter a job title that was not already in our suggestion list, whatever their education or English. That same answer is what decides which flow a person gets, so when it fails we either send them down the wrong path or stop them entirely. The branching cannot ship on top of a broken question.
One man speaks Hindi fluently but cannot read Hindi or English. He could not get started at all, and he is not new to phones: he already uses his gated community app competently. He never reaches either flow, because the first thing we ask him to do is read and type. We have no answer for him yet, so this became its own piece of work rather than a line in this milestone.
Screens exported from the Milestone 3 prototype, the same build the sessions above were run on.
What we are deliberately not touching: the longer flow for regular jobs. The one participant it was built for, a graduate sales executive, finished it without a single moment of confusion. We have evidence that it works and no evidence that it needs changing, so we leave it alone.
What onboarding cannot fix: two people told us, without being asked, that they fill everything in and still get no calls. One had found his job through a competitor. A shorter form does not repair that, and saying so now matters: if applications do not go up after this, onboarding may not be the reason.