Designing a grant management and processing system for the Administration of Community Living (ACL)

TLDR - Before we dive in, I'll draw a parallel to a more reknowned scenario - this will help you understand the business challenge for this project. Think of online tax filing, you have physical paper forms with many drawbacks - the biggest being delaying your returns (because, snail mail). Then you've got state tax-filing websites, which do not offer the best UX, are slow and even errorneous at times. And then you've got the fluid, seamless, end-to-end online tax filing software like Turbotax and HR Block that makes your tax filing and tracking stress-free.

Well, the client here, had a system similar to state tax-filing websites and I was tasked with building a new Turbotax-like experience for them. And guess what? - I was successful!

Problem Statement


Folks at The Administration of Community Living (ACL), part of The Department of Health and Human Services (HHS) were using a fractured, unintuitive grant submission system that peeved their users. The system was non-preemptive, disjointed and inconsistent in many places which led to applicants' (grantees) and reviewers' (ACL staff) being out of sync and delayed the grant funding process.

As UX Architect at ICF Next, I had the opportunity to help ACL build a grant submission and management system for Title VIA grant program that provides nutrition and supportive services to Native Americans (American Indian, Alaska Native and Native Hawaiian). We called this system OAAPS Older Americans Act Performance System.

The Team


  • 1 UX Architect
  • 8 software developers (4 full-stack, 1-front-end, 1 back-end, 2 testers)
  • 1 SCRUM Master
  • 1 Solution Architect
  • 1 Project Manager

Research and Requirement Gathering


The research phase involved attending a conference that walked us through the current process ACL had for grant management and its shortcomings. It also described ACL's vision for Title VI.

For next steps, I set up conf-calls with Regional Office, Central Office staff and Grantees the users of this system to understand their frustrations from the current system and what their vision of the perfect system looks like.

We also asked questions that helped us understand these personas better what a day in the life of this person look like? how do they currently coorodinate with each other? and so on.

Understanding our users


User Personas






The personas shown above represent (left to right) Grantee/Tribal users (person receiving the grants), the ACL Regional Office staff and ACL Central Office Staff (people reviewing the grants). The challenge here is that most Grantee users are not too tech-savvy and use only basic software applications Also, many reside in places with intermittent internet connectivity and we needed to build a system that accomodated for such users. So here are the steps we took to address these user needs:

Minimizing the learning the curve for less-tech-savvy users

  • Incorporate only basic interactions throughout the system - Click (Primary), Pan and Zoom (Secondary)
  • Use simple language and less procedural jargon
  • No motion, complex animations - use of only show/hide functions and modals


Making things consistent
While we started working on Title VI, my company had already rolled out submission systems for ACL's other titles - III and VII and they were currently under development, so it was also about maintaining consistancy across all titles for design patterns, components, language, voice and tone.

Remodelling the Grant Submission Process


We used the '5 whys' approach to understand the problem and learnt the root cause of the problem was not the tools nor the software, or even the way these people worked. It was the way the process was structured. Once this was validated through interviews, I immediately got working on remodeling the same.

Current Process


Current process

  • Non-preemptive
  • Disjointed Systems for every step
  • Relies on steady internet connection
  • No notification and verification mechanism
  • No reporting
  • No updates, Needs installation, No SSO
Proposed process


New process

  • Preemptive
  • One holistic and consistent experience for all titles
  • Protetion against unreliable internet connection
  • Aggragated reporting and analysis module
  • Over-the-air updates, No installation, SSO enabled


The remodelled ACL journey (click to enlarge)


Remodelled journey

Product Development


The Agile process (click to enlarge)


The Agile process

My team followed a 3-week Agile SCRUM-based framework. We had daily stand-ups, weekly check-ins with the client, story point estimation meetings, weekly demos with the team and monthly sprint demos with the client. My responsibilites as a designer cum BA involved:

  • Driving weekly client meetings
  • Writing tickets for developers with functionality and design specs.
  • Scheduling and driving usability tests
  • Communicating client feedback with development team and developer feedback/concerns to clients.


Information Architecture


I did open and closed card sorting in the second round of participant feedback sessions to design the information architecture for the application we were planning to build.

System statuses

Product Workflows


Now that I had a new remodelled process in place that had been vetted, reviewed and fine-tuned by our clients, we could safely move to translating the process to a product workflow that would dictate the dynamics of the new application being designed.

System statuses

The Design


I used Sketch, Axure and HTML/CSS for designing. The wireframes are protected under NDA. Let's get on a call to discuss this.

homepage wireframe

Mapping the submission form


Grantees who have received funding from ACL in the previous year have to submit a Program Performance Report (PPR) that records information like served meals, number of trips, caregiver data as proof of expenses and services provided through the grants. We had to start by first mapping the physical PPR to and online PPR.

This also meant employing adequate data validation and error handling to make sure the numbers that users would enter made sense.

Mapping the paper form to online(click to enlarge)


Mapping the paper form to online


Designing dashboards

The dashboards show where the user's application is in the process and who is working on it. They also reel in resources from ACL like important dates, system updates and grantee contact liaisons within the state. This was a common ask across interviews I did with the grantees.

Designing the dashboard(click to enlarge)
Designing the dashboard


Managing Users

ACL staff manage grantee and staff accounts. From interview feedback, I clearly sensed the need to integrate this functionality in ACL OAAPS's complete end-to-end grant submission experience. This feature enabled ACL staff to create new staff accounts, assign them to grantees, determine access privileges and establish relationships between them.

User creation and management(click to enlarge)
User creation and management


Results and Learnings


homepage wireframe

Designing for users in low connectivity areas:

  • Cache data on every page at a pathway level. Reduce number of API calls as much as possible.

  • Bucket content as primary and secondary. Load primary content that would add most value for the user, load secondary content only if requested by user. This results is the system only fetching content that's important. For example, if the user is supposed to have access to only some videos based on their permissions, instead of loading all videos and showing them as locked, only load videos they have access to and replace others with a 'Locked' message.

  • Load static content, dynamic content, media - in that order

  • Choose pagination over continuous scrolling

Designing for users who are less tech-educated:

  • Keep actions limited to Click, Pan and Zoom as most users are familiar with these actions.

  • Limit transitions to just show() and hide, avoid advanced animations or transitions - they might overwhelm users.

  • Only show as much data as requested, hide secondary content and load only when requested by user - too much data might overwhlem users.

×