Skip to main content

MiamiGo

Designing a
two-sided local
discovery product.

A two-sided mobile product connecting consumer discovery with venue demand generation through one shared offer object across discovery, claim, redemption and measurement.

  • Two-Sided Product
  • End-to-End Flows
  • Venue Operations
  • Platform UI

SCOPE

Consumer discovery, venue onboarding, offer creation, redemption states and performance UI.

CONSTRAINT

Two audiences need different interfaces, but the offer must remain one shared state across the system.

DECISION

Use the offer as the product object connecting discover → decide → claim → redeem → measure.

EVIDENCE IN THIS CASE

Consumer flows, business portal, offer states, redemption flow, measurement screens and UI foundations.

VALIDATION STATUS

The case shows the designed product loop. Claim-to-redemption, venue activation and repeat discovery remain next-validation metrics.

01

Two audiences, one shared transaction loop.

Consumers need to decide quickly what is worth doing nearby. Venues need a way to activate demand and understand whether an offer created action. The product challenge was to support two different user models without letting them drift into two disconnected systems.

CONSUMER

What is worth doing nearby, right now?

VENUE

How can I turn an empty time window into demand I can measure?

02

What if one offer object connected discovery, redemption and measurable demand?

The core product decision was to make the offer the shared object across both sides of the system: discovered by the consumer, claimed and redeemed in the real world, then measured by the venue.

DISCOVER

Consumer

DECIDE

Consumer

CLAIM

Shared state

REDEEM

Shared state

MEASURE

Venue

03

Reduce the decision cost of “what should I do tonight?”

Discovery is organized around time, proximity, visual context and offer value so the interface supports a fast decision without collapsing into a generic local directory.

TIME

Surface what is happening now

PROXIMITY

Keep distance and map context visible

VALUE

Make the offer legible before the tap

CONFIDENCE

Give enough context to decide

MiamiGo Discover screen
MiamiGo map discovery screen
MiamiGo deals and offers screen
MiamiGo venue details screen

01 / 04

04

A claim is not the end of the journey.

The product needed to connect digital intent with a real-world venue action. Claim, redemption and expiration were designed as explicit product states so both sides understand what happens next.

MiamiGo claimed offer screen
MiamiGo redeemed offer screen
MiamiGo expired offer screen
CLAIMED -> PRESENT -> REDEEMED / EXPIRED
MiamiGo claimed offer screen
MiamiGo redeemed offer screen
MiamiGo expired offer screen

01 / 03

05

The same product has to work from the other side of the counter.

Venue onboarding turns a business need into a guided operational path: enter the partner experience, create the account, establish the venue and move directly toward publishing an offer.

MiamiGo business portal screen
MiamiGo create business account screen
MiamiGo account created screen
MiamiGo create offer screen

01 / 04

06

Publishing is a lifecycle, not a button.

The offer model includes creation, preview, live states, editing, pausing and expiration. Designing these operational states makes the product usable beyond the happy path.

MiamiGo business offers list screen

LIST

Offer list

The venue can see offer status and manage published inventory from one operational surface.

07

Measure what happened after discovery.

Views and taps are only part of the story. The venue experience was designed to surface claim activity, offer performance and time-based patterns so operators can learn what demand actually converted.

MiamiGo offer performance screen
MiamiGo offer analytics screen
MiamiGo offer performance screen
MiamiGo offer analytics screen

01 / 02

INTEREST

Views and offer engagement

INTENT

Claims created

OUTCOME

Redemption and performance

TIMING

Best time and day signals

08

One system across two very different workflows.

The consumer and venue sides share the same foundations, interaction language and reusable patterns. The system keeps MiamiGo recognizable while supporting very different tasks and information density.

Foundations

Colors, type and radius tokens

pink

#F489AD

sky

#3ED6D0

black

#0D0F10

white

#FFFFFF

white-55

#FFFFFF8C

white-5

#FFFFFF0D

stroke-pink

#F489AD33

stroke-sky

#3ED6D033

black-75

#0D0F10BF

CANELA TRIAL

Headlines
80px / 700Experience Miami
56px / 700Experience Miami
48px / 400Experience Miami
32px / 400Experience Miami

NEUE HAAS GROTESK

UI / Body
20px / 500The nightlife guide for MiamiGo
16px / 400Handcrafted cocktails on our signature menu
14px / 400Valid for all cocktails • 4-7 PM
12px / 700MIAMI SUNSET • $22

UI, effects & radius tokens

r-12
r-14
r-16
r-24
r-32
r-9999
MiamiGo feature card system
MiamiGo icon and chip system

09

From local discovery to a closed-loop demand system.

The design treats consumer discovery and venue operations as one connected product system. A shared offer object carries state across discovery, decision, claim, redemption and measurement, creating a measurable loop instead of two separate interfaces.

CONSUMER CLARITY

A clearer path from “what is nearby?” to a confident action.

VENUE ACTIVATION

A focused operational path from business setup to publishing and managing an offer.

PRODUCT LEARNING

A measurable loop that can connect discovery behavior with claims and venue performance.

NEXT VALIDATION

Claim-to-redemption rate · Venue activation · Repeat discovery · Offer performance by time window

Next project: GoPool

Tell me what you need

A few details are enough. You can stay in this case and continue exactly where you left off.

What brings you here?

Prefer the full brief?Open contact page ↗