Home / Berkeleytime

Reducing Friction in the Design-to-Dev Handoff

Over years of rapid feature releases, unstandardized UI patterns and inconsistent designer-to-dev handoffs led to a fragmented user experience, duplicated work, and growing friction between design and engineering. To address these challenges, our team set out to build our first design system and bridge the handoff workflow from the ground up.

Team

2 Engineer

3 Designers

1 Design Lead

Skills

User Research

Frontend

Design Systems

Tools

Figma

Storybook

VS Code

Claude Code

My Contribution

Built our foundational design system in Figma with a team, then, as the lead designer this year, translating it into a token-based system connecting Figma to code via Storybook.

At a Glance

A scalable design-to-dev workflow built to reduce friction and ensure UI consistency.

70,000+ Files

Audited to establish a baseline of design token adoption across frontend files

48+ Components

built on Radix UI, establishing a 1:1 token structure between Figma and React

1157+ Hardcoded Values

… to none across color palette, padding, gap, border-radius, and shadow

From Hardcoded Styles to a Scalable Token System

We applied our token architecture to Berkeleytime’s most heavily-visited Grades Distribution page, replacing hardcoded charts with token-backed Radix components for a more consistent, accessible, and responsive experience.

Before: A Grades page built with hardcoded CSS, inconsistent spacing, and non-WCAG-compliant color contrast.

Inconsistent component rendering, a broken A+ bar, mismatched card styles, and an oversized tooltip, all symptoms of miscommunication between engineers and designers working without a single SOT.

After: Standardized Grades & Analytics interface powered by 48+ Radix-mapped tokens, crisp chart semantics, and built-in theme support.

Unified data visualization components, consistent card hierarchy, and a cohesive interaction language across different states (active and inactive), shipped using our component library and actively being built in Storybook.

The Problem

Without a single source of truth for design tokens and components, developer productivity slowed and UI consistency declined.

Good Samaritan Shelter provides 350+ social services across Santa Barbara County, but vulnerable residents had no unified way to find them. Scattered sites, broken links, and mobile-unfriendly pages left people without a clear path to help. That gap inspired the creation of OpenDoor.

Good Samaritan Shelter's existing site was irresponsive on mobile, required constant internet access, and buried critical resources behind confusing navigation. For 5,000+ residents in Santa. Has received recognition by The Rookies, IDA Awards, and Indigo Awards.

Good Samaritan Shelter's existing site was irresponsive on mobile, required constant internet access, and buried critical resources behind confusing navigation. For 5,000+ residents in Santa. Has received recognition by The Rookies, IDA Awards, and Indigo Awards.

The User Experience: Fragmented UI Patterns

Students encountered mismatched component variants (like the 3 course cards shown below) across different pages, degrading trust on Berkeleytime’s primary course discovery tool.

User Research

Our core user on average had to spend 20+ min searching 4+ sites to find a single relevant service.

Through 13 stakeholder interviews and surveys with 50+ program participants, two patterns surfaced consistently. Users were spending time searching across 4+ fragmented, outdated sites just to find one relevant service, and when they arrived, critical information like eligibility requirements, walk-in hours, and what to bring was either buried or missing entirely.

48%

Reported a wasted trip due to missing or unclear eligibility information

87%

Rely solely on mobile devices for internet access through the help of the lifeline program

"Many links look broken or are outdated. Who do I even trust? Let me just Google something, anything that can help." — Anonymized interviewee

User Journey Mapping

Users struggle to navigate fragmented support resources, outdated information, and identify a clear path to help.

Journey mapping from realization to action highlighted challenges in locating support. Users often navigated multiple disconnected resources, encountered outdated information, and lacked clear confirmation that they had reached the appropriate service.

Journey mapping from realization to action highlighted challenges in locating support. Users often navigated multiple disconnected resources, encountered outdated information, and lacked clear confirmation that they had reached the appropriate service.

TLDR; Mapping the user journey revealed a key insight: the lowest emotional point isn’t the crisis itself, but the search for help. Users arrive with urgency and often leave more overwhelmed due to fragmented resources and unclear next steps.

Competitive Analysis

Current solutions fail to serve vulnerable populations with local, contextual needs.

Existing tools like 2-1-1 or FindHelp either cater to generic audiences or suffer from complex, non-mobile-friendly navigation. OpenDoor fills the gap as an easy-to-use, localized platform tailored specifically for individuals in crisis.

Product Differentiation

