Gen Z isn't allergic
to touching grass.
They just don't know it's there.
How might we make Yerba Buena Gardens a place 18-25 year olds actively seek out, not just stumble upon?
How might we make Yerba Buena Gardens a place 18-25 year olds actively seek out, not just stumble upon?
Yerba Buena Gardens sits in the middle of SoMa, next to Metreon and a cluster of museums, and the age group it needs most has no reason to know it exists. There's no social proof and poor presence on TikTok, the channel Gen Z actually uses to find things to do in SF.
So I designed a companion app that makes the Gardens discoverable and worth coming back to.
I interviewed the staff and the visitors they want to reach, built a working MVP in Lovable and Cursor, tested it twice, and fixed what each round found. YBG's IT team is taking it to launch.
Main concept, at a glance
“That's the one group we've never figured out the magic pill for, at seven different parks and recreation departments, seven different cities.”
Executive Director, YBGThe Gardens aren't invisible because they're boring. They have no digital footprint in the one place this age group actually looks. I interviewed the people who run the Gardens and the people they want to reach to find the gap.
“I don't think people are going on our website to look things up. People go on social media to look things up.”
Special Projects Manager, YBG“There's a reason to come here. They just don't know.”
Special Projects Manager, YBG
Affinity map, synthesized from interviews
Marketing is still print-first: flyers passed through neighborhood organizations, which skews older.
Non-visitors never went because none of their friends do, so there's no reason to be first.
Every non-visitor named TikTok as their default source for "free things to do," not YBG's website or Google.
One has never set foot in the Gardens. The other visits but doesn't know its name.
Maya Hernandez · 20
Key insightHas never visited. With no social proof from her friends, YBG doesn't register as a place worth going.
Josh Richardson · 20s
Key insightVisits regularly and likes it, but never knew its name because of the poor digital footprint.
Physical spaces are seasonal, have no digital layer, or price Gen Z out. Event apps have the social layer but aren't tied to a place.
| Space / App | Free to Access | Digital Discovery Layer | Year-Round | Built-in Incentive |
|---|---|---|---|---|
| YBGC App (Planned) | Yes | Creator feed + QR + web | Yes | Badges → real rewards |
| SFMOMA | $30–40 | Owned channels only | Yes | None |
| Dolores Park | Yes | None | Yes | None |
| Stern Grove | Yes–Lottery | None | Seasonal | None |
| Partiful / Posh | Yes | Yes | Yes | Not destination-tied |
| Luma | Yes | Tech-event skewed | Yes | Not destination-tied |
Creator Feed
A TikTok-style feed of visitor and creator content, so discovery happens in a format Gen Z already trusts.
Vertical endless scroll: the lowest-friction way to keep watching.
RSVP
Event RSVPs that show who's going, lowering the social risk of showing up alone, which came up repeatedly in interviews.
Map + Badges
A consolidated map of hidden gems and amenities, with badges earned by exploring and redeemable for real rewards like free bowling.
Badges unlock as you explore, not through a fixed points system, so there’s a reason to come back.
Nudges
SMS and push notifications in a Gen-Z voice, turning a one-time visit into a repeat habit.
In testing, event notifications were one of the top reasons participants said they’d reopen the app.
HOVER (OR TAP) OVER THE SCREENS TO SEE THE FLOW IN MOTION
Creator feed
Event RSVP
Consolidated Map
Badge & reward
SMS nudge
Based on where research said 18–25 year olds already look.
A QR code on an art piece or flyer opens the app, so someone curious in the Gardens can install it on the spot.
People already visit YBG's website, so a Gen-Z-voiced accent-colored button and banner that prompts them to download the app.
Creators who already post about YBG, plus TikTok ads, on the channel every non-visitor named. Video shown is an edited example.
Interview data clustered into four HMW statements, each tested against sticky-note feature brainstorming before any screen was drawn.
I printed each competitor app and annotated every screen by hand.
Early sketches moved into mid-fidelity wireframes, then into a visual system built inside a real constraint: YBG's own brand guidelines.
Wireframe sketches - Discovery + Short-form videos
Wireframe sketches - Events + Badge-earning
The visual system had to work within YBG's existing brand, so it leans on their approved system, pushed just far enough to feel native to a feed.
Design system, color & type, within YBG's brand
Micro-animations make progress feel rewarding, and a worm mascot keeps the app personable rather than transactional.
Moderated usability testing with 5 participants on the first prototype surfaced four issues before the design reached a high-fidelity build.
The badge flow had poor hierarchy or labels. Users couldn't tell which badge to collect, how to earn one, or how badges connected to the map.
Added color and micro-animations to make progress and next steps legible, and tied badge-earning to the map so the two flows connected.
The option to post a video to the creator feed wasn't clear. Users didn't realize they could contribute content, only consume it.
Added a fixed feature CTA to the feed and added an occasional get featured ad while scrolling, the ad frequency changes.
An accessibility list-view was added for the map, but in testing it felt confusing due to many buttons and it competed with the main map view instead of supporting it.
Replaced the two competing buttons with a single Map/List toggle, so the accessible list supports the map instead of competing with it. The list view still needs its own usability pass.
Also fixed: the events icon and calendar view looked too alike, so I differentiated the icon set.
These fixes went into the high-fidelity build tested in round two. The badge flow was still the weakest task there, so I redesigned it again afterward (see Results).
Six participants completed five core tasks on the high-fidelity prototype, measured on success rate, time on task, and error count, plus an A/B test on the RSVP confirm gesture and a System Usability Scale survey.
| Task | Success (0 - 1) | Avg. Time | Avg. Errors | Ease (1–7) |
|---|---|---|---|---|
| Onboarding / download | 83.3% | 32.5s | 0.67 | 5.58 |
| RSVP to an event | 91.7% | 31.7s | 0.17 | 5.83 |
| Discover via explore feed | 100% | 35s | 0 | 6.0 |
| Earn a badge | 53.3% | 76.7s | 1.83 | 4.67 |
| Explore the map | 95.8% | 100s | 0.83 | 5.17 |
After round two I redesigned the badge flow again and showed it to 3 coworkers, not the original testers. They found it easier to follow, but this was an informal check with no metrics.
Asked what would make them reopen the app, half of participants pointed to upcoming events first.
Near the 68-point average-usability benchmark, from a 4-participant SUS survey.
“I didn't want to truly explore.”, flagged as a note on map engagement.
Round-two testing participantLovable and Cursor got this from Figma to a working, testable app fast. But a prototype isn’t a production system. YBGC’s IT team, who already run the live website, is taking it from here to make it secure for real users. The beta includes the fixes from both rounds of testing. The round-two changes haven't been re-tested with users yet.
Figma prototypes fake state. Code has to remember it. Building in Lovable and Cursor meant the app had to work like real software, and small bugs that survived two rounds of testing showed up as soon as I could actually use it.
Figma file, local styles & auto layout
Handing a file to Lovable and Cursor is unforgiving: nothing carries over automatically. So I built proper text and color styles and auto layout across every screen, so engineering could build from it as a system.
AI helped me build faster, but the design decisions were still mine. Working within tight token limits in Cursor and Lovable made that clear.
Lovable's credits ran out, even after 100 more were added. One Stripe prompt used up Cursor's.
Split each feature into small prompts, tightened with Claude to name the function, the check, and the test case.
All four features built, plus the badge redo after round two. Working MVP handed off.
The Stripe payment form currently lets any card number go through (even declined test cards like 4000 0000 0000 0002). The submit button is skipping the payment validation. Please update the RSVP button's submit handler to actually await the Stripe payment confirmation (stripe.confirmPayment or stripe.createPaymentMethod). It must throw a visible error on the screen if the card fails or is declined, and only complete the RSVP if Stripe returns a success status.
The Stripe payment form lets any card through, including declined test cards (4000 0000 0000 0002). The RSVP submit handler is likely calling recordRsvp() without properly awaiting and checking the result of stripe.confirmPayment(). Please fix the submit handler so it:
1. Calls stripe.confirmPayment() with redirect: 'if_required'
2. Awaits the result and checks for an error object. If present, display the error message (e.g. error.message) visibly on screen and stop
3. Only proceeds to call recordRsvp() if paymentIntent.status === 'succeeded'
4. Does not silently swallow or ignore any Stripe error response
Test with decline code 4000 0000 0000 0002 to confirm it now blocks the RSVP and shows a visible error.
Most of my Lovable prompts cost 3 to 5 credits. This one cost 1.9.
By hand: I caught the bug by testing with Stripe's test cards, wrote the fix prompt from it, and re-tested. The approved card now completes the RSVP; others decline with an error.
Repo, file structure
Repo, README
Describing the whole app at once burned tokens fast. I only got usable results once I broke each feature into small prompts in a fixed sequence. It also made me define each screen's behavior before building it, which is the same discipline a handoff needs.
I built it to show the idea works and to test it with real people. Making it secure and public is the IT team’s job, and knowing where my part ends is part of the work.
Badges got the most design effort and were the hardest feature to use in testing. When I asked what would bring people back, events beat rewards. Next time I’ll test the core idea earlier, not just how usable it is.