CheSafari

Turning fragmented event listings into a location-aware cultural discovery product

CheSafari helps people discover live events around them without requiring them to know exactly what to search for. I designed and built the product from the data model upward: ingestion and normalization, location logic, discovery patterns, responsive interaction, and the operating tools needed to keep the information trustworthy.

I turned scattered cultural listings into a map people can explore, trust, and act on.

The interface was only as reliable as the data behind it

Local event information arrives fragmented across ticketing platforms, venue pages, and scraped sources. Names conflict, locations are incomplete, and duplicated venues can send people to the wrong place. A polished search interface would only make unreliable information look authoritative.

Discovery quality is a data-product problem before it is an interface problem.

I treated venue identity separately from the geographic labels used to describe it. Provider identities remain evidence, while editorial geography can be corrected without silently rewriting the source. That distinction gave the system a safer way to reconcile contradictory information.

I designed the system before compressing it into screens

The product architecture connects providers, events, venues, artists, geographic entities, editorial rules, and user actions. Mapping those relationships exposed where automation was safe and where a human decision needed to remain visible and reversible.

The first wireframes tested one central interaction question: how can the map, event list, and event detail behave as one workspace instead of three disconnected pages?

The map gives context. The list supports scanning. The detail enables a decision.

One discovery model, adapted to the moment of use

On desktop, the persistent multi-panel layout lets people move between overview and detail without losing geographic context. On mobile, the same information model becomes a more focused sequence: explore, inspect, decide, and continue toward the ticket provider.

Responsive design was not a smaller layout. It was the same decision model, reprioritized.

A small system keeps the experience coherent

Reusable states, semantic colors, keyboard focus, touch targets, and predictable feedback turn the visual language into product behavior. The button specification is a small example of how accessibility and implementation rules were documented alongside appearance.

The most useful validation happened outside the design file

We used CheSafari to discover real events in Córdoba, buy a ticket and find out venue locations. That journey proved the core loop could create value—and immediately exposed the next problems: ambiguous venues in external navigation, weak geographic recovery, and opportunities for clearer ticket handoff and timely reminders.

The product helped me find and attend a real event. The field test then revealed what the interface alone could not.

Those observations shifted the roadmap toward stronger venue identity, clearer ticket CTAs, event reminders, and more reliable navigation handoff.

What this project demonstrates

CheSafari is an ongoing product, not a finished concept. It demonstrates how I work across product strategy, information architecture, data constraints, interaction design, systems thinking, and implementation—while keeping the user-facing experience deliberately simple.

Complexity belongs in the system. Clarity belongs in the experience.