UX case study
L'Artusi Dine-In
Designing an order-and-pay app for a Greenwich Village Italian restaurant
At a glance
Ordering at the table, without the wait
Problem
Ordering and paying meant flagging down a server, leading to miscommunication, errors and long waits.
Goal
Let diners order and pay from their table, accurately and on their own time.
Outcome
A tested hi-fi prototype covering check-in, menu, customization, call-a-waiter and checkout.
My role
UX designer, end to end, from concept to high-fidelity prototype.
Timeline
June 2021 – January 2022
Methods
Interviews, empathy maps, personas, journey mapping, wireframes, prototypes, 2 usability rounds
The product
Modern Italian in the heart of the Village
L'Artusi is an Italian restaurant in Greenwich Village, New York, serving a modern take on traditional Italian cuisine that balances comfort and creativity.
Its guests come from all over the world, so the app had to make an Italian menu easy to understand, order from and pay for, in any language.
Understanding the user
Research summary · Pain points · Personas · Journey map
Research summary
Diners wanted more than speed. They wanted less contact.
I ran interviews and built empathy maps to understand who I was designing for. The primary user group: working adults who regularly ate out during the COVID-19 pandemic.
Research confirmed the initial assumptions about miscommunication and wait times, and surfaced a third factor: people were wary of new places and of interacting with strangers.
Assumed
Miscommunication with servers and long waits
Discovered
Fear of new places and of unnecessary contact with others
Pain points
Four problems to solve at the table
1 · Navigation
Mobile menus are hard to move through and find things in.
2 · Time
Long waits to be attended to when seated, and again at checkout.
3 · Mix-ups
Language barriers lead to more errors when orders are taken.
4 · Accessibility
Dishes are often named in another language, with little or no description.
26 · Registered nurse
Brooklyn, NY
Married, has a dog
Persona 1 of 2
Caroline Green
“Because I work with a lot of COVID-19 high-risk patients, I am careful with the people I interact with and the places I go.”
Goals
- Give patients lasting recovery plans after discharge
- Enjoy time out safely with a few people she loves
- Avoid unnecessary contact with strangers
Frustrations
- Skeptical of places without an accessible menu online
- Hard to wave down a waiter to order or pay
- Menus rarely describe unique or niche dishes
Problem statement
Caroline is an essential worker who needs to reduce contact with others, understand what she's ordering, and check out with ease.
30 · Customer success rep
Princeton, NJ → New York City
Single
Persona 2 of 2
Justin Sol
“I love exploring different cuisines around the city and trying out new restaurants in an efficient and timely manner.”
Goals
- Help clients uncover the full value of a product
- Meet new people and understand diverse backgrounds
- Spend less time on logistics, more with friends
Frustrations
- Paper menus turned mobile are hard to read
- Splitting the bill in a big group gets confusing
- Small restaurants' menus run long and repetitive
In short
Justin wants to decide quickly, spend his time with the people at the table, and pay without the who-owes-what hassle.
User journey · Caroline
Clear dish descriptions make or break her order
| Access app | Start order | Place order | Receive food | Pay and tip | |
|---|---|---|---|---|---|
| Tasks | Scan table QR code, open app | Read menu, select items | Set table, review, place, confirm | Inspect and eat meal | Open bill, add payment, pay |
| Feeling | Confused, impatient | Lost | Anxious about ordering | Delighted, or upset if it's wrong | Frustrated if payment fails |
| Opportunity | Mobile web app, no download | Food photos, plain descriptions, language setting | Streamlined checkout with undo, order updates | Special notes, translated if needed | Cash option via waiter, post-meal feedback |
Starting the design
Paper wireframes · Digital wireframes · Low-fidelity prototype · Usability studies
Paper wireframes
Sketch wide, then keep what solves a pain point
I drafted several versions of each screen on paper before going digital. On the item screen, I prioritized a photo and description of the dish, and the ability to adjust it for dietary preferences.
★ Starred elements made it to the final mockup.
Digital wireframes
Built to remove miscommunication
Every screen traced back to a research finding, with the heaviest focus on language barriers. Guidance mattered most in the final steps: placing the order and paying.
Low-fidelity prototype
One flow: menu, cart, checkout
From the completed wireframes I built a low-fidelity prototype of the primary flow: browse the menu, add an item to the cart, and check out.
View the lo-fi prototype →
Usability studies
Two rounds of testing, each one changed the design
Round 1 · Wireframes → mockups
Users wanted an easier way to add more items to their cart. Users needed one intuitive flow to order and pay at the table. Onboarding and ordering needed clearer, more consistent guidance.
Round 2 · High-fidelity prototype
Users wanted to call their waiter at any moment. Customization toggles were confusing for pre-selected ingredients.
Refining the design
Iterations · Final mockups · High-fidelity prototype · Accessibility
Iteration · after round 1
Add to order, straight from the menu
Early mockups only let diners add items from the item screen. I added “Add to order” buttons to the menu list so diners can build a multi-item order in fewer taps.
Before
After
Iteration · after round 2
Help is always one tap away
Testers were frustrated they couldn’t ask a server a quick question about the menu. A call-waiter button now sits in the top bar on every screen.
Before
After
Final mockups
From browsing the menu to the receipt
High-fidelity prototype
Check in, order, pay. Staff on call.
The final prototype guides diners through check-in, the menu and checkout, lets them customize any eligible dish, and calls wait staff whenever they need help.
View the hi-fi prototype →
Accessibility
Designed for any diner, in any language
1 · Familiar icons
Commonly known icons help diners navigate and complete tasks without reading every label.
2 · Language switching
The app defaults to the system language, and diners can change it any time in settings.
3 · Consistent CTAs
High-contrast buttons in the same position on every page guide diners from one task to the next.
Going forward
Takeaways · Next steps · Looking back with a product lens
Takeaways
The first idea is a starting point, not the flow
Impact
The app meets diners' needs at the table and is built to reduce miscommunication between servers, kitchen staff and customers.
What I learned
Usability studies and peer feedback shaped every iteration and kept my own assumptions about a “common” experience in check.
Next steps
Where I'd take the research next
1 · Onboarding at check-in
Research how easily diners get started once they're checked in at the restaurant.
2 · Kitchen-to-table loop
Analyze kitchen feedback to make sure open-ended requests sent through the app are handled well.
Looking back · 2026
What I'd add today, with a product lens
Success metrics up front
Define what “faster and clearer” means: time from seating to order, order error rate, time to check out.
Both sides of the table
Map server and kitchen workflows too, so the app removes work for staff instead of moving it.
The business case
Test adoption and point-of-sale integration, and weigh the cost to the restaurant against table turnover.
Prefer slides?
See this case study as a slide deck
A condensed, presentation-ready version of this project that's easy to skim or share.
Want to talk it through? Message me @ reahrajmangal@gmail.com
