Improving conversion in the application flow

The Problem

Talent.com is a global job marketplace connecting employers and job seekers. Quick Apply lets job seekers apply without leaving the platform, using saved profile data.

The flow was failing both sides: real job seekers were dropping off before finishing, while employers were drowning in bot submissions. In the previous month, nearly 80% of applications were bot-driven traffic that led to no revenue or employer value. Parts of the flow also weren’t instrumented well enough to tell us where real users were actually dropping off.

Goal

Increase Quick Apply conversion while making the flow harder for bots to exploit, improving value for existing employer clients and making new customer acquisition easier.

My Role

I was the lead and sole product designer on this project. The core team included a PM, a developer, and a data engineer. I led the UX audit, identified the highest-impact problems with the PM and translated them into sequential fixes and experiments, created high-fidelity mockups and prototypes to validate decisions, and reviewed implementation with engineering.

Impact at a Glance

A particularly strong aspect of our collaboration was Carla's ability to communicate design intent. Understanding the reasoning behind her decisions helped me make better technical tradeoffs.

Discovery: Understanding Where the Experience Was Failing

Quick Apply involved several steps, each a potential drop-off point.

Auditing the flow exposed friction at nearly every step

I began with a full UX audit and walkthrough of the end-to-end experience for authenticated and unauthenticated users across mobile and desktop. The problems compounded across the flow: users couldn’t easily tell what was required or how many steps remained. The system was failing to prefill information it already knew, asking users to repeat work. Fixing resume prefill alone increased basic details completion by 11%. Mid-flow authentication broke momentum at the point of highest intent. And localization errors, OTP delays, and broken verification states interrupted progress at every turn.

Incomplete tracking was hiding the real drop-offs

Once tracking was in place, we identified three major leak points, each pointing to a different kind of failure and requiring a different response:

• 61% drop during the first step (contact information), most likely a structural acquisition problem. The majority of Talent’s users don’t browse jobs on the platform directly. They encounter a listing on another job board, click through expecting to land on a company career page, and find themselves on Talent’s interface mid-application instead. For many, it’s their first encounter with the product. The drop was real, but the cause wasn’t something a UX change could fix. We noted it and moved on.
• 37% drop during OTP verification: friction affecting motivated users who had already started applying, driven by a combination of technical issues and confusing verification UX
• 22% drop in the Review step: late-stage abandonment after users had already invested effort, with mobile users disproportionately affected at the final step

These findings pointed to three distinct problems requiring different solutions. But running parallel to the funnel work was a separate investigation into bot abuse. When the scale of it became clear, it reordered priorities. Nearly 80% of applications were bot-driven, which meant the funnel data itself wasn’t trustworthy. Authentication moved to the top of the list: it was the most urgent lever to stop the abuse and the only way to get clean signal on what real users were actually doing.

---

Redesigning the Entry and Verification Flow

Without a sign-in prompt at entry, the problems compounded in ways the funnel didn’t fully capture. New users (30%) landed mid-application on a platform they’d never used. Returning users who weren’t signed in risked creating duplicate accounts. And Google SSO users who entered their Gmail triggered OTP instead of their Google login, potentially splitting their application history in two.

The case for a login gate

No one likes a login gate. But authentication at entry was the most defensible path to filter abuse and reliably prefill information for any returning user. It’s also industry standard for most application flows, which gave us confidence in the tradeoff. Moving authentication to the start introduced a small, expected dip in overall conversion.

Bringing the login form into the flow

I brought the existing Talent.com login form into the flow, unlocking Google SSO for Quick Apply for the first time, and made a few adjustments.

I updated the login title and description to feel specific to the application rather than a generic sign-in. I also disabled the Continue button until a valid email was entered, unlike the standard Talent.com login where it’s always active. The intent was to nudge users toward Google SSO, visible and immediately clickable, since that path bypasses OTP altogether.

The existing job context strip was kept at the top but reduced in height to give the login form more prominence.

Before

After

Making OTP easier to recover from

The funnel showed a 37% drop at OTP verification. Most of it wasn’t voluntary: 27% of users failed or were blocked by the step itself, while only 11% chose to abandon. We addressed the technical side (rate limiting and auto-fill) alongside the UX changes.

