Designing for
people first.

The problem

Young adults who want to positively impact their communities lack a centralized way to find local resources or stay aware of issues — from food insecurity to policy changes. Over 50% of young people say they rarely connect with others in their community in person, directly reducing civic participation.

Key decisions

As lead web developer, I built the team site and drove UX research: user interviews, affinity diagramming, and two rounds of usability testing. We redesigned the “organize” feature after testing revealed it was too confusing — participants hesitated between action buttons, showing pathways weren’t immediately obvious. We focused subsequent iterations on clearer feedback and progressive disclosure.

What I learned

Heuristic evaluation and usability testing surfaced different but complementary issues — together they gave a fuller picture than either method alone. Designing for civic engagement also taught me that trust is a UX problem: users need to feel confident in information accuracy before they’ll take action.

The problem

New engineers on the Liquids team struggled to understand the rocket's architecture. Onboarding was slow, documentation was scattered, and institutional knowledge lived in people's heads.

Key decisions

I chose an interactive, visual-first approach over static docs. Each component links to context, specs, and related parts — so engineers can explore non-linearly the way they actually think.

What I learned

Designing for engineers meant respecting precision — every label, hierarchy choice, and flow had to be defensible. The best UX here was invisible: it just worked like the user expected.

The problem

Most sleep apps are bloated. Users abandon them because logging feels like a chore. The challenge: make the core loop (log → view → reflect) feel effortless enough to sustain daily use.

Key decisions

I prioritized clear information hierarchy and readable components over feature density. Local storage meant no login wall — users could start immediately and revisit data without friction.

What I learned

Accessibility isn't a bolt-on. Designing for legibility and contrast from the start made the app better for everyone — not just users with visual needs. Simplicity is the hardest constraint to honor.

The problem

Google Docs was built for adults. For children ≤12, the interface is overwhelming — too many options, no visual affordances, and language that assumes prior knowledge of document editing.

Key decisions

As UX lead, I pushed for keeping core functionality intact but wrapping it in age-appropriate affordances — larger tap targets, iconography over text labels, and a progressive toolbar.

What I learned

Designing for children is humbling. They don't read instructions — they explore. That forced me to think about discoverability, forgiveness (easy undo), and delight as core UX pillars, not extras.