A little thanks. On your terms.
THE CASE, AT A GLANCE
How can a diner understand existing charges and make an explicit tip choice before a terminal handoff?
What this builds onThe archive includes research and hardware exploration. The new flow is a design proposal; no completed payment integration or new test result is claimed.
The next question to testCan diners identify an included service charge, choose zero or a custom tip, and recover the same amount after a connection error? The V3 tasks are prepared, not yet run.
Open the project source ↗ (opens a new tab)TIPEASY / DESIGN DEVELOPMENT / V3
A concept for reviewing restaurant charges, choosing a tip and checking the amount before a terminal handoff.
Independent project · UI/UX by me
This page documents a later design iteration. Research outcomes are not claimed here.
01 / UNDERSTAND
Risk to test
A person may overlook a service charge and add a tip unintentionally.
Design response
Show subtotal, tax and service charge before asking for a tip. Explain the charge without assuming how the restaurant distributes it.
An additional tip is your choice.
Validation question
Can someone identify what is already billed and explain that an additional tip is optional?
02 / CHOOSE
Risk to test
A preselected percentage may be mistaken for a required amount.
Design response
Give percentage, no-tip and custom choices equal access. Show the total only after an active selection.
Validation question
Can someone continue with $0 additional tip without searching for a hidden option?
03 / CONFIRM
Risk to test
A person may confuse reviewing, sending and actually paying.
Design response
Keep an editable review, then match the bill ID and total on the terminal. Connection failure must never imply payment success.
Validation question
Can someone tell what was sent, what was confirmed and whether any payment occurred?
Confirmed: this is an independent project. Visible artifact: the editable V2 interface and concept prototype. The risks above are design hypotheses, not observed findings. Interviews, hardware results and usability outcomes need source evidence before publication.
Prototype map: bill → choice → review → terminal, with service-charge, custom-input and connection-recovery branches.
View the V3 design story ↗A familiar object. A clearer interaction.
A table number gives the bill a place. The torn edge makes the paper recognisable. A handwritten thank-you adds warmth after the decision.
The texture belongs to the setting. The numbers get a clean, white surface.
Follow one amount from start to finish.
Choose a tip, enter your own amount or choose zero. Review the calculation, open the terminal and confirm. Try a connection issue along the way, then find the same amount in Saved.
Choose an example bill
Amounts shown before an optional tip. Switching examples starts a new choice and keeps the latest confirmed summary.
A simplified, local demonstration. No account, payment or external service is connected. Changes reset when the page reloads.
The peach table ticket anchors the bill. White receipts hold the figures. Lilac brings attention to an included charge; sage marks an amount that has been confirmed.
Interface collection / tap to enlarge
One connected decision / 02 surfaces
The terminal carries the same bill forward. A large total makes the handoff easy to check, with a clear return to the phone if anything needs changing.
Try the connected flow ↗A restrained material language gives the interface its identity. The system keeps money, reading and action consistent across the phone and terminal.
Inter / Clear amounts, clear hierarchy
$61.44Subtotal. Tax. Service charge. Your tip.
Title 30 / 35 · Body 16 / 24
Supporting 14 / 20 · Amount 36 / 40
Fill, outline and a persistent selected state work together. “No tip” has the same target size as the percentages.
Consistent decimal places and aligned figures support checking. A 54 px primary action and 24 px screen margins keep the frame stable.
Default, selected, disabled and error treatments belong to reusable components. Receipt rows change without changing their hierarchy.
The original physical exploration
The archived project explored RFID, Arduino, an OLED display and thermal printing. Those materials informed the idea of a handoff at the table.
The new terminal interface demonstrates that interaction. It does not establish a completed payment integration.
TIPEASY / FORMATIVE USABILITY STUDY / NOT YET RUN
Planned study · 5 participants · 20–25 minutes each
Recruit people with varying familiarity with US tipping. This is a proposed plan, not a completed study.
“We are testing the design, not you. Think aloud as you go. This is a concept prototype; no money will move. You can stop at any point.” Ask permission before recording. Use participant codes and avoid storing payment details.
The task buttons open prepared example states. They do not record a participant, collect results or mark a study complete. Starting a task replaces the current draft; the latest confirmed demo summary is kept.
Read to participant
Your restaurant bill is open. Explain what you would be charged before any tip.
Start: Service charge included.
Expected: $48.00 + $3.84 + $8.64 = $60.48. Participant identifies the service charge.
Read to participant
You do not want to add anything beyond the charges already on the bill. Prepare the amount for review.
Start: Service charge included.
Expected: $0 additional tip; total $60.48. Observe whether the option is found without a hint.
Read to participant
You want to leave a $10 tip. The custom amount currently shows an invalid negative value. Explain what is wrong, then use the available correction and check the total.
Start: Custom input validation, without a service charge.
Expected: recognize −5 as invalid and review $61.84 after correction. The Figma prototype uses a preset $10 correction; this browser version also accepts typed amounts. Treat keyboard testing as a separate browser check.
Read to participant
The terminal is disconnected. Decide what to do next and explain whether the amount has been sent or paid.
Start: Connection recovery.
Expected: distinguish unsent amount from payment; retry or return to review without assuming success.
For each task record: participant code · outcome (independent / assisted / incomplete) · time · wrong turns · amount understood · exact quote · confidence (1–5) · issue severity. Keep observed behavior separate from your interpretation.
Participant ___ Task ___ Outcome ___ Time ___
Observed behavior / exact quote:
Interpretation / possible cause:
Design change to try:
Retest observation:
Prioritize any mistaken payment status or unintended amount. Revise repeated comprehension problems, then retest. With five participants, report counts and examples; do not present them as population-wide success rates.
Portfolio results — leave blank until the study happens.
No success rate, interview quote or improvement metric has been inserted. Add dated observations and before/after examples only after testing.
View the original validation workbook ↗Design decision
I kept the receipt metaphor, but reduced its visual noise. Table tickets, clear totals and a handwritten closing each have a place in the sequence. The amounts remain easy to inspect.
Next validation
Next, I would ask a diner to identify the service charge, choose no additional tip, explain the total and recover from a connection problem. I would also check whether the terminal confirmation is understood as an amount confirmation, not a completed payment. These are proposed tasks, not completed findings.
TipEasy is an independent project. The V3 decision story and proposed validation plan build on the V2 interface and component system. The browser prototype supports real numeric entry; the Figma correction uses a preset amount. Bill amounts are illustrative. The bill-presenter scene is AI-generated; the hardware board is original portfolio material. Texture stays outside monetary reading areas. The 2026 portfolio revisit uses AI-assisted interface refinement and presentation production under my direction. No launch or measured usability improvement is claimed.