Post-Application Recommendations
The numbers said the module was fine. Using it told a different story — a hierarchy rebuild grew its share of all applications from 8.2% to 11.6%.
View → Application
Company
Remember
Timing
H1 2025
Role
Senior Product Designer
Team
PM, Design, Data, Engineering
Contribution
Owned redesign end-to-end
Improved stage
Exposure
→
View
→
Apply
→
Hire
Overview
1
v1 shipped
by a junior designer I mentored (already 8.2% of all applications)
2
Firsthand friction
the hierarchy answered the wrong question. I prototyped the fix and made the case
3
Redesign
hierarchy + CTA rebuilt: 11.6% share
The post-apply screen was a dead end until a junior designer I mentored shipped the first recommendations module there. Its numbers were solid. But using it firsthand, the experience wasn't. I made the case to the product team with a working prototype, so they could see and feel the friction themselves, and owned the rebuild.
Problem
v1's hierarchy celebrated the wrong moment: 'application complete' dominated the screen while the module title sat small beneath it. Behavior data showed why that mattered: a first application takes days of deliberation, but the ones that follow happen within minutes. Right after applying, the user's question isn't 'did it work?' It's 'what's next?', which the screen wasn't answering.
v1 as shipped: solid numbers, but 'complete' dominating and the next action buried
Hypothesis
If the screen answered 'what's next' instead of celebrating completion (module title promoted, completion demoted to a quiet confirmation), the module's share of all applications would rise well above its 8.2% baseline.
My Role
Firsthand audit · case for rebuild
Redesign ownership
Hierarchy & CTA structure
Web–app consistency
Design Decision
I inverted the hierarchy. The completion notice shrank to a small line above the title; the module title took the visual lead; the CTA led straight into the next application. The screen's job changed from confirming the last action to accelerating the next one, matching how users behave once their first application is in.
Considered and rejected: sunsetting the module. The team keeps only what moves applications, so retirement was a live option. But the behavior data said the demand was real; the interface was the constraint.
The rebuild: module title leading, completion demoted, CTA straight into the next application.
Result
8.2% → 11.6%
share of all applications on Remember
+3.4pp, measured in the A/B week. Same module, same logic; the change was the interface
Daily applications through the module later grew from ~60 on weekdays to peaks near 250. Different period from the A/B week; not directly comparable.
Measured
A/B test at 50:50 for one week; the lift was large and immediate. Metric = applications via the module ÷ all completed applications on Remember. UI changes only, with no recommendation-logic or exposure changes in the window.
Trade-offs & Guardrails
Interrupting the completion moment could read as an upsell, so the module frames itself as a continuation of the user's own search. Recommendation scope stayed anchored to the posting just chosen (similar requirements and position), keeping added volume within expressed intent.
What This Shows
This was a project where I took ownership as the designer, and visual and UX changes alone drove a large result. Functionally, nothing was broken. But judging from my own use of it, the UX and UI weren't giving users 100% of what they needed in that moment. Instead of arguing it, I prototyped the improvement and let stakeholders see and use it themselves. That is what got it built, and the A/B results came back strong.
Learnings
Craft that had been deprioritized for shipping speed proved measurable: the lift made UX/UI quality visible across the org.
Next
User interviews later showed role fit isn't the whole picture: company type (big tech vs. startup) weighs heavily too. The planned next iteration shifts the recommendation logic from requirement-similar postings toward company-similar ones.
