HAPPYHOUR — Case Study

01The strategy

An open brief is a test of scoping.

Starting with an open brief, the first challenge wasn’t UI design — it was scoping the product. Most two-sided marketplaces build everything into the consumer experience, leaving the business with a basic, afterthought admin panel.

But if restaurant operators can’t easily read the data, list and manage empty tables, the diner app has nothing to show. I chose to design both sides with equal weight, building them under a single system.

Design for action, not just data.

A dashboard should drive decisions, not just report numbers. Instead of simply telling a manager that table traffic is slow, the app gives them an immediate tool to fix it. The diner taps Grab It, the operator taps Push — this shared focus on quick, direct action is what unifies two completely different interfaces.

2

sides, equal weight

3

operator dashboards, before one worked

~30

screens, both apps

1

system underneath

02The diner side

Give the user a simple answer.

Diners open the app with a clear goal: find a quality restaurant deal during off-peak hours, or discover a local event. The UI cuts out the noise and focuses entirely on answering that immediate need.

Diner flow, launch to review — discovery, booking, the QR pass, and the review that loops back in.

The Loop

A completed visit prompts a quick review, which instantly updates the discovery feed for the next user.

Contextual Booking

The four-step checkout uses inline pickers instead of full-screen overlays, keeping previous choices visible so users never lose context.

Designing for Reality

Instead of designing for an ideal scenario, I built the flow around real-world friction. I analysed actual diner complaints about existing platforms, mapped out how to handle empty off-peak venues gracefully, and simplified checkout down to a single QR pass at the door. An app’s real usability is decided by how it solves these friction points.

03The operator side

The side that decides if the business succeeds.

Diners want deals, but restaurants need to fill empty tables during slow periods to protect their margins. This side of the product is tougher because managers face operational pressures diners never see. I iterated through three versions to get the dashboard right.

Operator flow — the home spine drops into a deal that needs action; Stats forks into act when a deal lags, or leave it when one is healthy.

1

The Consumer Clone · failed

Mirroring the diner app

The first version mirrored the diner app layout with a generic greeting and a hot-deals feed. It looked clean but was completely useless. A manager logging in at 9:00 AM needs an immediate answer to one question: are we on track today? That data was entirely buried.

2

The Industry Standard · iterative

Built on how the real tools work

I studied tools like OpenTable and SevenRooms, which triage tasks by occupancy, pending requests, and active promotions. I rebuilt the screen around this hierarchy using colour-coded states. It was a step up, but the interface only reported problems without offering solutions. Telling a manager “6 of 20 slots sold” identifies an issue but doesn’t help them resolve it.

3

The Final Tool · prescriptive

The card becomes the tool

The breakthrough was moving from passive reporting to active prescribing. If a deal underperforms, the card expands to show the revenue at risk and offers two immediate solutions: Push to Followers or Boost Deal. Stable deals stay collapsed, letting the dashboard automatically reorganise around the urgent decisions a manager needs to make that morning.

The action card, rebuilt here as a live element — the same object the whole product is built around.

Push vs. Boost

Push sends a quick notification to regular followers, capped at once every four hours to prevent spam. Boost is deliberately slower, letting managers tweak the discount or time slot while displaying the projected impact on their margins.

Knowing When to Do Nothing

When a deal is nearly sold out, the action buttons disappear and the status turns green. Pushing a deal that is already performing well is counterproductive — it just crowds out full-paying walk-ins who would have come anyway.

Data Integrity

Because the analytics charts track cumulative seat sales, the lines only climb or plateau. The touch targets are explicitly oversized for fast, reliable use on a busy kitchen line.

Deal needs help — act

Revenue at risk, a clock, and two routes out: Push or Boost.

Selling well — leave it

Green status, no buttons, no manufactured urgency.

04The throughline

The action card unifies both apps.

The operator’s management card and the diner’s checkout card use the exact same structural footprint: identical widths, the same data hierarchy, and a shared saffron highlight for high-priority items. Because both users are making quick decisions under time pressure, the shared design language helps them process information instantly. The card is the smallest expression of the whole concept.

05The system architecture

Supply becomes demand.

The system connects a consumer looking for value with a manager looking for efficiency. Every operational input from the restaurant instantly converts into a marketplace signal for the diner.

The operator

Supply · efficiency

Sets off-peak time windows
Adjusts the deal markdown %
Caps the available covers
Approves bookings & replies to feedback

⇄supply ⇄ demand

The diner

Demand · value

Sees bookable time slots
Sees the live “40% OFF” badge
Feels “12 slots left” scarcity
Gets a QR pass & reads public reviews

Operator input · supplyDiner UI output · demand

Sets an off-peak time window→Generates bookable time slots

Adjusts the deal markdown %→Updates the live "40% OFF" badge

Caps the available covers→Triggers "12 slots left" scarcity

Approves a pending reservation→Populates the active QR pass

Replies to operational feedback→Displays public venue reviews

06Limitations & next steps

What I’d do before it ships.

The concept is built end to end, but three things would need to happen before it could ship — and they’re worth stating plainly.

On-Site Validation

The dashboard hierarchy is based on competitive research and logic. Spending a few shifts with working Prague restaurant managers would validate whether the information priority matches their actual workday.

Dynamic Data Layer

The personalised card recommendations require a behavioural backend that isn’t built yet. Until then, these sections use static, tier-based defaults.

Component Cleanup

A final audit revealed minor text and spacing inconsistencies across screens. I’m currently mapping these into a unified set of master components tied to a single data source, to eliminate formatting errors.