Lab · Experiment 01
Quintos ’86
A digital layer for a real-world reunion.
- Tags
- Product Design · Service Design · AI-assisted development
- Year
- 2026
- Role
- Product design · Service design · AI-assisted development
It was supposed to be a Google Form.
We were organising a reunion dinner for people born in 1986 in Benicarló, a town of around 30,000 inhabitants.
The original idea was simple: send a form and find out who was coming.
But while thinking through the experience, I realised that confirming attendance was only one moment in a much bigger journey.
A form could answer one question:
“Are you coming?”
The actual experience involved many more:
- Who else is going?
- What are we eating?
- How much does it cost?
- How do I pay?
- When do I need to pay?
- Has my payment been confirmed?
- What if I have a food allergy or intolerance?
- What songs take us back there?
- What old photos do we have?
- How can we share the experience together?
That is when the Google Form started becoming a product.
“The form was solving a task, not the experience.”
What came out of it was a small digital experience built around the lifecycle of a real-world event — before, during and after the night itself.
Before the event
Understand, decide, participate.
Everything someone needed in order to say yes — and to actually follow through — lived in one place instead of a thread of messages.
- Date and location
- Price and payment deadline
- Menu
- Attendance confirmation
- Bank transfer information, easy to copy
- Food allergies and intolerances
- Attendee visibility
- Filtering attendees by former school
The attendee list was intentionally visible. The design intention was to make participation visible: seeing who was already coming could help someone decide whether they wanted to join. This was a design intention, not a measured result.
Attendance
Turning intention into confirmed attendance.
The admin view separated people who had said they were coming from those whose payment had been verified, making it easier to identify pending payments and follow up before the deadline.
Access
Access evolved with the event.
Initially the site used a shared password, to create a private feeling around the reunion while registration and payments were still open. After the payment deadline, the access model changed: only confirmed attendees whose payment had been verified could enter, using their email.
Before the deadline
- Shared password
- Explore
- Register
- Pay
- Payment verification
After the deadline
- Verified attendee
- Access
The product changed as the event changed.
Anticipation
Building the event before the event.
The product was not only administrative. It was also a way of making the night feel collective before anyone physically arrived.
Attendees
People could see who was already coming and filter attendees by former school — the small detail that turns a list of names into recognisable faces.
Music
People could contribute to the soundtrack of the reunion, either adding directly through Spotify or suggesting a song without it, so nobody was left out of the playlist.
Wall
A shared space where people could leave messages, memories and questions, so the conversation started weeks before the dinner.
Collective memory
Building a shared visual memory.
Participants could contribute old photographs and shared memories: uploading, describing and editing what they posted. The intention was not to create a gallery, but to let a generation collectively assemble the visual memory of its shared past.
Frontstage + backstage
What participants didn’t see.
Behind the participant-facing site there was an operational layer supporting the real event.
- Participant experience
- Digital product
- Admin / operations
- Real-world event
The admin experience supported organisers in
- Viewing attendees
- Viewing relevant attendee information such as email
- Distinguishing attendance confirmation from verified payment
- Manually verifying payment status
- Identifying pending payments
- Accessing relevant food allergy and intolerance information
- Printing attendance information
- Exporting attendee information to Excel
- Using payment verification to determine post-deadline access
Admin screens are represented here without any participant data. No emails, health information, payment details or credentials appear in this case.
Visual identity
Nostalgia as an interface.
The product itself used an intentionally nostalgic identity inspired by the eighties: pixel typography, terminal references, neon-inspired details, retro interface language and playful microcopy. That identity belongs to Quintos, not to this page.
How it was built
AI-assisted building.
I designed the experience, defined the logic and flows, and used Claude as a development partner to take it from idea to a working product.
The interesting part isn’t the tooling. It’s the combination of product thinking, experience design and AI-assisted building — the technology is what made the experiment possible at this scale and speed.
Learning
What I take from it.
What started as a simple way to collect attendance became an experiment in designing around the whole experience rather than a single task.
AI-assisted development allowed me to turn product decisions into a working experience without waiting for a traditional development process.
It doesn’t prove a methodology. It was an experiment built for a real need, used in a real context.