Case study 04 Health Resources and Services Administration (HRSA)
HRSA Grant Application Redesign
Fifteen forms due on the same day, and one of them nearly took ninety screens to finish.
- Client
- Health Resources and Services Administration (HRSA)
- Role
- UX designer, grant application experience
- Platform
- Salesforce, Axure
- Timeframe
- 2019–2021
Overview
A form clinic staff had to get through once a year, without help.
HRSA’s Health Center Program funds clinics that serve people with nowhere else to go: rural counties, migrant communities, people without insurance. Every year, those clinics reapply for the money that keeps them open through a Salesforce-built system called GAAM, the Grants Application and Attachment Module, sitting inside HRSA’s Electronic Handbooks.
GAAM is not one form. It is fifteen: general information, staffing, service sites, board member characteristics, and one form, Clinical Performance Measures, that alone asks for eighteen separate measures of patient outcomes. Each measure needs its own baseline, goal, data source and methodology, and key factors.
Most of the people filling this out are not grant writers. They are clinic staff doing this on top of their actual jobs, against a federal deadline, on a system carrying decades of HRSA handbook habits layered onto Salesforce’s own defaults. Get it wrong and the application does not just look sloppy. It gets delayed, and the money a clinic needs to keep serving patients gets held up with it.
I designed the applicant experience across all fifteen forms, and the internal review workflow behind it: how HRSA’s own staff route, check, and approve what comes in.
The part of the process I actually touched
The redesign started in the middle of a seven-stage federal grant process.
Scope
Where the redesign starts and stops.
Seven-stage grant process from Grants.gov to the official record. GAAM covers the EHB intake handoff, program forms, validation, and program review.
Grants.gov submission
An organization submits the federal package.
EHB intake
The package enters HRSA’s Electronic Handbooks and is matched to the applicant.
Application forms
Clinic staff complete fifteen program-specific forms.
Validation and certification
The application is checked, completed, and certified by an Authorizing Official.
HRSA review
Agency staff review the package and request corrections when needed.
Funding recommendation
The application moves through grants processing toward an award.
Award record
The decision becomes part of the official grant record.
Out of scope
Owned by other systems and other teams.
The redesign scope
Stages two through five. The handoff into EHBs, everything an applicant fills in, everything the system checks, and the queue an agency reviewer works from.
Why the boundary mattered
Applicants do not experience separate systems. They experience one long task across multiple systems, from the federal handoff through HRSA review.
The application’s life is longer than the part I designed. It starts on Grants.gov, where an organization submits into the federal system. It ends with a funding decision and an official award record. My scope sat in the middle: the moment a package lands inside HRSA’s Electronic Handbooks, gets matched to the right applicant, and turns into fifteen forms that need filling out, validating, and certifying before an Authorizing Official can send them on to HRSA for review.
Even inside that middle stretch, the interface had to account for both ends of a chain it did not control. It needed to explain what had just arrived from Grants.gov without applicants needing to understand the handoff, and it needed to give HRSA’s reviewers a package they could act on the moment it landed in their queue.
Eight jobs, one application
None of them see the same version of it.
On the applicant side, four different jobs touch the same package. Someone coordinates the whole application and tracks what is left. Several people supply the actual data: staffing numbers, service sites, patient outcomes. A project director owns the programmatic content. An Authorizing Official has to certify the whole thing and put their name on it before it goes anywhere.
On HRSA’s side, that same application becomes a queue item for a program reviewer checking eligibility, a quality control pass checking completeness, a grants specialist checking budget and administrative requirements, and a grants officer supporting the funding recommendation.
Role ecosystem
One grant, with eight different views.
The same application changes what people can see, edit, route, certify, or approve according to their role and its current status.
Two groups of four roles, applicant organization on the left and HRSA review and grants on the right, connect into one shared application record in the middle. The shared record holds its status, validation, permissions, and history.
Applicant organization
- Application coordinatorAssembles forms and tracks status
- Data contributorsSupply sites, budget, and outcomes data
- Project directorOwns programmatic content
- Authorizing OfficialCertifies and submits
Shared system
One application record
- Status + validation
- Permissions + history
HRSA review and grants
- Program reviewerAssesses content and eligibility
- Quality controlChecks completeness
- Grants specialistReviews budget and administrative requirements
- Grants officerSupports the funding recommendation
Role visibility is part of the interaction design: what someone can see, edit, route, certify, or approve changes by role and by where the application sits in its life.
What any one of those eight people can see or edit depends on their role, and on exactly where the application sits in its life. That was not a permissions screen bolted onto the forms afterward. It was part of the interaction design from the start.
To keep three of the highest-stakes roles concrete while designing, I worked through what each one actually needed and what got in the way of it, based on their documented responsibilities rather than on interviews I didn’t run.
Role tensions
Three high-stakes roles, three different definitions of ready.
A working design tool used to make the needs and barriers of the people around one application concrete.
Three role cards: an application coordinator needs a status that leads to the next task but must track fifteen forms against a deadline; an Authorizing Official needs a readiness summary but can miss a blocking issue hidden behind a completion count; a program reviewer needs a queue that surfaces today’s actions but sees an application differently from other roles.
Application coordinator
Needs
A status that leads to the next task, not just a percentage.
Authorizing Official
Needs
A readiness summary, not every field re-reviewed from scratch.
Program reviewer
Needs
A queue that surfaces today’s required actions.
Reasoned from each role’s documented responsibilities and the shape of the actual forms, not from interviews.
The applicant’s side
The deadline from the applicant’s side.
Walking through the six stages between the package landing in EHBs and it reaching HRSA for review made one thing clear: the low point comes at validation, when someone has done the work and still cannot tell what is stopping them from finishing it. The next two decisions address that moment directly.
Applicant journey
The moment validation turns completed work into uncertainty.
Six stages between the package landing in EHBs and it reaching HRSA for review.
A six-stage applicant journey: Handoff, Orient, Complete, Validate, Approve, and Respond. The emotional arc moves from uncertain to concerned to focused, drops to frustrated at Validate, then recovers to cautiously confident at Approve before ending urgent at Respond.
-
01
Handoff
What just arrived from Grants.gov?
-
02
Orient
What remains, and who owns it?
-
03
Complete
Can I finish this section now?
-
04
Validate
What exactly is blocking completion?
-
05
Approve
Is the package ready to submit?
-
06
Respond
What changed, and where?
Emotional arc
The emotional low point is validation: the applicant has done the work but may still lack a clear path to finishing it.
The problem
The form that broke the pattern I had just proven.
The shape of the work
Fifteen forms, and one of them is eighteen forms.
The application contains fifteen program-specific forms, including Clinical Performance Measures with eighteen patient-outcome measures and four sections per measure: Baseline Data, Goals, Data Source and Methodology, and Key Factors.
One shared application
One application, many shapes
Most forms are short enough for a page, a sequence, or tabs. Clinical Performance Measures is the outlier: one form that repeats the same work eighteen times.
-
Application set
General informationStaffingService sites -
Program detail
Board member characteristicsClinical Performance Measures -
One shared deadline
15 forms1 application
Inside Clinical Performance Measures
One repeated structure, multiplied by eighteen.
The volume
18 measures
- 01–18Patient-outcome measures repeated through the form
- × 5The same five steps inside every measure
- = 90Screens in the rejected step-by-step version
- 01
Baseline data
The current state of the measure
- 02
Goals
The target the clinic plans to reach
- 03
Data Source & Methodology
Where the numbers come from and how the clinic calculated and interpreted them
- 04
Key factors
What helps or restricts progress, and what to do next
The step-by-step version turned repeated measure work into ninety screens.
The design consequence
A structure that reads well for a four-section form can become unusable when it is multiplied eighteen times.
Most of the other fourteen forms fit neatly into a page, a short step-by-step flow, or a set of tabs, depending on whether their fields had a natural order or stood alone. Clinical Performance Measures does not fit any of those, because it is not really one form. It is eighteen forms’ worth of the same fields, repeated once per measure.
I built it as a step-by-step wizard first, the same pattern that worked cleanly on shorter forms elsewhere in the application. Eighteen measures times five steps is ninety screens between a start and one Complete state. A pattern that works cleanly at the scale of one form can fall apart entirely at the scale of eighteen repeated ones, and this one did.
The pattern failed for three related reasons. Repetition changed the maths: the applicant had learned the shape by the second measure, so every later step added friction without teaching anything new. The measures were not independent, so comparing a goal with a related measure became a navigation task when the wizard hid the neighboring work. And progress belonged across the measures, because the useful question was which of the eighteen were still empty, not where someone was inside the one they happened to have open.
Eighteen measures times five steps is ninety screens to reach one Complete state.
I rebuilt it as a persistent list instead: every measure visible down the side, one page of fields on the right, and the list of what is left never disappearing while you work. Ninety screens became eighteen pages. The wizard file is still sitting in the prototype set, dated earlier than the version that shipped, which is the closest thing I have to proof that I built the wrong thing first and caught it before it went to development.
Conventions
Keep the platform where it earned the default, and protect the habits where it had not.
Design rationale
Where platform conventions met user expectations
Three design decisions balanced Salesforce defaults with familiar EHBs behavior.
A three-row comparison of Salesforce defaults, existing user expectations, and the resulting GAAM design decision for application navigation, status language, and section structure.
| Design area | Salesforce default | Existing user expectation | GAAM design decision |
|---|---|---|---|
| Application navigation | Records open in closeable console tabs so several cases can remain active. | Applicants work in one grant at a time and use breadcrumbs to return. | USER-LED Use a focused application flow with breadcrumbs. |
| Status language | Generic record states describe the underlying platform. | Not Started, In Progress, and Complete match program guidance. | USER-LED Preserve the familiar program terms. |
| Section structure | Standard card headers divide content. | Teal section bands signal a new part of a long form. | USER-LED Keep the familiar section bands. |
GAAM runs on Salesforce, and Salesforce comes with its own opinions: a waffle-style app launcher, closeable console tabs, and Lightning’s default components. None of the people filling out this form had any attachment to how the app launcher behaved, so there was no reason to fight the platform there.
But those same people had spent years inside HRSA’s Electronic Handbooks, and EHBs came with its own vocabulary already baked into their expectations: teal section bands, a status of Not Started, In Progress, or Complete, and an Authorizing Official who reviews and certifies. I kept those, even where Salesforce’s own defaults pointed somewhere else, because changing a label a returning coordinator has read every year for a decade is not simplification. It is one more thing to relearn under deadline.
The same rule ran through the language. Acronyms like AO and PAR stayed, because HRSA staff already live inside them, but a first-time coordinator got the full term spelled out at least once. Denser shorthand like MUA, MUP, and UDS got expanded on first use instead of assumed. And because this was a federal application, accessibility could not be an afterthought: status never relied on color alone, and every required field and error message stayed tied to its label, so the form still made sense read aloud.
I built both versions where the two systems disagreed, the Salesforce-default screen and the EHBs-familiar one, and picked per case instead of committing to one system’s conventions across the board.
Adopt the platform wherever the user has no opinion, and protect the habits that help them finish.
The design process
Prototype first, argue from artifacts, decide in front of the people who own the outcome.
Design process
How the work moved, and what each phase produced.
Six-phase design process: understand the existing system, map the domain and roles, prototype at real fidelity, run variants side by side, decide with stakeholders, and specify and hand off.
Understand the existing system
Walked the legacy application end to end as an applicant would, then again as a reviewer.
Current-state walkthrough and inherited-pattern listMap the domain and the roles
Fifteen forms, their groupings, validation rules, and the roles that touch an application on its way to an award.
Form inventory, role map, validation modelPrototype in Axure, at real fidelity
Built working prototypes with real form content, real field labels, and real volumes rather than placeholder text.
High-fidelity interactive prototypesRun the variants side by side
Seven layouts for Form 1A, six for the forms overview, and three for Clinical Performance Measures.
Sixteen documented variantsDecide with stakeholders in the room
Walked variants through review with program staff and engineering together, deciding from applicant needs and platform constraints.
Agreed patterns and a record of what was rejectedSpecify and hand off
Interaction specifications, accessibility requirements, and field-level behavior required by engineering.
Build-ready specificationsThe rule the process ran on
Never bring one option to a review. Two or three options that each answer the same question differently force a conversation about the users.
I started by using the existing system rather than reading about it. All the way through, as an applicant would, then again from the reviewer’s side. The point was not to build a list of complaints. It was to find what already worked, because a modernization that throws away familiar behavior costs users more than it gains them, and the pressure on a project like this always runs toward changing more than necessary.
Then I mapped the domain and the roles. Fifteen forms, how they group, the validation rules that run between them, and the eight roles that touch an application on its way to an award. Four roles work for the applicant and four work for HRSA. Roles matter more than usual here because what any screen shows depends entirely on who is looking at it. The same application record is a task list to one person, a review queue item to another, and a funding recommendation to a third.
I prototyped in Axure at real fidelity. Real form content, real field labels, and real volumes. Not placeholder text and not three sample rows. This is the discipline that made the rest of the process work, and it is the one most often skipped because it is slow. A prototype with placeholder content will tell you a layout is fine. The same layout with forty real fields and eighteen real measures tells you the truth.
I built the variants side by side. Seven layouts for Form 1A, six for the forms overview, and three for Clinical Performance Measures. Each variant answered one specific question rather than expressing a different taste, which is what made comparing them produce a decision instead of an argument.
I never brought one option to a review. This is the rule the whole process ran on. A single design invites approval or rejection, and that conversation is about whether people like it. Two or three options that each answer the same question differently force a conversation about the applicants, and the client walks out owning the decision rather than having consented to mine. On a program where I would not be there forever, that mattered more than being right.
Then I specified it properly. Interaction specifications, accessibility requirements, and the field-level behavior engineering needed: conditional display, when validation fires, how autosave confirms itself, and what happens to work in progress when a reference value changes underneath it. That last one is the sort of thing that never appears in a mockup and always appears in production.
Three decisions
The useful answer changed with the volume of the work.
Progress: how much work is left?
Progress
Three ways to answer “how much is left,” and only one of them does.
Three progress treatments compared: percentage ring, two progress bars, and status counters. Status counters were chosen because they show what work is left and where to start.
What decided it
The applicant is not asking a question about measurement. They are asking what work is left and where to start.
Three treatments got built. A percentage ring showing one figure for the whole application looks authoritative. It is close to useless. A percentage cannot be acted on, and worse, it actively misleads when the forms differ enormously in size. Fourteen short forms and one enormous one do not average into a meaningful number.
Two progress bars, one for the overall application and one for the program-specific section, are better because they stop pretending there is one obligation when there are two. Still, they say nothing about what to do next.
Three status counters across the top are what shipped: Not Started, In Progress, and Complete. They answer the applicant’s question: what work is left, and where should I start? Counters answer both, because each number corresponds to a real, filterable group of forms. The number doubles as a route into the work behind it.
The counters use the program’s own vocabulary, which means the numbers on screen match the language in the guidance document sitting open next to the applicant.
The overview itself was redesigned from a checklist into a routing surface: due date and days remaining at the top, forms grouped by section, counts for Not Started, In Progress, and Complete, and direct navigation into any unfinished form. A percentage complete would have been simpler to build and would have told a coordinator nothing useful. A list that routes straight to unfinished work is useful immediately.
Structure: how to divide a long form?
Form 1A structure testing
Three tested structures for Form 1A.
Three structures tested against the real Form 1A content: a labeled sequence, an alternative single-page shell, and a persistent list. The structure depends on the form’s actual volume and sequence.
The answer was not one structure
Each structure was tested against the real content volume. Form 1A could stay compact; Clinical Performance Measures needed the persistent list.
The stepper worked on Form 1A: its labeled sequence moved through Applicant Information, Proposed Service Area, Patients and Visits, and Review & Complete. I tested that structure alongside an alternative shell and a persistent-list treatment against the real content volume.
The structures were tested against real content rather than placeholder fields. A structure that holds up with three sample fields can still fall apart when the actual form volume arrives. The answer was not one structure for everything: a labeled sequence helped where fields had a natural order, while the persistent list belonged to Clinical Performance Measures, where applicants needed to compare repeated measures rather than follow one linear path.
What shipped
Fifteen forms specified for the applicant side, with the review workflow behind them.
By the end, all fifteen applicant forms had interaction and validation specifications detailed enough to hand to engineering directly: conditional display, validation timing, autosave behavior, and what a form looks like mid-progress versus complete. The internal review side got the same level of detail: queues, routing, correction requests, and role-based visibility for HRSA’s own staff.
Sixteen documented interface variants came out of the process along the way: seven for Form 1A, six for the overview screen, and three for Clinical Performance Measures. Each one was built to answer a real question rather than to look thorough.
The system runs today because of the full team at REI Systems and HRSA who built GAAM and have kept it running long after I moved on to other work. What I designed sits inside that larger system: the applicant experience across all fifteen forms, the decisions about where to follow Salesforce’s conventions and where to protect the habits EHBs users already had, and the interaction and accessibility specifications that went to engineering.
There was no usability study built into the project timeline, so the case for the persistent list over the wizard rests on the math, ninety screens against eighteen, and my own repeated walkthroughs, not a measured task time.