I turn ideas into shipped products.
Currently migrating this site, some project are linked to Behance in the meantime
Supporting every way an activity can be sold
Adapting activity creation to the business, not the other way around.
Role
CPO & Product Designer
Product strategy, User research, Information architecture, UX design, Developer collaboration
What this unlocked
Scalable support for diverse business models.
Fewer engineering hard-coded exceptions as the platform grows.
Faster onboarding for new business types.
New customer-facing product opportunities.
A path to converting offline revenue into online transactions.
Overview
Started as children's activities, Tripsome later expanded to support a wide range of experiences.
Tripsome originally focused on children's activities. As the platform grew, it expanded to support tours, classes, rentals, sports activities, and ticketed experiences.
While the business evolved, the activity creation flow largely remained the same.
What began as a simple form eventually became difficult to maintain, difficult to use, and unable to support newer business models.
I redesigned the entire activity creation experience, turning it into a scalable system that adapts to different types of businesses instead of forcing every business into the same workflow.
The New Approach
One platform, multiple ways to sell.
The redesign reorganized activity creation into a structured setup process that balances simplicity with flexibility.
A guided flow, modular pricing, independent availability, and progressive disclosure allow different types of businesses to configure and sell experiences without increasing complexity.
7-step structured flow.
A guided setup process that breaks activity creation into clear, manageable steps.
Reduces cognitive load and helps partners move from draft to published activity with confidence.
Support for multiple business models.
Designed to support different ways of selling experiences, from per-person activities to group packages and future pricing models.
The system can evolve alongside different business needs without redesigning the entire flow.
Flexible pricing.
Pricing is built from modular rules rather than a single fixed price.
Partners can introduce customer-based, group, or time-based pricing only when those options become relevant.
Progressive disclosure.
Advanced options remain hidden until they become relevant.
This keeps the experience approachable for first-time partners while preserving flexibility for more complex operations.
Independent availability.
Scheduling, capacity, and pricing operate as separate systems.
Changes to one area no longer require reconfiguring the entire activity setup.
Legacy Experience
The legacy experience and its session recession.
The original flow used only three steps, but complexity accumulated inside activity sessions.
What began as a scheduling concept gradually absorbed pricing, capacity, availability rules, age restrictions, and booking windows, turning sessions into mini-products of their own.
As new requirements appeared, additional fields were added instead of reconsidering the underlying model.
Discovery
Discovery was a mess, no sugarcoating.
Every few weeks another partner wanted to join, bringing a different way of pricing, scheduling, or operating.
At the same time, Tripsome was expanding its audience and the types of experiences it offered.
New requirements often became new fields, new rules, or another exception.
Eventually, it became clear that the problem wasn't supporting existing businesses, it was building a system that could support the next one.
Looking across existing partners revealed why exceptions kept appearing. Similar businesses often had very different pricing, capacity, and scheduling requirements.
| Business | Pricing | Capacity | Scheduling |
|---|---|---|---|
| Pottery Workshop | Per person | Fixed seats | Recurring classes |
| City Tour | Adult / child pricing | Large groups | Multiple departures |
| Play Center | Hourly | Flexible capacity | Open hours |
| Equipment Rental | Hourly / daily | Inventory-based | Flexible duration |
| Adventure Sports | Group packages | Minimum participants | Booking cutoffs |
The problem
A growing platform chained by its system.
- One size no longer fit all
Over time Tripsome expanded into rentals, classes, events, and many other experiences. Each business expected the platform to work differently.
- Every new partner changed the rules
New businesses introduced different ways of pricing, scheduling, and operating. What worked for one partner often didn't work for the next.
- Growth came with trade-offs
Hardcoding exceptions beacme the default. It worked in the short term, but the 'defaults' kept piling up.
The scope
This wasn't just another listing creation flow.
this project was about defining how an activity works across the entire platform, not just how it is created.
The decisions made during setup become the rules that determine how partners operate, what customers can book, and what the platform can support in the future.
Designing this experience meant redesigning the foundation behind every booking, not just another form.
Why change?
The opportunities we were missing
I know it might seem unusual to give the "why" to this section instead of folding it into the problem.
The reason is simple: I don't believe every problem deserves a redesign, let alone a rearchitecture.
Before investing in a major platform change, let me play devil's advocate for a moment.
After all, if it works, don't touch it.
Were hardcoded exceptions really the bottleneck?
Or were we quietly limiting what the platform could become?
What the change makes possible:
- Growing with the business, not around it.
The platform needed to adapt without partners relying on us for every update.
- Selling experiences, not just tickets.
Most bookings ended with choosing a ticket and quantity. Experiences like extending time, purchasing additional attempts, or upgrades happened offline, limiting upsells and average order value.
- A platform that could keep evolving.
New customer experiences could be introduced without redesigning the platform again.
Implementation strategy
Planning for failure, not perfection.
Rebuilding the platform also meant rebuilding one of its core data models. A full migration assumed everything would work perfectly from day one, a risk I wasn't willing to take.
Instead, I proposed running the old and new systems side by side. Existing activities stayed on the current model, while new activities used the redesigned one. Older activities would then be migrated gradually, allowing us to validate the new architecture with real businesses before committing to a full migration.
Design principle
Designing around decisions, not database fields.
Instead of designing around database fields, I designed around partner decisions.
This approach was guided by five principles:
- Business-first design:
The setup revolves around five business questions: What are you offering? How do customers attend? When is it available? How much does it cost? What helps customers book?
- Progressive disclosure:
Allows partners to complete setup quickly for the common use cases, while advanced options are revealed only when needed.
- Flexible by default:
Supports multiple business models, pricing strategies, and attendance types without creating separate flows or hardcoded exceptions.
- Built for future scalability:
Makes it easier to introduce new business models by separating pricing, availability, and attendance.
- Reducing ambiguity:
Field labels, helper text, defaults, and terminology were refined to be clear and understandable.
Basic information
A straight forward step of what and where the activity is.
Photos
Help partners showcase the activity visually.
Availability
In this step user has to only fill attendance method and activity schedule. The rest of the settings are optional.
Pricing
Support different business models without separate flows.
Pricing was redesigned around modular rules instead of a single fixed price. Optional pricing layers appear only when needed, it might appear long but the user has to only fill 3 fields.
Description
Customer-facing content is collected separately from operational settings. This allows partners to focus on writing clear descriptions, highlights, and important details without unnecessary distractions.
Additional details
Optional settings and other operational details are grouped into a dedicated step. Keeping these separate prevents the core setup flow from becoming overwhelming.
Publishing
The final step lets partners publish immediately or schedule publication for later, with the option to automatically unpublish on a chosen date.
Trade-offs
The hardest decisions weren't visual-they were architectural.
The final experience looks straightforward, but reaching that simplicity required balancing competing priorities. Two decisions, in particular, shaped the final product.
Reducing cognitive load vs. simplifying editing
Initially, how customers attend and how the activity is priced were separate decisions under a dedicated How it works step. This reduced cognitive load by keeping pricing and availability focused only on their own settings.
The downside was that partners had to jump back and forth between Pricing and How it's priced, or Availability and How customers attend, whenever they wanted to change their business model.
I chose to move these decisions into their respective sections. While this slightly increased the complexity of the Pricing and Availability steps, it made editing much more intuitive.
Clear business concepts vs. avoiding conflicting configuration
Duration naturally belongs in Availability, but hourly pricing also depends on it. Keeping it in both places would've created conflicting rules.
Instead, the flow adapts. If an activity uses time slots, duration is configured in Availability and hourly pricing is disabled. Otherwise, partners can price by the hour or simply provide an estimated duration.
This gave customers a clear expectation of how long an activity takes, regardless of the business model.