POAP Passport
From branded collectible hunts to a configurable phygital experience platform.
- Sole UX/UI Designer
- 2023–2026
- V1 and V2 launched
- Information architecture · User flows · Interaction design · UI · White-label system · Backoffice logic · Handoff
Why a reusable system was needed
POAP Studio initially built tailored collectible hunts for individual brands and events. As requirements diversified, the team needed one system that could support different identities, collection structures and participation rules without rebuilding from scratch. As the sole UX/UI designer, I worked with the founders and engineering to turn that requirement into a participant-facing platform, a configurable backoffice and a white-label framework — the three pieces this case follows, from a backoffice decision to a system behaviour to a participant outcome.
The challenge was never to make each Passport look different.
It was to stay legible for both participants and administrators while each activation differed in branding, rules, collection structure and rewards.
V1: establishing the participant model
The first version focused on branded collectible hunts. Participants could join a Passport, discover available collectibles, track progress, unlock benefits and compare progress through leaderboards. Three item states carry most of the product’s meaning, so each one earned its own screen rather than a badge on a grid.
Benefits were the reason to collect. The requirement list on the benefit and the redemption moment are the two halves of that promise, so they were designed as a pair, not as separate screens.
What broke as requirements grew
The limitations of V1 became the design inputs for V2. None of them were visual.
- Customisation was insufficient for increasingly diverse brand identities.
- Collections needed richer internal structure and categories.
- Benefit logic needed more than simple requirements.
- Rewards required stock, multiple types and more flexible unlock mechanisms.
- Some projects required bespoke implementations outside the standard product.
V2: scaling configurability
V2 expanded Passport from a hunt template into a configurable platform capable of supporting product onboarding, employee engagement, community programs, city exploration and event gamification.
Make requirement logic readable instead of hiding it
Benefits could now depend on any combination of collectibles: all of them, some of them, at least one, or specific mandatory items. Expressing that in an interface usually turns into either a hidden rule or an unreadable formula.
I put the rule on the benefit itself, as a checklist the participant can verify item by item. The sentence above the list states the logic in plain language, and each row carries its own state. One pattern renders every combination the backoffice can produce.
Configuration → behaviour → participant outcome
The backoffice and the participant product are not two sets of screens. An administrative decision creates a system behaviour, which produces a participant state. Designing that chain is the actual work.
- Organisationwho owns it
- Projectone experience
- Setup & brandingreusable variables
- Collectibleseligibility, timing
- Benefitsunlock logic
- Participantstate and progress
| Backoffice configuration | System behaviour | Participant outcome |
|---|---|---|
| Branding, fonts and media | Reusable visual variables and assets | A Passport that reads as the client’s own product. |
| Collectible, category and availability | Placement, state and timing rules | Collected, available or missed. |
| Benefit requirements | All / some / at least one; mandatory items | A locked or unlocked reward with visible progress. |
| Inventory and redemption | Limited stock and redemption status | Availability, urgency and claim state. |
| Location or collection method | Permission, validation and error handling | The right minting journey, and its edge cases. |
Ship a neutral template that is already a working product
A white-label framework fails when the unbranded state looks broken. Clients see the empty template first, and if it reads as unfinished they ask for a bespoke design, which is exactly what the platform existed to avoid.
The default template is designed as a complete, credible page: real hierarchy, real spacing, explicit replacement slots. Applying a brand swaps variables; it does not rebuild the layout.
Where the happy path runs out
Location verification is the flow worth showing, because almost none of it is the happy path. It has to explain why the browser is about to ask for a permission, handle the asynchronous check, and give a useful answer in every way it can fail.
Experience: unifying Passport and minting journeys
By 2026, Passport and the standalone minting journeys had become deeply interdependent but were still configured through separate tools. I designed the information architecture and low-fidelity flows for a unified product called Experience, combining minting, collections, benefits, branding and distribution into a single administrative model.
The main design challenge was making interconnected rules, dependencies and permissions understandable without removing the flexibility required by advanced clients and internal teams.
- Minting Journey
- Passport
- Shared configuration
- Experienceone project, one model
Selected outcomes
These are outcomes from individual implementations, not one aggregate metric — participants, collectors and redemptions are not interchangeable, so each figure stays attached to its own experience.
- 200
- new users in one day
- 580+
- participants and 700+ benefit redemptions
- 600+
- collectors across Arbitrum experiences
- 65%
- of attendees visited at least two stations
Figures come from the project evidence supplied by POAP Studio and are attributed individually. Where a metric definition is uncertain it is validated before publication rather than rounded up.
Across selected implementations, Passport supported product onboarding, event participation, city exploration and community engagement. There have been more than 20 direct deployments, including MetaMask, Cannes, Mantle, Merge Madrid, Mercedes-Benz Consulting, Arbitrum, Toledo Art Museum, BASF, Shell, Linea, ENS, Bayer, VIVA Technology and WWF.
What I would carry forward
Scalable UX needs more than reusable components.
As the platform grew in complexity, I learned that it also requires clear ownership, documentation, design governance and regular implementation reviews to preserve interaction consistency as the system evolves.
That is why the customisation guidelines exist: a written contract with clients about images, fonts and colours, so the system stays coherent when someone else configures it.
If your product has more rules than screens, we should talk.