United Way 211 App

The Challenge

What's the best way to help someone when they're already in a crisis? United Way of Buffalo and Erie County's answer has been 211, the number people call when they need help with food, rent or a utility shutoff. They've helped about 108,000 people across Western New York in just over two years. United Way's 211 call center was over capacity, and the 211 website wasn't built for phones, so they wanted a self-serve experience to make sure more people got access to help while also lowering the barrier for people who are already in a tough place. The person opening this app is often hungry, facing eviction or about to have their utilities shut off, and they're usually on an older budget Android phone with spotty data. That set the table stakes: it had to get someone help fast, use an approachable reading level and be bilingual from the start. United Way came in with a muddy picture of what they wanted, which amounted basically to a digital Yellow Pages. A directory is the right idea, but for someone struggling to feed their family this week, working out what to type into a search box can take more mental bandwidth than tapping Food.

The Solution

In my first week on the project I wrote down the question that became the thesis statement for the app: how can we help a person in crisis? A UX strategist had done the initial research before I started and to immerse myself in the project I took what he had and deepened it. The competitor analysis grew from 4 apps to 16 across related industries and I pulled United Way's 211 Community Dashboard, which logged nearly 190,000 calls between January 2024 and March 2026, to see what people actually call about.

From there I built the design system, the wireframes and then a fully working prototype in Expo (a toolkit for building React Native apps for iOS and Android) with Bolt, running on mock data. That prototype was the moment United Way could finally hold what they'd been describing, and when I walked them through it in April the first reaction was "This looks really good so far."

Key Decisions & Rationale

• Anything in the way of the critical path of help should be removed. Other 211 apps tend to put a login in front of their information, and someone in crisis is more likely to give up or just call than to make an account, so ours has no login. The same went for an onboarding with language, permissions and transportation settings. Everything is asked for when it's needed and not before. You open the app to the six category tiles and the search bar.
• Someone who's already stressed shouldn't feel like the app is shouting at them. I used Antonio, a condensed display font, in all caps only for short labels. The main prompt, "How can we help?", is in Palanquin and in sentence case.* The copy follows the same idea: it borrows the plain voice of United Way's 211 website and aims to be literal and straightforward.
• Borrow from the apps people already know how to use. While other 211 apps exist, they have their own usability issues. The core job to be done is "help me find X near me" which is squarely in the wheelhouse of Uber, DoorDash, Zillow, and Google Maps. Throughout this process I was intentional in what I was borrowing. All of those apps are profit motivated, so it's important to differentiate what constraints drive the experience.
• Categorize with simple options. I used affinity diagramming, a classic UX tool for grouping related things, to strike the balance of verbosity and disclosure. My goal was to pick a number that had a low cognitive load (5-7 is a normal figure for working memory and 6 worked well on a phone) and to find the right categories for all of the needs. I folded 8 of the dashboard's 16 categories into Housing, Food, Transportation, Tax Help, Health and Legal, which cover 80% of the call demand. Everything else is one search away.

What We're Watching

The app just launched, so feedback is still being collected. We're looking at all the choices we made along the way including category usage, map versus list, searches, and click-to-call, and we'll use the data to drive future iteration.

• Tiles versus search. If people tap a tile far more often than they search, the six tiles are doing their job.
• Map versus list. Internal stakeholders were conflicted on how useful each view was, and data will help us prioritize the screen space each receives.
• Reaching help. Every call, set of directions and website visit from a resource page counts, because that's someone who found help without waiting on the 211 line.

Reflection

I wasn't the first designer on this project, and while initially there was some pressure to crank out designs, the work I did to verify and expand the research paid off. For example when United Way asked how the six categories were chosen, I could show them exactly how their own data mapped to each tile. As AI shortens development cycles it's tempting to feel behind and need to feed the machine, but it doesn't help us to go fast in the wrong direction. Clarity around the problem and understanding the user is always valuable work that will only become more important with time.

Addendum: Type in React Native

* The type took more craft than it looks. React Native has no text-box-trim, the CSS property that trims a line of text down to its letters, so the line box decides where text sits, and line height is the wrong tool for lining things up. Palanquin makes that worse: it was designed for Devanagari, the script used for Hindi, so the empty headroom above its capital letters is 64% of the font's size. I measured the font's real metrics with fonttools, found that iOS and Android compute identical line boxes, and built an AlignedText component on Capsize, a library that trims text to its cap height.

The first version went too far. The trim works with negative margins, and on stacked lines they ate the gaps until the lines overlapped, shrank touch targets and focus rings, and clipped under overflow: hidden. So the rule became: trim single labels like buttons, pills and headers, and never stacked body text. I proved it with an alignment demo screen with a red centerline overlay, screenshotted on iOS and Android with Maestro, then moved 25 text elements across 8 files over to it. The production app's design doc still keeps the rule, trimming text "rather than line-height hacks."