Case study · Product design
One-Click Apply: redesigning how funding programs are created, applied to and reviewed
How I redesigned the full path of a funding program, from the provider who sets it up to the member who applies with one click to the reviewer who decides, without asking anyone for something the system already knew.
Senior Product Designer · Mar 2025 to present · Member portal and back office · Happly, white-label platform
Role
Senior Product Designer. I designed all five parts and ran design QA on the built screens.
Team
The PM, who wrote the PRD until the handoff, the company lead, front-end and back-end developers, and me.
Timeframe
March 2025 to present: the first redesign from March to July 2025, the second in May 2026.
Tools
Figma
What One-Click Apply is
One-Click Apply is the idea that a member who has already told Happly about their business shouldn’t have to tell it again to apply. The first version existed before I joined. My work started in March 2025 with its redesign and grew into the whole chain: how programs are created, how members apply, and how reviewers see the applications.
The company’s 2025 product review lists that redesign (program creation, application management, the reviewer experience and member One-Click Apply) as one of the biggest UX upgrades of the year.
The path of one program
Five parts, all designed by me
01
Provider sets up
Program creation
Default and additional questions
Challenge 4
02
Member applies
Program list
Check my eligibility
One-Click Apply
Challenges 1, 2, 3, 6
03
Reviewer decides
Application management
Reviewer flow and fit score
Pending-tab approval
Challenge 5
Every challenge below sits at one of these stops. One-Click Apply is the middle one, and it only works if the other two hold.
Many small decisions between two screens
A funding program on Happly is created by an organization in the back office and applied to by a business owner in the member portal. Between the two sit a lot of small decisions: which questions the applicant must answer, whether they’re eligible, what the button does, and what the reviewer sees afterwards.
Each of those decisions already had an answer, built into the back end. The redesign had to change what people saw without breaking any of it.
“Please make sure not to remove or break any existing journeys, conditions, or API logic.”
The PRD, on what the redesign had to keep
So design review became an inventory of states: any state the back end had without a design got flagged, not dropped.
What the PRD asked for
Condensed from the PRD the PM wrote before handing off. Every challenge below answers one of these lines.
Goal
A member applies in one confirmation when the system already has what it needs; a provider creates a program and configures what’s asked; a reviewer sees applications and a fit score that helps, not decides.
Users
Founders and small-business operators on the member side; program managers and admins who create and configure; reviewers who decide.
Success criteria
“Apply” is enabled only when the program is open and the member is eligible, and when it’s disabled the reason is on screen. Contact details are prefilled, and an edit applies to this application only. The questions screen appears only when the program has extra questions. The AI fit score is labeled as a guide. Every previous state and API behavior still has a UI, or is flagged.
Non-goals
Changing eligibility logic or the matching model; removing existing journeys; letting the score decide.
Constraints
Existing back-end behavior keeps working. English and French. Individual and business accounts. Programs hosted on Happly and external opportunities take different paths: Apply for the first, a link to the funder or the browser extension for the second.
Challenge 1 of 6
Member applies
Browse first, check later
Situation
Before the May 2026 redesign, a member answered the mandatory matching questions before seeing the program list, so that matching could run.
Decision
Show all programs regardless of status, with the same call to action on every card: “Check my eligibility”. The mandatory questions appear when the member clicks it. While the check runs, every card shows a checking state; then High, Medium or Low results appear. “Apply” is enabled only if the program is open and the member is eligible.
Order of operations
Before and after May 2026
Before
1
Mandatory questions
The first thing a new member met
2
Program list
After the form
3
Apply
After, May 2026
1
Program list
Every program, any status
2
Check my eligibility
The same questions, asked here
3
Apply
Open and eligible only
Same questions, same matching. Only their place in the path moved, from the door to the first click.
Outcome
The listing page and the apply journey were scoped at 8 engineering days, done on 26 May 2026, and their QA closed on 2 Jul 2026. The PM presented the finished design to the team with that reasoning: members now explore before they are asked anything.
What made it hard
Matching is the product’s strongest idea, and asking first protects it. But the first thing a new member met was a form, not a program, and friction at the front of a funnel is expensive and hard to see.
Options
A
Keep the questions as the gate
B
Show the programs, hide the match
C
Show every program and run the check when the member asks
Chosen
Challenge 2 of 6
Member applies
A disabled button has to say why
Situation
Two QA rounds, a year apart, reported the same thing in different words: a member with a high match found the apply button disabled and didn’t know why. In July 2025: “high matches with the button disabled”. In March 2026: “eligible, 85%, but I’m not sure why it’s disabled.”
Decision
Disable it and give the reason in a tooltip: “Not eligible” or “Program closed”. While matching runs, the button is disabled too. The existing states, re-apply (with past submissions in a tooltip) and already applied, kept their behavior and got designs.
One button, seven states
Illustration, not a screenshot
Check my eligibility
Before the check
Checking…
While matching runs
Disabled
Apply
Open and eligible
Apply
Not in the audience
Tooltip: Not eligible
Apply
Program closed
Tooltip: Program closed
Already applied
Submitted once
Re-apply
Applied before
Tooltip: past submissions
Only one of these is a working Apply. Every other state says, in its own words, what it is waiting for or why not.
Outcome
The QA of the new journey still found gaps: a disabled header button off the design system, a loading flash on every visit even when the match was done, and the “not eligible” path still to design. They were logged as design-system and state bugs and handled in that QA round.
What made it hard
There were several valid reasons: the program was closed, the member wasn’t in the program’s audience, the deadline had passed, the maximum number of applications was reached, or the check was still running. To a member they all looked the same: a grey button.
Options
A
Hide the button
B
Leave it disabled and silent
C
Make the disabled state the explanation
Chosen
Challenge 3 of 6
Member applies
Ask once, ask later, never ask twice
Situation
To apply, the system needs a phone number and an email. The first onboarding questions asked for them, along with everything else.
Decision
In April 2026 the rule was set: the onboarding wizard asks only what smart matching and One-Click Apply need, so no email or phone. When a member clicks Apply, the confirmation modal shows contact details prefilled from the profile. They can edit them, but the edit applies to this application only. With no contact details on file, the fields are blank and required. If the program has additional questions, the next screen asks them; otherwise the application is submitted.
What is asked, and when
The profile is the source
Onboarding
Only what matching and One-Click Apply need
No email, no phone
Click Apply
Contact details, prefilled from the profile
Edits stay on this application
Nothing on file
Contact fields blank and required
Asked once
Program questions
The next screen asks them
Only if the program has them
Submitted
Nothing asked twice
Read it top to bottom: each line is asked only if the lines above haven’t already answered it.
Outcome
The modal tells the member that their profile will be used for the application, which sets the expectation that the profile is the source of truth.
What made it hard
Onboarding is one of the most expensive moments in the product, and contact details aren’t needed to run a match. Asking at the start adds a step with no benefit; asking at the end can feel like a trap.
Options
A
Keep them in onboarding
B
Ask for them in the apply step
C
Treat the profile as the source and ask only when it’s empty
Chosen
Challenge 4 of 6
Provider sets up
Program questions without breaking “one click”
Situation
Providers wanted to ask questions specific to a program, beyond what a member’s profile already holds.
Decision
Two kinds, never mixed. Default questions come from the organization’s profile-question settings: they apply to every program, are always mandatory, and are read-only on a program’s page, with a link to where they’re managed. Additional questions are added per program, are optional by default, and are built from scratch or from templates.
The setup is a full page, not a modal, in three panels: the question list with the default ones locked, a live preview, and the selected question’s settings. The PRD was written as three journeys: admin configuration, member application, admin review.
The program’s own question sits above the default ones, which carry a lock; the middle column is what the applicant will see. Real screen, demo data.
Outcome
The honest part: on 1 May 2026 the team decided to rename the feature, because with mandatory extra questions it is no longer a true one click. At the time of writing the name was under review, so this page keeps the name One-Click Apply.
What made it hard
Every extra question makes “one click” less true. And there were two kinds of question that behave differently: ones the organization requires for One-Click Apply across all programs, and ones that belong to a single program.
Options
A
Let each program define everything
B
Keep programs free of questions
C
Separate the two kinds clearly
Chosen
Challenge 5 of 6
Reviewer decides
The reviewer sees help, not a verdict
Situation
A provider reviews many applications, and some organizations want staff and partners to submit for an admin’s approval instead of publishing on their own.
Decision
The fit score is a column in the applicants list and appears again on the application page, calculated after submission, in three tiers: High, Medium, Low. The subtitle never varies: “The score and insight are AI-generated from application details. It’s a guide, not a guarantee.” The existing reviewing system (statuses, assignee, messages, requested files, private notes) stays as it was.
An export gives the whole application as a spreadsheet: personal profile first, then business profile, then additional questions, with unanswered fields as empty cells so nothing is hidden. For organizations that need a second pair of eyes, “Publish” becomes “Approval request” for staff and partners, and items wait in a Pending tab for an admin.
The built list: each application carries a Fit score of High, Medium or Low beside its status and assignee. Real screen, demo data.
Outcome
Reviewers keep the whole application and their own tools; the score only changes where they look first. It is one more place where the product keeps its rule that the AI advises and a person decides.
What made it hard
An AI score on an application is useful and risky. Used well, it tells a reviewer where to look first. Used badly, it quietly becomes the decision.
Options
A
No score
B
A score with a verdict: recommend or reject
C
A score as one column among others
Chosen
Challenge 6 of 6
Member applies
The edge that two portals create
Situation
Organizations run their own portals, and a member can have accounts on more than one. In August 2026 a production report showed a member who had signed up separately on two portals getting stuck: the magic link answered “Client not found”, and registration refused because the email already existed.
Decision
This was a back-end fix, filed and fixed the same day, 28 Aug 2026. I include it because it’s the failure “one click” invites: the shorter the path, the less room there is to recover from a wrong turn. The design response is a rule: every disabled or failed state on the apply path needs a way back.
What made it hard
Each side behaved correctly by its own rule. Together they left a person with no way forward, which no single screen would have shown.
By the numbers
What the record shows, with its source. The record has dates and counts, and no conversion or efficiency figure.
Two years on one ruler
Sep 2024 to Oct 2026
2024
2025
2026
First version, before I joined
Sep–Dec 2024
I join Happly
Feb 2025
Pending-tab approval
Mar 2025
First redesign
Mar–Jul 2025
“How can apply” field
Aug–Sep 2025
Contact-details rule
Apr 2026
Rename decided
May 2026
Second redesign, then its QA
May–Jul 2026
Cross-portal fix
Aug 2026
Two waves of work a year apart, with the first version, built before I joined, at the left edge.
4
Parts named in the product review: program creation, application management, reviewer experience, member One-Click Apply
Company’s 2025 product review
19
Major platform features the product team delivered in 2025; this initiative is one of them
Same review
13
Tickets with “one-click apply” in the title, Sep 2024 to Aug 2026
Jira search, counted 13 Oct 2026
3
Journeys in the additional-questions PRD: admin configuration, member application, admin review
The PRD
8
Engineering days estimated for the May 2026 listing and apply redesign
Jira comment, 11 May 2026
0
Conversion or efficiency figures found for this work
None in Jira, Slack or the review
“Significantly improved provider efficiency and member conversion” is the team’s own description. I have no number for it, and this page won’t make one up.
What I’d measure next: apply-start to submit rate; the share of members who click “Check my eligibility” after seeing programs, against those who completed the old mandatory form; time from opening a program to submitting; how many disabled-button views end in a submission later; reviewer time per application with and without the fit column; and how often the reviewer’s decision disagrees with the tier.
What I learned
Order is a design decision.
Moving the questions from before the programs to after the first click changed the whole feel without changing the logic.
Every state is a screen.
The disabled button was the most reported problem, and it had no design.
A name can outlive its meaning.
“One-Click” stopped being literally true when mandatory extra questions arrived, and the team said so.
Claim what you can show.
The efficiency and conversion gains are credible and unmeasured. I’d instrument before I’d quote.
Next.
Instrument the funnel, design the “not eligible” path with next steps, and settle the name.