An end-to-end mobile resource hub for essential community services across Santa Barbara County — designed for urgency, unreliable connectivity, and real-world stress.
The Brief.
Good Samaritan Shelter provides emergency housing, recovery programs, and long-term support across Santa Barbara County — a region known for affluence that has faced persistent homelessness for decades.
I joined a cross-functional pod of seven designers to create Good Help: a mobile app that consolidates 55 scattered programs into a single, discoverable, stress-aware experience — one that works with or without internet and supports time-sensitive decisions.
I owned the service discovery architecture and led the tracks within it: accessibility, offline behavior, and map feasibility.
The help was there.
It just wasn't in one place.
Good Samaritan Shelter runs dozens of programs across the county, but reaching the right one, checking program availability, or finding help in a crisis meant navigating service information that was never in one place.
Many people never learned the full range of services GSS offers; programs existed that the people who needed them couldn't see.
Time-sensitive changes, shelter availability, and program updates weren't reaching people quickly enough to act on.
With no shared structure, what someone found depended on where they happened to look, not on what they actually needed.
Research designed
to do no harm.
Direct interviews with unhoused individuals were intentionally avoided as introducing research during a crisis risks harm, coercion, and emotional burden. The constraint shaped the method, not the depth.
GSS clients are often navigating housing instability, recovery, or crisis. Instead, we reviewed paper surveys collected by the GSS website team and interviewed shelter employees as proxy users — staff who help clients locate services every day. Real workflows, zero added burden.
Research surfaced four patterns that shaped every decision that followed:
Access to shelter is consistently the first priority. The fastest path to housing-related programs had to anchor the entire discovery experience.
Many individuals lack consistent internet access. Anything critical had to survive a dead connection; offline wasn't an edge case.
Most existing tools assume confident, fluent users. Every screen had to work for someone using it for the first time, under stress.
Step-by-step direction matters more than open-ended browsing when locating resources. The flow had to lead, not just list.
Six features scoped.
One core to get right.
Research and client requirements defined a six-feature MVP. Most of them depend on one thing working first — that a person can actually find the service they need.
The team's focus: making 55 programs findable.
Service Finder was the heart of the product — the feature the other five lean on. Three of us designed it together, covering browse, search, and map discovery across Santa Barbara County.
A three-designer feature.
55 programs that
refused to sit in a tidy tree.
I owned the discovery structure — translating a messy Excel dataset of 55 programs into a navigable system. The hard part wasn't the levels. It was that real programs don't each have one clean home.
The clean answer — county-level discovery down to a single program:
One program, many homes.
A program that offers several services has to appear under every one of them — reached from any path, but always the same single record.
One example of many — across 55 programs, cross-listing was the rule, not the exception.
Surfaces under every service it offers — from one source record, never a duplicate.
Handles uneven depth — some paths run four levels, some honestly say "no services yet."
Scales past 55 — new programs slot into the hierarchy with no redesign.
Iterating toward clarity.
Three phases — from structure-first sketches to a refined interaction system, with friction surfaced and fixed before visual polish.
All three phases show the same step — choosing a department — so you can watch one pattern move from raw structure to a finished, standardized component.
Low-fidelity layout with placeholder rows, no color, and no real icons — proving the structure and navigation held up before any polish.
Real chrome, content, and icons arrive, and tap zones get tuned — but the icons stay mono and the label ("Select Type of Help") is still jargon.
The finished pattern: plain instruction ("Choose a department"), tint-fill category icons, locked type, and clear tap targets — built once, reused everywhere.
Tested with
the people who help.
Mid-fidelity prototypes were validated with GSS employees as proxy users via Figma and UserTesting.com — grounding feedback in real service-delivery workflows.
Validated with staff who route these services daily, never people in active crisis. The constraint shaped the method, not the depth.
Some users couldn't tell how the two views related.
Strengthened the visual affordances linking list and map.
Staff knew exactly what order helps someone qualify fast.
Reordered service content: services → eligibility → description → steps.
In urgent moments, calling beats navigating.
Made Call the primary CTA, with Directions alongside.
Users wanted to know what would survive a lost connection.
Clarified offline messaging across cached and empty states.
One page, re-sequenced for faster decisions.
It competed with evaluating the resource the user had just opened.
Call sat in a horizontal scroll, equal-weighted with everything else.
Services and contact details sat far down the page, slowing decisions.
Focus stays on the selected service — nothing competes with the decision.
Call leads with Directions alongside; Bookmark, Download, and Share drop to a "Save it" row.
Services → eligibility → description → steps — the order that qualifies someone fastest.
Every decision
assumed urgency.
Four decisions I owned, each shaped by the same question: does this still work for someone stressed, rushed, and possibly offline?
Comfortable taps on small screens, even in dense layouts.
Visual compactness preserved, no oversized UI.
Consistent interaction behavior across navigation and actions.
Annotation overlay for the case study — not the shipped UI.
Cached services — previously viewed programs stay browsable in list and map.
Cached search — recent searches remain available offline.
No cache — first-time users get a clear state explaining limits.
Map controls and overlays styled to the GSS color, spacing, and type system.
Map pins open the app's own service card — not Google's default info window.
Engineering effort saved for the discovery experience itself.
Help you
can actually find.
The final Service Finder prototype — the architecture, accessibility patterns, and offline behaviors working together. Four flows, shown in motion.
Designed for real scale.
Currently in development with Good Samaritan Shelter — the work below is what the design is built to deliver once live.
The population this app is built to serve — improving access to shelter and essential programs countywide.
Previously scattered services, now restructured into a single discovery system people can actually search.
Built for urgent decisions on unreliable connections — cached services, cached search, and a clear fallback.
"We asked the team to create something that didn't exist anywhere. With the blueprints they created, I'm confident our app builder can quickly turn the vision into a working reality."
What this project
taught me.
Structuring 55 programs meant balancing discoverability, hierarchy, and cross-listed services — architecture that grows without breaking.
Clear navigation, large targets, and fast access to information outrank visual density when someone is deciding under stress.
Connectivity can't be assumed. Cached data strategies and honest empty states are design work, not engineering afterthoughts.
Proposals got stronger through the design manager, stakeholders, and the pod — user-centered and technically feasible, together.
