Case study · Concept · Browser extension
GrantGPT: an assistant that fills in a grant form, and asks before it does anything
How I designed the rebuilt version of a browser assistant that sits next to someone else’s grant form, answers from a member’s Happly profile, and never moves on, or submits, without a yes.
Senior Product Designer · States, design QA, approval and pause screens · Feb to Sep 2026 · Happly, Chrome extension
Role
Senior Product Designer. States, design QA, approval and pause screens
Team
A PM who wrote the requirements, the company lead, front-end and back-end developers
Timeframe
Rebuild: Feb to May 2026. Agent version and landing page: Sep 2026.
Tools
Figma, Jira
Hero image: the GrantGPT side panel beside a grant form, on demo data (to come)
Where the form is
Happly knows a lot about a business: what it does, where it is, how big it is, what it has applied for. Most grant forms aren’t on Happly. They’re on a funder’s own site, with different questions on every page, so a member who finds a good opportunity still retypes the same company description into a stranger’s form.
GrantGPT is the idea that the assistant should go where the form is. It opens beside the page, reads the form, answers from the member’s profile and, where it needs more, asks.
So the design problem isn’t “make an AI that writes answers”. It’s how an AI sits as a guest on a page it doesn’t control, writes to a funder in a person’s name, and stays trustworthy while it does.
It writes in a person’s name, to a funder, on a page it doesn’t control.
The brief
What the requirements asked for, condensed.
Goal
A member answers an external grant application with AI help from their Happly profile, and stays in control of every word that is sent.
Users
Business members. Individual accounts can’t use it.
Success criteria
Sign-in happens on the platform, never in the extension. The member can answer all at once or one by one, and switch at any time until the application is marked submitted. Every answer can be edited by hand or rewritten with a prompt. A free monthly allowance behaves clearly when it runs out. The profile-readiness percentage informs and never blocks.
Non-goals
Not for individuals. Not a replacement for One-Click Apply on programs hosted on Happly. Never submits on its own.
Constraints
Every funder’s form is different, and the extension has to work in the browser the member already uses, whatever its theme or width.
Each of the six challenges below ends at a gate, the way the agent version ends every page of a form: what happened to the decision, said plainly.
By the numbers
A concept has no use to count, so the numbers are about the work: when it happened, and which part was mine.
The project, by date
From the project’s tickets
First version · not my design
Nov 2024
First ticket for the extension
11 Feb 2025
First delivery
Feb to May 2025
Numbered QA rounds, plus two by the company lead. The findings were theirs
5 + 2
28 May 2025
Marked done, counted from the first delivery
106 days
The part I designed
9 Feb to 2 Mar 2026
The rebuild, opened to done. I designed its states and checked each build against them
21 days
5 May 2026
Findings in the PM’s QA list for the rebuild
28
Sep 2026
The agent version’s approval and pause screens, and a landing-page hero
Today
Users and submitted applications. It was built and tested, never published, so there is nothing to count.
0
Read the rail from the top: the dark stretch is the part I designed; everything above it is the first version, which wasn’t mine.
Sign-in belongs to the platform
Situation
In the first version’s QA rounds, in 2025, someone who had signed up but not finished onboarding could log in to the extension and find an empty account. The team took the login out of the extension: “Log in to Happly” and “Create my Happly account” open the platform, and the extension picks up the session.
Decision
In the 2026 rebuild I designed the edges the rule left open. An individual member gets a dedicated screen: “You need a business to use the extension. Please add your business to continue.” A member who hasn’t finished onboarding is held with a message and a way to finish, because there’s nothing in the profile to work from yet.
Who opens the panel
Schematic, not the shipped UI
Signed out
Log in to Happly
Create my Happly account
No login fields
Individual member
You need a business to use the extension. Please add your business to continue.
Opens Happly
Designed in the rebuild
Onboarding not finished
[A message, and a way to finish onboarding]
Opens Happly
Designed in the rebuild
Business member
Ready
The assistant: reads the form, answers from the profile
The only state that reaches the form
Three of the four states end on the platform; the panel’s job in each is to say why, in one screen, and open the right page.
Gate 1 of 6 · Outcome
Kept
The sign-in rule held through every later round. Staying signed in on one side after signing out on the other was a bug QA found in the rebuild, and it went back to the developers.
What made it hard
An extension with its own login invites every account state: no business yet, onboarding half done, a different session on the site than in the extension. Each one looks like “it’s broken” to the member.
Options
Handle each state inside the extension, or send each one to the platform, where it already has an answer, and give the panel one screen that says why.
Two ways to answer, and no choice about method
Situation
Members wanted the assistant to fill a whole page at once, and also to answer one stubborn question carefully.
Decision
Both stay available until the application is marked submitted: start with “Autofill all” and fix one answer, or go one by one and autofill the next page. Answers sit in cards with a manual edit, “Rewrite with AI”, and a bookmark to reuse them.
The method disappears: “Vision” runs in the background, “Try again” is the only retry, and while it scans, a full-panel “We’re scanning, please wait” stops accidental clicks.
The answer loop
Two ways in, one loop
Autofill all
One by one
Switch at any time
01 Generate
An answer from the profile
02 Review
The member reads it
03 Edit or rewrite
By hand, or with a prompt
04 Next
The next question or page
Back to Generate, question after question
Mark as submitted
The only way out of the loop, and only the member can take it.
The two buttons at the top are doors, not modes: whichever one a member uses, they end up in the same loop.
Gate 2 of 6 · Outcome
Kept
The loop, generate, review, edit, next, became the product. There’s no usage data, so I can’t say which way in people preferred.
What made it hard
Offering both can feel like a mode you lock into. And early builds showed the method itself: two buttons, “Autofill” and “Vision”, and a “Try again” that asked whether to retry or scan with AI vision. Testers hesitated at both.
Options
One mode; two modes picked at the start; or two modes the member can swap between at any time.
Only show what it can finish
Situation
The extension suggests opportunities. The platform’s list mixes eligible and ineligible programs, programs hosted on Happly, and external forms the assistant can’t read well.
Decision
Show only opportunities that are eligible and ready for the assistant. Say “Not eligible”, never “0% match”. Give the two routes two names: programs hosted on Happly use One-Click Apply, external ones use the extension. And when matching can’t run because the profile is missing required answers, show “Complete your profile”, not an empty list.
What the list may show
Demo opportunities
Opportunity A
External form · eligible · ready for the assistant
Apply now
Opportunity B
External form · eligible · not ready for the assistant
Not shown
Opportunity C
Not eligible
Not eligible
Never “0% match”
Program D
Hosted on Happly
One-Click Apply
On the platform, not here
Any list
Profile missing required answers
Complete your profile
Replaces the whole list
Read the tags as a promise: only the cases with an action are ones the member can finish.
Gate 3 of 6 · Outcome
Still in QA
The API side, defaulting to ready opportunities and naming the missing profile fields when matching can’t run, was in place by February 2026. The front-end states were still in QA in May 2026.
What made it hard
A list that offers things the tool can’t complete spends the member’s trust. A “0% match” badge reads as a score, not as “you don’t qualify”. And a member has to know whether a card means “apply here” or “use the extension”.
Options
Mirror the platform list; filter quietly; or filter on purpose and say what each state means.
A guest on someone else’s page
Situation
The extension opens beside any website. In March 2026 a reviewer opened it and found it black: their browser was in dark mode.
Decision
Light only for version one, to be revisited, and a set of manners: the panel belongs to its tab, like other browser assistants; progress stays until the member presses “Done”; edits sync both ways with the original form; only questions that exist on the form are listed; upload fields aren’t answered as text; and typing // in an answer box opens a menu of saved answers.
Found in QA, and the rule it became
From the 2026 QA notes
Behaved like an app
Behaves like a guest
Stayed open across every tab
Belongs to the tab it was opened in
Reset progress when a tab was switched
Keeps progress until the member presses “Done”
Toasts spanned the whole panel
Toasts sit inside the area they relate to
An edit changed its own copy, not the form
Edits sync both ways with the form
Turned black in a dark-mode browser
Light only, for version one
None of the left column is about AI. Most of what QA found was the extension forgetting it was a visitor.
Gate 4 of 6 · Outcome
Set as QA rules
These were written as QA expectations for the rebuild in 2026, the list each new build was checked against.
What made it hard
The member’s page, browser theme, window width, open tabs and half-finished work are all outside the design. QA kept finding the extension behaving like an app when it should behave like a visitor.
Options
Build a dark version now; force light and defer; or set the guest’s manners first.
When the allowance runs out mid-application
Situation
The requirements gave each member a free monthly allowance of AI answers and applications. Running out half way through a form was always going to happen to someone.
Decision
I designed a soft stop. At the first limit, a prompt offered a one-time bonus for writing a store review, with a reminder at most once a day until it was used. After that, the member could still browse the other tabs, but had to wait for the reset, or upgrade, to start a new application.
The allowance, as designed
Limits not shown
In allowance
Answers generate as usual.
First limit
A one-time bonus, offered for writing a store review.
Dropped
After that
Browse the other tabs; wait for the reset, or upgrade, to start a new application.
The dashed tag marks the step that was dropped: the bonus asked for a review in return, and that’s the part a store won’t allow.
Gate 5 of 6 · Outcome
Dropped
I designed this flow, but it conflicted with the store policy on reviews for rewards, so it was dropped.
What made it hard
It’s the worst moment to ask for money, and the rules were moving: in February 2026 the team wanted to simplify the credit logic and offer an upgrade instead of a second application.
Options
A hard stop with an upgrade prompt; a soft stop with a one-time bonus; or no limit.
The AI acts, the person approves
Situation
In September 2026 the company lead asked for the next version: instead of detecting fields one by one, the extension reads the page like a person would, and clicks, selects and fills, the way browser agents do.
Decision
A review at every step, and I designed its two screens. When profile information is missing, the agent pauses and asks: “We aren’t sure about this one. Could you give us a little bit more information in order to complete this form?”, then resumes with the answer.
Before every “Next”, a verification view shows everything it filled on that page and waits for approval, page by page. Nothing is submitted without an explicit yes. The capability goes into the existing interface rather than a new one.
Page by page
Concept, Sep 2026 · schematic
Page 1
Approved
Page 2
Waiting for you
Page 3
Not started
Page 4
Not started
Page 2 · what was filled
Company name
What the project will do
Number of employees
A question the profile can’t answer
Paused · asked
Approve and continue
Nothing is submitted without a yes
One page at a time: the agent fills, stops at the edge of the page, and the member’s approval is the only way to the next one.
The pause screen, from the Figma file (to come)
The page verification view, from the Figma file (to come)
The two screens I designed for the agent version; real frames to come.
Gate 6 of 6 · Outcome
In review
A pull request for this behavior was under review in September 2026. No release, no result yet. It’s the rule Happly uses everywhere: the AI advises, a person decides.
What made it hard
An assistant that can click can also submit. And its mistakes land in a stranger’s database, under a member’s name.
Options
Full automation with an undo; automation with one review at the end; or a review at every step.
Under the panel
Smaller rules that hold the screens together.
The profile is the source of truth
The extension edits nothing the platform owns. “Edit profile” opens the platform, and the panel re-reads the profile each time it opens.
A percentage is a hint
The readiness figure is a plain share of answered onboarding questions, all weighted equally. Nothing in it predicts a good answer, so it stays a hint and never becomes a gate.
Business plan first
An uploaded plan is the best context the assistant can have. With neither an upload nor a plan built on Happly, a box sends the member to the Business Plan Builder.
State copy over spinners
“Not eligible”, “Complete your profile”, “We’re scanning”, “Add your business”: each one names what’s happening and what to do.
Motion from the system
The AI’s waiting state is an animation from the design system’s own set, not a generic spinner.
The landing page
In September 2026 I designed the hero and its motion for a GrantGPT landing page.
GrantGPT landing-page hero (to come)
The landing-page hero; the real frame and its motion to come.
What I’d redesign first
The review-for-credits flow. I designed this flow, but it conflicted with the store policy on reviews for rewards, so it was dropped.
The problem it tried to solve is still open: what a member sees when the allowance runs out half way through a form. I’d start by showing what’s left before a member begins an application, so the limit never arrives as a surprise.
What I learned
Sit lightly on someone else’s page.
Most of the QA was about manners, tabs, themes and sync, not about AI.
Don’t show the method.
“Autofill or Vision?” is the system’s question, not the member’s.
Filter on purpose.
A shorter list that finishes beats a longer one that doesn’t.
An agent needs gates.
The design of an AI that acts is the design of its pauses.
What I’d measure if it ships: how many installs reach a first filled page; how many generated answers are kept, edited, rewritten or deleted; and how often the agent pauses to ask, and how those pauses end.