ME
DÖ
P
UYGroup travel app, mobile
One plan for where the group eats and who pays
A mobile app for group trips, designed around one evening in Lisbon. Three friends decide where to eat, the plan updates itself, and they settle up with the fewest transfers and no arithmetic.
It has not launched yet, so there are no usage numbers. What the design proves is the link: every screen reuses a decision or a cost that already exists in the plan, so nobody types anything twice.
Four options at most, closed automatically once everyone has voted. On a tie, the creator’s pick wins.
Less democratic, and there is no runoff. In return nobody has to be the one who calls it, which is where group chats stall.
The plan after the vote. Dinner came from the poll, and the score stays on the item.
Context
Group trips break down at two points. The decision happens in a chat thread, where the loudest voice wins and nobody commits. The money happens later, in a splitting app, as a pile of small transfers and reminders. The plan sits in a third place, and nothing connects them.
Three tools for one dinner: a chat to argue in, a notes app for the plan, a splitting app for the bill.
Tension
A map of the whole app would have been the safe deliverable, and shallow everywhere. I scoped it to one evening and played it end to end with real states, so every rule had to survive being used.
Insight
Plan, decision and expense are one object. A poll result should become a plan item, and an expense should attach to the item it paid for. Once that holds, the app does the bookkeeping people now do in their heads.
The poll result is the plan item. The bill is attached to it.
Decisions, and what each one cost
The three acts
The empty evening slot starts the poll. Up to four places, picked from the map or typed in.
The poll closes on the last vote. The winner is in everyone’s plan before anyone asks.
The expense is already linked to dinner. Balances count from their old value, so the change reads before the total.
Two transfers for the whole trip. Then the other phone, where the request says exactly what it covers.
More: craft details
Craft
It is a working app in plain JavaScript, not a click-through file, so timing and state could be judged on a real phone.
- Balances count upEach balance animates from its old value to its new one in 900ms.
- HapticsA short vibration on votes, payments and selections.
- NotificationsEvery banner opens the screen it talks about. They are what make it feel shared.
- State that survivesThe demo keeps its state, so a reload on a phone does not lose the evening.
Looking back
The first thing I would test with real groups is whether auto-close with a creator tie-break feels fair to the person who lost. Onboarding, trip creation and more than one trip are stubs on purpose. Next it needs more than one currency, partial payments, and the friend who leaves before anyone settles.