echo park embark • Concept 2023
A mobile experience designed for discovering curated, budget-friendly activities in Echo Park

Role
Product Designer
Timeline
Aug 2024 – Nov 2023
(16 weeks)
Team
Lois Kim
Isabel Bautista
Arthur Jensen
Sammy Schreier
MY IMPACT
User Research
Wireframing
Prototyping
TL;DR
Echo Park Embark is a mobile app that helps budget-conscious visitors explore Echo Park with confidence—surfacing affordable attractions and building custom itineraries. Over 16 weeks, I led research synthesis, built the visual design system, and ran three prototyping phases. I tracked down recurring issues like user flow friction and icon clarity.
Problem
Not knowing what something costs makes people default to what they already know.
Unfamiliarity, financial barriers, and misconceptions about Echo Park keep low-income individuals and families from exploring it.
Interviews and background research surfaced three consistent barriers:
Unfamiliarity
Visitors don't know the neighborhood well enough to feel comfortable exploring alone.
Reputation
Echo Park's gentrification history has left some visitors feeling unwelcome or out of place.
Cost
Rising prices mean leisure spending is low on the priority list for budget-conscious households.

Opportunity
How might we give budget-conscious people a way to plan a fun, customizable trip to and around Echo Park?
Instead of a generic city guide, we saw room for something narrower: a tool that filters for affordability and gives people enough context to make a new neighborhood feel low-risk.
Solution
Finding something new and staying on budget aren't two separate decisions.
Echo Park Embark is a personalized guide to affordable exploration. Users browse attractions by category, see price and essential details up front, build a custom itinerary, and navigate to it directly—with local deals surfaced along the way for budget-conscious visitors.

core flows

Onboard: Tell us what you're into
Pick a few categories you care about, so the app feels tailored from the very first screen.

Explore: Echo Park stops feeling like a blank map
Attractions sorted by your interests, plus a "You Might Like These" row.

Discover: No more guessing games
Tap into any listing and see hours, price, rating, photos, and sometimes a local coupon — no surprises when you get there.

Navigate: A vague idea becomes an actual plan
Add stops to an itinerary, label it, jot a note, and hand off to maps for directions.

Map View: Seeing the whole day at a glance
See distance between stops at a glance, so you know what's a quick walk versus a trek across town.
Design and build
Working my way down, thinking from a high level structure…
Working my way down, thinking from a high level structure... I started with the persona and core barriers, then moved screen by screen into the itinerary builder and navigation flow. The working principle was context forward: show what something costs and what to expect before asking someone to commit to it.
Phase 1: User testing exposed unclear icons and a missed CTA.
I built wireframes and prototypes for the app's foundational features, including the itinerary builder. Testing surfaced our first usability issues: unclear icons, an ambiguous CTA, and confusing category labels.

Phase 2: A custom navigation feature backfired.
To make the app feel tailored from the start, we introduced an onboarding flow where users filter their interests, which then generates premade itineraries suggested based on those interests. We also built a custom in-app navigation feature that guides users stop-by-stop through their itinerary. But testing showed this added more confusion than clarity. Users struggled with the swipe-based flow and consistently missed our audio guidance feature across multiple rounds.

Phase 3: Cutting what didn't work, refining what did
Phase 3 was as much about subtraction as addition. Rather than keep iterating on a navigation experience reinventing what people already use, we cut it. Once a user builds an itinerary, the app now hands off to whichever maps app they already rely on (Apple Maps or Google Maps) instead of asking them to trust a new one. That decision freed up time to land on a visual identity that actually fit the product.

Reflection
What I'd carry forward
Knowing when to cut something is as important as building it
We spent two phases building and refining a custom navigation feature before realizing the real fix wasn't a better version of it—it was handing off to an app people already trusted. I'd want to ask that question earlier next time: are we improving this, or just getting better at defending something that shouldn't exist?
Restraint is a design skill
I had more good ideas than the timeline could support. The real work wasn't generating solutions—it was cutting them down to the one feature set that solved the core problem well, instead of five problems shallowly. That tradeoff shaped how I think about scope now.