Personal project · NYU · Mobile app
Yelp, rebuilt around one question: what’s good near me, at my price?
Easy Yelp: in two weeks I reviewed the Yelp app, cut everything that didn’t help people choose, and built a working React Native version on live Yelp data.
8 min read
The 30-second version
Price became the structure of the app, not a filter
Problem
Finding a place to eat meant getting past sign-in prompts, ads and deep menus before I ever saw a price.
My role
All of it: the heuristic review, goals, paper sketches, the React Native build and the test sessions.
Key decision
Group results into horizontal rows by price, Cheap, Affordable and Donate a Kidney, instead of one list sorted by rating.
Outcome
A working app on real phones in two weeks, pulling live listings from the Yelp API and shared with testers through Expo.
Before · the big app
- Sign-in prompt first
- Ads among the results
- Set a price filter
- Dig into a listing for price
After · Easy Yelp
- Location found for you
- Search “pizza”
- Pick a price row
- Call to order
Context
Take a big app apart, then rebuild one job well
The NYU brief was product deconstruction and rapid prototyping: pick a popular app, find where it gets in the way, and prototype something better in two weeks.
I picked Yelp because I used it most and it slowed me down most. The job I cared about was small and frequent: find something good to eat nearby, at a price I can afford. The Expo project's working name says it plainly: NYU Cheap Eats.
I also set myself three personal goals. Ship something that runs on a phone, not just a design file. Learn React Native by building with it. And practice cutting scope until only the core job was left.
- Brief
- Deconstruct an app, prototype a better version of one task
- Platform
- iOS and Android, through Expo
- Data
- Yelp API: name, address, price level, rating, reviews, photos
- Timeline
- 2 weeks
The problem
Three things stood between me and a meal
From a heuristic review of the Yelp mobile app, focused on one task: choosing where to eat.
- Too much on screenAds and promoted listings competed with the results I asked for.
- Answers buried deepPrice and menu sat several taps into a listing.
- Sign-in before valuePrompts to log in arrived before I'd seen anything useful.
Who it is for
Two hungry people, two very different budgets
Personas drawn from my own habits and the people around me.
The between-classes student
Hungry, on a budget, 20 minutes free
- Needs
- Something cheap and close, decided in a minute.
- Before
- Scrolls past ads and sorts by price by hand.
The weekend treat
Planning a night out, happy to spend
- Needs
- The best places nearby when spending more is the point.
- Before
- The same filters and scrolling, for a different budget.
My role and process
Two weeks, from a review to a working app
My role: product designer and developer, end to end.
- Review
3 pains
Heuristic analysis of one task: choosing where to eat
- Goals
5 rules
What the MVP must do, and what it must never do
- Sketch
Price rows
Paper wireframes, three layouts compared
- Build
React Native
Expo and the Yelp API, on real phones
- Test
Expo and a QR code
Testers on their own phones
- Reflect
Cut more
What I'd change next time
- Worked with
- Solo, with feedback from classmates and instructors
- Tools
- Expo, React Native, JavaScript, Yelp API, pen and paper
Research
The five questions my review asked
Speed
How many taps does it take to go from opening the app to seeing a price?
Noise
What on screen isn't helping me choose?
Entry
What stops me before I see a single result?
Decision
Which details actually decide where I eat?
Budget
Do people think of price as a number, or as a feeling like "cheap"?
For a quick meal, price and distance decide almost everything. Ratings, photos and menus matter after you've narrowed it down. That was my working hypothesis for the build.
Goals
Five rules for the MVP
- Cut
Keep only what helps you choose
No ads and no social features. If it doesn't help pick a place, it goes.
- Entry
No sign-in, ever
Results on the first screen, without an account.
- Order
Price and distance first
They lead every screen. Everything else waits.
- Location
Use location automatically
The phone already knows where you are, so the app doesn't ask.
- Group
Group by price, not by score
Three tiers people already use in conversation.
The key decision
How should results be organized?
I sketched three layouts and judged each against the five rules.
One ranked list
One vertical list, sorted by rating, like most search results.
- Pros
- Familiar. The best-rated place comes first.
- Cons
- Price is a detail on each row, so you still scan everything for your budget.
List with a price filter
The same list, with $, $$ and $$$ filters on top.
- Pros
- Exact control over budget.
- Cons
- One more decision before any result, and only one budget on screen at a time.
Rows by price
One horizontal row per price tier: Cheap, Affordable, Donate a Kidney.
- Pros
- Every budget visible at once. Swiping sideways is easy with a thumb. Price is the structure, not a filter.
- Cons
- Fewer results per tier on screen, and no single best-overall ranking.
The decision
I went with rows by price
Price became the structure of the page, so the first glance already answers "what can I afford?". No filter UI needed, which kept the screen calm.
A strict best-to-worst ranking across all prices, and room for long result lists. For a quick meal nearby, that was the right trade.
The tier names are informal on purpose. "Donate a Kidney" says $$$ with a smile.
What I left out
Three things I cut on purpose
- Sign-inNo account, no prompt. Results come first.
- AdsNothing on screen that you didn't search for.
- Social featuresNo feeds or check-ins. Detail screens stay focused on choosing.
Sketch to app
The paper sketch survived almost untouched
The solution
Open, search, swipe, call
No sign-in step anywhere. The app does the setup; the person only makes choices.
- Person
Opens Easy Yelp
No sign-in screen
- App
Finds their location
From the phone, automatically
- Person
Searches "pizza"
One search box, front and center
- App
Groups results by price
Cheap, Affordable, Donate a Kidney
- Person
Swipes a row, opens a place
Name and address on every card
- Person
Calls to order
Rating, reviews, address and photos on one screen
The home screen
Five choices on one screen
Location, found for you
"Near you" uses the phone's location, so there's nothing to set up.
One search, front and center
The hint suggests a dish, not a business category.
Price is the heading
Each row is a budget. The chip shows $ to $$$.
Swipe sideways
Rows scroll horizontally, so three budgets fit on one screen.
Only what decides
Name and address. Ratings wait for the detail screen.
The app
The screens, end to end
The prototype’s screens, and the walkthrough I recorded at the time.
Testing
On real phones, through Expo
I published the app with Expo, so anyone could open it on their own phone by scanning a QR code. Then I watched them use it and asked about the journey and the no-sign-in start.
Start
Did anyone look for a sign-in, or miss it?
Rows
Did people find the sideways swipe without a hint?
Choice
Could they get from opening the app to a place they'd call, without help?
Outcome
A working app in two weeks
A React Native app on live Yelp API data, running on real phones by the end of the sprint.
Shared through Expo with a QR code, so testers used it on their own phones, with feedback on the journey and the no-sign-in start.
Time from opening the app to a choice, and how often people wanted a filter the rows didn't give them.
Reflection
What I took from it
Simplicity is a decision you make many times
Adding the price rows was easy. Saying no to reviews, check-ins and sign-in, again and again, was the real work.
Building it changed the design
Working with real API data showed which details were reliable enough to lead with. Price and address made the cut; long review text didn't.
What I'd do next
Test with more people, add a clear cue that rows scroll, and check that every row works with a screen reader.
Appendix
Additional material
More screens and artifacts from the project.
A1The prototype screens
