BOXSPOT
Designing a multi-sided platform that coordinates athletes, fitness spaces, availability, capacity, bookings, and operations.
A simple promise with a complicated system underneath.
BOXSPOT started from a clear proposition: make it easier for athletes to discover and access fitness spaces beyond a single home gym.
But the product could not be treated as a simple directory. A useful platform had to coordinate multiple actors with different needs, changing availability, capacity constraints, bookings, cancellations, and operational responsibilities.
My role sat across product and technology: turning the concept into a coherent product model, shaping the workflows, designing the experience, and keeping the interface grounded in what the underlying system could actually support.
Start with actors, resources, and responsibilities.
Before focusing on screens, I mapped the platform as a coordination system: who participates, what each party controls, what information must stay in sync, and where the platform itself needs to mediate.
Athlete
Discovers spaces, evaluates fit, books access, manages changes.
Gym / Box
Publishes access, sets capacity, manages availability and attendance.
BOXSPOT
Connects supply and demand while maintaining booking state and platform rules.
Platform Admin
Resolves exceptions, oversees quality, and supports operational edge cases.
Design the journey as a sequence of commitments.
The primary athlete journey can be expressed simply. Each step, however, changes system state and creates new responsibilities for the platform and venue.
Discover
Evaluate
Reserve
Confirm
Attend
Complete
Make complexity visible only where it helps someone act.
Clarity before choice
Surface the information an athlete needs to confidently decide before adding more options or controls.
State must be explicit
A booking should never rely on interpretation. Users need to know what is confirmed, pending, changed, or cancelled.
Operators need a different interface
The venue experience prioritizes capacity, attendance, exceptions, and operational visibility rather than discovery.
Design with implementation in mind
Interactions were considered alongside application logic and the data/state required to make them reliable.
search / venue detail / availability / booking.
capacity, schedule, bookings, attendance, or admin.
The interface and the system were designed together.
Because my role crossed product and technology, design decisions could be evaluated against application behavior rather than treated as isolated visual specifications.
Data model
What entities and relationships need to exist for locations, availability, bookings, and users to remain coherent?
State & edge cases
What happens when a booking is pending, cancelled, at capacity, or changed after confirmation?
Feasibility
Product decisions were shaped with implementation constraints in view, reducing the gap between interaction design and software behavior.
The lasting lesson was to design the rules before polishing the surface.
BOXSPOT strengthened the way I approach platform products: the quality of the interface depends on the clarity of the underlying model.
Multi-sided products become difficult when responsibilities, state, and exceptions are implicit. Making those relationships explicit creates a stronger foundation for both product decisions and implementation.