ACCESSHRA Case Study

2025 UX Case Study

New York City’s Human Resources Administration (HRA) ACCESSHRA mobile app processes applications for benefit programs including the Supplemental Nutrition Assistance Program (SNAP) for low-income New Yorkers and people with disabilities. While there is an overwhelming need for food assistance, many low income New Yorkers have a hard time navigating the application process, often due to language barriers and limited accessible technology, that requires in-person assistance to complete forms and notices.

Target Audience

U.S. Citizens
People who live in New York State
18 years or older
Have experienced being unemployed or experiencing unemployment

ACCESSHRA Website

Research

I interviewed 10+ people of different ages to understand their current user flow navigating the online SNAP application process. All users were all asked questions related to their unemployment experience, disabilities, language barriers, and project management.

These questions included:

Tell me about the last time you were unemployed or had your hours reduced.
During that time, did you need access to affordable food and groceries for yourself?
If so, how would you research affordable food and groceries?
If you purchase food online, what apps do you use? And why?
Do you have a disability?
What is your primary language?
Have you applied for unemployment for SNAP (food stamps) benefits before, and if so, what was your experience like?
Have you assisted anyone applying for unemployment or SNAP benefit before, and if so, what was your experience like?
When you encounter a term in the application you do not understand, how do you look for information?
Have you ever needed in-person assistance from a family member, close friend, loved one, or a social worker for forms and notices?
What apps do you use to keep track of tasks? Have you ever missed a recertification deadline?

I also gave all users a small assignment, where they were asked to annotate the current “Factors of Eligibility” document to learn how users organize their documents.

I also asked users the following questions:

Are there any categories of eligibility that you think should remain its own category or be combined?
How many categories do you think you can supply your own documents without connecting a third party?
How many categories do you think you would need to connect a third party?
What terms and categories do you find to be clear or unclear? Then, circle the categories and terms you may find to be unclear.

Overcoming Language Barriers

For non-English speaking users, I worked together with a translator to translate questions and delivered the documents in their native language (i.e. if a user’s primary language was Spanish, I conducted the interview in Spanish and gave them the official documents in their native language).

Note: Unlike the current website, the current mobile app does not have translation features integrated into their system.

Current ACCESSHRA Mobile App

Current Factors of Eligibility used to determine if an individual qualifies for assistance for food

Insight

I learned the ACCESSHRA app also encompasses other programs outside of SNAP including Medicaid and reduced Metrocard programs and they all require the same documents to apply. However, users pointed out that:

You cannot keep your documents saved
You have to resubmit the same files

One user described the app as a scavenger hunt when looking for documents. They had a meltdown forgetting to recertify their unemployment benefits and reduced Metrocard fare application because they needed to put their attention to paying rent.

Another user also pointed out the “Factors of Eligibility” and the mobile app gave them a headache because the text was too close together and lack of spacing made it hard to read. This user also has dyslexia, so their reading disability enhanced the headache experience.

Due to outside stressors whether it be unemployment, homelessness, mental health, or illness, users can be forgetful and need reminders to complete time sensitive forms. They found the app to be overwhelming and lost track of their application progress (the UI design feels like an afterthought),
and it feels cold and bureaucratic compared to the old system which involved social workers and translators.

Common Issues

After conducting my user interviews, I reviewed my notes and grouped together observations made by users concerning the app and alternatives they used for food assistance.

I found that:

The app uses repetitive language and lacks distinctive hierachy
It is not inclusive to non-English speaking audiences which is not reflective of the diversity of NYC
The app does not have reminder notifications built into the app despite the time sensitive nature of the application process
You cannot preview documents and track your progress
There is a lack connection between the website experience and the mobile app experience
The overall SNAP application process has changed since the mid 2010s and 1990s, so there is new terminology that older users may not be familiar with

Affinity Diagramming

Personas

Since the ACCESSHRA app used by New Yorkers of all backgrounds, my personas reflect the diversity of the city.

Persona 1

Persona 2

Improving Information Infrastructure & User Flow

There are 17 main categories of eligibility users must complete to be considered for all benefits programs. This does not include the subcategories and documents needed to complete the application.

Users felt overwhelmed by the number of categories and felt many of the categories can be grouped together by like topics.

Sketching

When I creating sketches of the average user’s flow I noticed the Documents section in the mobile app experience felt overwhelming because all 17 categories would be displayed on one page. Users would be asked to submit their files all on the same page, and some documents would need to be reuploaded, although they were already submitted to fulfill another category.

For instance, one user wrote, “Age and identity could probably be combined.” They required the same documentation, but ACCESSHRA treats the two as separate categories.

Some users annotated like categories by color coding. For instance, this user grouped “Identity” factors in yellow, “Residence” factors in pink, and “Social Security” remained its own category in green.

Others emailed me notes about the groupings, and I used the information to condense the number of eligibility factors.

In the mobile app experience, the user would complete all 17 categories on the same page.

User Flow Initial Sketch

I circled the documents category because I noticed it was the largest cluster in the user flow and had too many tasks being performed on one single page.

User Annotations

Categories of Eligibility

I created 6 main categories: Idenity, Disability, Residence, Medical, Income, and Dependent.

Followed by subcategories and they include:

Identity – Age, Household Size, Social Security, Citizenship, Immigration Status, School Attendance
Residence – Utility Expenses, Referral
Income – Earned Income, Unearned Income, and Resources
Disability
Medical –Medical Bills, Health Insurance
Dependant

Original Categories of Eligibility without Organization

In the mobile app experience, the user would complete all 17 categories on the same page.

Original Categories of Eligibility with Organization

Low Fidelity Sketches & Feedback

After reorganizing the information, I presented to the same users a prototype that included multilingual translation features and progress tracking.

Users found the prototype’s typography to be cleaner and the app’s features were simpler to use than the original app. They appreciated the inclusion of multilingual translation, as people pointed out that they were surprised the original app did not consider non-English speaking New Yorkers. They felt encouraged and they felt could complete the application with less stress.

Branding

For the high fidelity version, I wanted to unify the website and mobile app experience, using colors, iconography, and typography from the ACCESSHRA site. I used Noto Sans because the typeface is inclusive of multiple languages.

In the onboarding mockup, I included the languages present from the original website: English, Spanish, Arabic, Urdu, Mandarin, Korean, Haitian Creole, and Russian.

Onoboarding

Multilingual Typeface Exploration

High Fidelity Mockup

Reflections

In the next iteration, I will focus on Content Design and Writing. I would like the user to understand the language of the application in an accessible way that does not use complex language. I would also like to explore redesigning the web experience, so the two feel like a unified piece. Overall, I learned alot about refined Typography and Multilingual Typography.

View in Figma

Brigitte Ugarte