Case study 04 HHS / Health Resources and Services Administration
HRSA Grant Application Redesign
Sixteen prototypes, one deadline, and a form with ninety pieces inside it.
- Client
- Health Resources and Services Administration, Bureau of Primary Health Care
- Role
- Senior UI/UX Designer
- Platform
- Salesforce, with a custom applicant and reviewer experience
- Timeline
- 2019–2021
Overview
A grant application with a hard deadline and ninety pieces inside one form.
Community health centers apply to HRSA for the funding that keeps their doors open. The application runs through fifteen program-specific forms, and it has a hard deadline. Most applicants are small organizations without a grant-writing department, so the person filling this in is usually a clinic administrator doing it alongside their actual job.
The system they were using had grown for two decades. HRSA funded a modernization of it, and the client asked for something specific: build it on Salesforce, but do not just accept whatever Salesforce gives you by default. Serve the applicants, and stay inside what the platform can actually do.
That is the whole design problem in one sentence. Two sets of habits, one belonging to the platform and one belonging to people who had been using the old system every year for a decade, and a budget that only stretched to fighting the platform in a few places.
I prototyped it in Axure at full fidelity, produced sixteen documented variants across three screens, and argued each decision from a comparison rather than from a preference. The most useful thing I learned was that a pattern which works well on one form can become punishing on another, and the only way to find that out is to build it at the real volume before anyone agrees to it.
A note on what is shown
The screens in this case study are my own prototypes, built with placeholder organization names and test data. No real applicant information appears anywhere.
Where the work sits
The redesign starts 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 program forms, validation, and program review.
Grants.gov
The applicant submits the federal package.
Association
The handbook system imports it and links it to the organization and opportunity.
Program forms
The applicant completes program-specific forms, attachments, budgets, sites, and contacts.
Validation
Forms move toward Complete. Validation flags missing or inconsistent data, then an authorized official submits.
Program review
Agency staff run eligibility and pre-funding review, and may ask for corrections.
Grants processing
Business and budget review, funding recommendations, and award.
Official record
Data and documents flow to downstream systems and the official grant file.
Out of scope
Owned by other systems and other teams.
The redesign scope
Stages three, four, and five. 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 a boundary. They experience one long task that starts on a federal site and ends somewhere they cannot see.
An applicant does not experience this as one system. They start on Grants.gov, submitting the standard federal package. That submission gets imported and associated with their organization. Then they arrive in the handbook environment and complete the program-specific part, which is where the real work is: forms, attachments, budgets, service sites, contacts, performance measures. The system validates as they go. An authorized official submits. Agency staff review it for completeness and eligibility, and may send it back for corrections. Eventually it becomes an award and an official record.
The redesign covered the middle of that: the forms, the validation, and the reviewer queue on the other side. Naming that boundary early was worth the hour it took. It kept the team from designing things that belonged to other systems, and it made one thing obvious that had not been obvious before. Applicants do not perceive a boundary at all. They perceive one long task that begins on a federal website and ends somewhere they cannot see. Every point where an applicant crossed into or out of our section was a place the design had to say plainly what had just happened and what came next.
The problem
The first problem is volume.
The shape of the work
Fifteen forms, and one of them is eighteen forms.
Fifteen form categories lead to Clinical Performance Measures, which contains eighteen measures with five sections each, or ninety pieces of work.
What the applicant sees
General information
Budget information
Sites and services
Other forms
Performance measures
Other
What is inside one of them
18 required measures
- Diabetes: HbA1c poor control
- Screening for depression
- Depression remission at 12 months
- Weight assessment, children
- Body mass index screening
- Controlling high blood pressure
- ...twelve more measures
Baseline data
Year, numerator, denominator, calculated baseline
Goals
Projected goal and a target goal description
Data source and methodology
Source selection plus a 500 character methodology
Key factors
At least one contributing and one restricting factor, each with a planned action
Review and complete
Check the whole measure and mark it done
Ninety separate pieces of work inside one row of the form list.
The design consequence
A structure that reads well for a four-section form can become unusable when it is multiplied eighteen times.
Fifteen forms, grouped into six categories. That is visible from the overview page. It is daunting but comprehensible.
The part that is not visible is what sits inside them. Clinical Performance Measures is one row in that list of fifteen. Open it and there are eighteen required measures, covering diabetes control, depression screening, prenatal care, cancer screenings, immunisations and more. Every one of those eighteen carries the same five sections: baseline data, goals, data source and methodology, key factors with planned actions, and a review step.
Eighteen times five is ninety. Ninety separate pieces of work, inside one row, for someone who still has fourteen other forms to finish and a deadline counting down in the corner of the screen.
That number shaped more of this project than any opinion about layout.
A structure that reads well for a four-section form can become unusable when it gets multiplied eighteen times, and you cannot see that happening if you prototype with three example rows and an ellipsis.
The second problem
Whose habits win?
Two sets of conventions
The platform had habits. So did the users.
Five comparisons between Salesforce conventions and applicant habits, showing which side won or where both patterns were kept.
App launcher and console tabs
Open records as closeable tabs across the top, the way a caseworker keeps several files open at once.
One application at a time, with breadcrumbs back to the grant. Applicants work one grant, not a queue.
Applicants are not power users of this system. They visit it once a year under deadline.
Left navigation
A collapsible record panel listing sibling records with status.
A persistent form rail showing all fifteen forms and their status, always visible.
The platform pattern was kept, but loaded with the handbook’s information: every form, always, with status.
Status vocabulary
Generic record states.
Not Started, In Progress, Complete. The three words the program already used in policy and guidance.
Renaming a state that appears in official guidance creates a support burden for no design gain.
Section styling
Standard card headers.
Filled teal section bands, which is how the handbook signaled a new part of a long form.
This is the cheapest possible win. It costs nothing to build and removes a moment of disorientation.
Save behavior
Save and Save & Continue on every record page.
Return to List, Save, Save & Continue, plus Previous Form and Next Form.
Platform buttons kept, then extended with the sequential movement a fifteen-form task actually needs.
The principle underneath
Adopt the platform wherever the user has no opinion, and spend the customization budget only where the user already has a habit worth protecting.
Salesforce Lightning has strong opinions about how an application should behave. It wants an app launcher. It wants records opened as closeable tabs across the top. It has its own status vocabulary, its own card styling, and its own button placement. All of that comes free and is cheap to build.
The applicants had different habits. They had been using the handbook system for years, once a year, under deadline. They knew what a teal section band meant. They knew the words Not Started, In Progress, and Complete, because those words appear in HRSA’s own published guidance. They expected a rail down the left listing every form they owed.
The temptation with a low-code platform is to take everything it offers, because that is the cheap path. The opposite temptation is to rebuild the old system pixel for pixel, which fights the platform on every screen and burns the budget on things nobody notices.
I worked through it case by case. The principle I settled on: adopt the platform wherever the user has no opinion, and spend the customization budget only where the user already has a habit worth protecting. Some examples of how that landed.
-
Console tabs lost
Salesforce wants you to open several records as tabs, the way a caseworker keeps multiple files open. That is right for a caseworker. It is wrong for an applicant, who is working on exactly one grant application and visits this system once a year. I built the tabbed version to be sure, and looking at it made the answer obvious. It offers power to someone who does not want power, and it costs them orientation.
-
The left rail was a compromise
Salesforce’s collapsible record panel was kept, because it behaves well and it was free. What went into it was the handbook’s information rather than the platform’s: all fifteen forms, always listed, each with its status. The container is the platform’s. The contents are the users’.
-
Status vocabulary was not negotiable
Not Started, In Progress, and Complete appear in HRSA’s own guidance documents. Renaming them to match generic platform states would have created a support burden and gained nothing.
-
Section styling was the cheapest win
Filled teal bands marking each section of a long form is how the old system signaled where you were. It costs nothing to reproduce and it removes a moment of disorientation on every form. There was no reason not to.
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 engineering actually needed.
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 roles that touch an application on its way to an award. There are about ten of those roles, from the applicant and the authorizing official through project officers, quality control staff, grants management specialists, and grants management officers. 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 budget document 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 actually 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: what does “how much is left” actually mean?
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. The reason is that they answer the question the applicant is actually asking. They are not asking for a measurement. They are asking what work is left and where to 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.
Structure: how to divide a long form?
Structure inside a form
Seven layouts for one form, asking one question each.
Three structures for a four-section form compared: one long page, a labeled chevron stepper, and a minimal dot stepper. The long page was chosen for long forms and the labeled stepper kept for short forms.
The answer was not one structure
Short forms with a natural sequence got the labeled stepper. Long forms with independent sections got the single page.
Form 1A has four sections and roughly forty fields. Three structures got built.
One long page with filled section bands keeps everything visible, scannable, and answerable out of order. You can do the easy fields first and come back. It prints and reviews properly, which matters when several people at a health center check a draft before submission. The cost is that it looks like a wall on first arrival.
A labeled chevron stepper naming all four steps across the top makes the length predictable instead of a surprise, and each step becomes a small finishable unit. The cost is a click between every section and the loss of out-of-order answering.
A minimal dot stepper is the same four steps reduced to unlabeled dots. I built this one and it taught me something by failing. It is quieter and takes less vertical space, but removing the labels removes the only thing the stepper was doing. If the steps are not named, the applicant cannot see what is coming, and it stops working as navigation and as a progress indicator at the same time. Rejected.
The answer was not one structure for everything. Short forms with a natural sequence got the labeled stepper. Long forms with independent sections got the single page. Applying one pattern to all fifteen would have been more consistent and worse, because the forms are not the same shape as each other.
The deepest screen: where a good pattern turned bad.
The deepest screen
Where a good pattern turned into a bad one.
Comparison of a five-step wizard inside each of eighteen measures with one page for each measure and the list always visible. The wizard creates ninety screens and the single-page treatment creates eighteen.
Stepper inside each measure
The same five-step pattern applied inside every one of eighteen measures.
90 screens to reach one CompleteNot recommendedOne page for each measure
All five sections on a single scrolling page, with the eighteen measures as a list on the left.
18 pages, and the list stays visibleChosen directionWhy the pattern did not transfer
Repetition changes the maths
A five-step wizard is reasonable once. It is punishment when the applicant must do it eighteen times, because the shape was learned by the second measure.
The measures are not independent
Applicants set goals for one measure by looking at a related one. A wizard hides the neighbors, so comparison becomes a navigation task.
Progress belonged across measures, not inside one
The useful question is which of the eighteen are still empty. A wizard answers where you are inside the one you happen to have open.
The transferable lesson
A pattern is not good or bad on its own. It is good or bad at a volume.
The stepper worked on Form 1A. So the obvious move was to use it inside Clinical Performance Measures, where each measure has five sections. I built that version.
Eighteen measures times five steps is ninety screens to reach one Complete.
Repetition changes the maths. A five-step wizard is a reasonable way to walk someone through something once. It is a punishment when they have to do it eighteen times, because the applicant has learned the shape by the second measure and every later step is friction with no teaching value left in it.
The measures are not independent. Applicants set a goal for one measure by looking at what they set for a related one. A wizard hides the neighbors, so a comparison that should take a glance becomes a navigation task.
Progress belonged across the measures, not inside one. The useful question is which of the eighteen are still empty. A wizard answers a much less useful question, which is where you are inside the one you happen to have open.
A pattern is not good or bad by itself. It is good or bad at a volume.
The version that shipped puts all eighteen measures in a list on the left and opens the current one as a single page on the right. Eighteen pages instead of ninety screens, and the list of what is left never goes away. The only way to find out which structure works is to build it at the real volume before agreeing to it.
Outcomes
Designed to implementation-ready detail, without claiming a measured improvement.
I want to be precise here, because this is a long federal program and it is easy to write a sentence that claims more than it should.
What the design work produced
- A complete set of high-fidelity Axure prototypes covering the applicant experience across all fifteen forms, including the deepest screen at its real depth
- Sixteen documented variants across three screens, each built to answer a specific question rather than to offer an alternative style
- A resolved position on where Salesforce conventions should be adopted and where applicants’ existing expectations should be protected, with the reasoning recorded so later teams would not have to relitigate it
- Interaction and accessibility specifications detailed enough to build from, covering conditional display, validation timing, autosave, and the behavior of in-progress work when reference data changes
- An internal approval and review experience alongside the applicant one, covering queues, routing, approvals, and role-based visibility
What I cannot claim
- No usability testing was run against these prototypes, so nothing here is validated with applicants
- No production analytics were instrumented, so there is no measured change in completion time, error rate, or abandonment
- Public procurement records confirm HRSA funded a GAAM modernization initiative. They do not publicly attribute specific deliverables to individual designers, and I do not claim otherwise
- Program-wide statistics for the wider handbook environment belong to that program and are not results of this redesign
The defensible statement is that the applicant experience was designed to implementation-ready detail and the platform question was resolved with reasoning that held up. Not that a measured improvement was achieved.
Attribution
This was a long modernization program delivered by a large team across engineering, data, product, and program staff, and parts of the underlying system predate my involvement entirely.
What is mine in this account: the applicant-experience prototypes and the variants behind them, the platform-versus-expectation decisions and the reasoning recorded for them, the progress and structure decisions described above, and the interaction and accessibility specifications handed to engineering.
The system, the program, and its outcomes belong to HRSA and to the team that built it.
The single-page structure was chosen on reasoning rather than tested against the wizard with applicants.