Marketing student
“Tap to pay really blows not having it. Physical card is a big downside.”
Taps to pay about 99% of the time and once couldn’t pay without a physical card, so a stranger covered him. Also: “Their hours are hit or miss.”
Andy’s serves a chicken katsu its regulars swear by, from a truck with no signage, a handwritten menu, and no tap to pay. We designed a mobile ordering app that lets students order ahead, pay the way they already do, and know when their food is ready, without losing the truck’s homemade feel.
Paper-tested · mid-fi prototype built · usability test next
Great food, easy to miss
Andy’s has loyal regulars and friendly owners. But the truck has no branding, the menu is a small handwritten sheet of green paper you have to stand at the window to read, there are no set hours or online presence, and it only takes cash and physical cards.
The owner wants more customers during the lunch rush. Our brief: find out what’s keeping people away, then design an app that fixes it.
Our goal: help Drexel students order ahead, pay the way they already do, and know when their food is ready, without losing the truck’s homemade feel.
Each of us watched the truck during a different part of the day. I took the 2:15–3 pm slot, after the lunch rush.
I interviewed three Drexel students who eat at Andy’s once or twice a month. Every one of them orders the chicken katsu.
“Tap to pay really blows not having it. Physical card is a big downside.”
Taps to pay about 99% of the time and once couldn’t pay without a physical card, so a stranger covered him. Also: “Their hours are hit or miss.”
“The truck is ugly but has character.”
Comes for the value and the owners: “Good food, good people.” Pays with Apple Pay everywhere else, and thinks an eye-catching poster alone would bring in more people.
Wants to go more. His only complaint is the hours.
Orders DoorDash every day because it saves time. The food isn’t what holds him back, the uncertainty is.
We put every observation and interview finding on a sticky and grouped them three ways: what customers need, what they’d want from an app, and where Andy’s loses to its competitors. My notes fed the value props, user needs, payment and competition columns.
Lilly Jones is a busy Drexel student with 20 minutes before her next class. The team mapped her through an ideal visit with the app, from discovering Andy’s to eating on the green.
Three pages of my own thumbnails, about 30 screens: menu, tracking, payment, receipt, specials, “order ready,” hours, reviews, past orders, favorites, an Our Story page, and a map with directions.
We scored every idea on whether it was New, Useful and Feasible, then focused the first version on three jobs.
A digital menu with categories, prices and descriptions. Customization and add-ons. Guest checkout, with an optional account for rewards.
Apple Pay and saved cards. A quick checkout with as few steps as possible. An order confirmation and receipt.
Choosing a pickup time. Order status from received to cooking to ready. Today’s hours and location.
Saved for later: reordering favorites, allergen info, menu search and featured dishes.
Each of us storyboarded one task on paper. Mine follows a student between classes from the cart to the window: payment, confirmation, live tracking, walking directions, pickup, and rating the order. Then I tested it with a Drexel student.
Each of us ran a moderated test of the full paper prototype with one participant, using a script I wrote for the team. Mine ordered the katsu and found his profile without much trouble, but he tapped Add to Bag and asked whether it had worked. On paper, nothing changes when you tap. That was my moment: without a cart badge or a confirmation, people lose their sense of progress.
Patterns that showed up across the team’s sessions, and what we changed:
Note to self for next time: let participants get stuck before answering their questions, and watch how they recover.
Our first checkout said: “Payment will be taken in person. Cash or card only.” It pushed payment back to the window, the exact friction we’d seen in research. I took on the payment screen.
Why it had to change
What I changed
The tradeoff: Andy’s has no point-of-sale system, so a real build needs a payment processor. Pay at pickup stays as the fallback while that’s phased in.
We rebuilt the flow in Figma as a mid-fidelity prototype: start and hours, menu, customizing an item, cart, pickup and payment, and the order confirmation. Each of us owned a set of screens.
A cash-only truck with no point-of-sale meant phasing payment in, not pretending the backend exists.
“Did it go in my bag?” showed that every action needs a visible response, especially around orders and money.
Observation caught payment friction that people downplayed in interviews.
Next: high-fidelity UI with the Andy’s brand, order status notifications, and running the usability test to iterate. This page will update as the project moves.