I changed the title from “Complete your application” to “Check your email” so the screen matched what users actually needed to do. I clarified recovery by adding a change email address action, added explicit troubleshooting guidance (check spam folder), and resurfaced Google SSO as an alternative path when verification failed.

I also removed the step tracker from the OTP screen. OTP is part of authentication, not the application, and the original tracker made this worse by quietly dropping one step once OTP was complete, leaving users with a lower count than when they started.

Before

After

---

Redesigning the Review Step for Completion

Review-to-submit had a 22% drop overall, and it was worse on mobile where drop rates ranged from 5–14% versus roughly 2% on desktop. By that point, users had already done the work, which made this a costly place to lose them.

Why Users Were Dropping Off

I suspected users were reading the review step as a confirmation screen rather than a final checkpoint. The title “Review your application” plus the email address felt like a confirmation receipt. Collapsed accordions hid the information and edit options, so users couldn’t immediately see their answers or make changes. And on mobile, the chunky header pushed the submit button out of view entirely.

Making the action unmistakable

I started with the framing. I changed the step title to “Review and send application” and the CTA to “Send application” so the screen read as an action, not a receipt. I replaced the email address with a short warning that changes couldn’t be made after sending, which better matched what users needed to know at that moment. I also refined the text hierarchy, reducing visual weight on labels and giving more emphasis to the answers users actually needed to check.

Then visibility. On mobile, I reduced the header footprint and tightened the whitespace so review content was easier to reach. I removed the accordion pattern entirely so users could immediately see their information and edit affordances. I added a sticky CTA so the submit action stayed visible as the page grew longer.

Before

After

My initial MVP was more conservative. I planned to keep the accordion pattern and expand all sections by default so answers and edit options were visible. But once engineering and I started simplifying the interaction by removing nested scrolling and stripping out shadows, rebuilding the review step as one continuous review surface became the cleaner, lower-effort solution.

Surfacing the security check

The security check didn’t appear for everyone, but when it did, the CTA was disabled until it was completed. The problem was that the check sat at the bottom of the page, below the button. Users had no way of knowing what was blocking them until they scrolled past the action they were trying to take. I moved the security check above the CTA so the dependency was visible and the disabled state made sense.

Before

After

Applying the same fixes to desktop

Before

After

The review step sample was too small for a clean A/B test, so we made the call to ship the changes and monitor conversion directly rather than wait for a test environment that would never give us clean signal.

After the redesign shipped, review-step completion improved from 75% to 92%, confirming that the drop was an interface problem, not an intent one.

---

What I’d do differently

Required field visibility kept getting descoped despite having designs ready. Fields weren’t marked until users hit the CTA and got an error, at which point they had to scroll back to fix them. The fix touched a shared component, which made it a harder sell. I’d push harder for a scoped version limited to the apply flow.

Where it was headed

The top-down goal was to improve conversion, and the immediate priority was right: understand the funnel, close the leaks. But from the start I questioned whether optimizing the flow alone would be enough. Working across job seeker experience initiatives gave me enough exposure to competitor products to suspect we had a bigger problem: no one inside the team had a clear picture of what competitors were actually doing. I proposed a competitive analysis as part of the Q1 roadmap, it got approved, and I ran it in parallel with the flow work, evaluating the full apply experience across Indeed, ZipRecruiter, and Talent.com across six dimensions: how each platform signaled the apply type before users entered the flow, authentication strategy, flow architecture, data reuse and resume maturity, effort protection, and post-submission behavior.

The findings confirmed we had a positioning problem, with competitors winning either through velocity or platform value. Rather than optimizing individual steps, the priority needed to shift to closing structural gaps in sequence: first remove the highest-abandonment risks, then make speed visible to returning users, then build the resume infrastructure that would enable compounding improvements over time.

My analysis included a sequenced roadmap with clear rationale. I shared it with leadership for prioritization. A company-wide restructuring changed what the team focused on before those decisions were made.

One piece of that roadmap that was already in design: for authenticated users applying to jobs without employer screening questions, the review step added friction without adding value. I designed a one-step apply variation where eligible users would land on a pre-filled contact form and submit in a single step. The designs were ready but hadn’t shipped.

Thanks for reading!

Get in touch if you would like to know more about this project.