Our Bet: Leveraging conversational AI to reduce staff burden and personalize support.

To maximize impact with limited resources, we categorized potential features into a impact/effort matrix. We prioritized AI search and offline access as critical "Big Bets," while cutting low-value friction like forced account creation.

Our Goal

Transform fragmented shelter data into an AI-assisted mobile experience that cuts search time to under 5 minutes with upfront eligibility and clear next steps.

Defining the Visual Identity

Defining a minimal and clean visual identity.

OpenDoor's visual identity centers on trust and ease. Warm tones, high-contrast type, and WCAG-AA accessible color pairings ensure the app feels approachable for users navigating stressful situations rather than sterile or overwhelming.

Key Design Decisions

Evaluating design tradeoffs to find the most intuitive path for users in high-stress situations.

Every iteration balanced user needs, technical constraints, and real-world conditions. Rather than focusing on aesthetics alone, final decisions were guided by usability testing with caseworkers and unhoused residents.

Filter-First Layout

Has a map/list view toggle (visual search vs. list search)

High cognitive load (i.e wall of controls/filters)

Organized by Categories

Establishes a clear, predictable navigation path

No primary actions like "Call" or "Directions"

Guided-Discovery Layout

Users can discover services through categories or browse "Services Near You"

Users can easily scan the name, status and primary actions

Expanded Card Pop-Up

Caseworkers noted that important details are buried

Groups key information into logical, collapsible sections

Single-Column Details Page

Has a full page view for expanded service details

Still is hard to scan for our users

Easy-to-Scan Details Page

Builds users' trust with an entrance photo, confirming the location is safe to approach.

Uses progressive disclosure by hiding secondary info

Pre-Filtered Smart Search

Users think "Type of Help" UI is complex and unclear

Relevant filters like sort by "Distance" and "Type of Help"

Integrated Search

No complicate pre-search filter barrier

Accidental conflicting touch targets for many users

The service card competes with the search dropdown

Conversational AI Search

Separates search into its own view

Uses progressive disclosure by hiding secondary info

Positions AI as a conversational path to an answer

Before Versus After

Transforming a complex web directory into an intuitive mobile experience.

For more than 5,000 people in Santa Barbara County, finding housing and shelter resources is frustrating and time-consuming

Before: Services buried under charity copy with no clear entry points

Focuses on donation promotion rather than immediate service access

Overwhelming list of categories with no filtering or hierarchy

No way to see service status, distance, or availability at a glance

After: Scannable categories and immediate access to nearby services

Users can discover services through categories or browse "Services Near You"

Users can easily scan the name, the service' status and primary actions

Before: Dense wall of text missing upfront eligibility, hours, or directions

High cognitive load (i.e wall of controls/filters)

No primary action

After: Clear, progressive disclosure showing operating hours, with multiple direct CTAs

Highly scannable cards

Builds users' trust with an entrance photo, confirming the location is safe to approach

Before: Static search requiring manual reading of long service descriptions

Dense paragraph text is hard to scan quickly

No eligibility info, hours, or accessibility details visible

After: Conversational AI that guides users directly to answers

Separates search into its own view

Provides three distinct search paths (Keyword, Category, AI)

Final Prototype

Over the course of 8 weeks, we designed 10+ screens, 26+ components, built for Android and iOS.

Outcome & Impact

Reimagining housing search with conversational AI: from local community impact to national recognition.

Key Highlights

→ AI Innovation: Selected for the 2025 Harvard Applied AI Grid Incubator & backed by AWS.

→ Recognition: $10k Grand Prize Winner (Oxford Rhodes Innovation Challenge) & Xfund $100k Finalist.

→ Traction: 20+ partner orgs approved pilot programs across Santa Barbara, the Bay Area, and Boston.

$10k

2025 Grand Prize Winner (Oxford Rhodes)

92%

Of surveyed participants would use OpenDoor if deployed

20+

Partner orgs expanding pilots across the Bay Area and Boston

Winning the Kevin Xu Innovation Challenge ($10k+ in Awards)

Reflection

From problem ambiguity to decisive product bets and shipped experiences.

Early on, I focused heavily on information architecture. But talking with caseworkers made me realize users needed upfront visual proof, like entrance photos and live bed availability, to feel safe approaching a shelter. Trust is an accessibility requirement.

Without strict requirements or a single "standard" user persona, waiting for perfect data would have stalled us. Learning to make opinionated, hypothesis-driven bets allowed us to put real prototypes in front of residents faster.

Explore More Work