SimplePass
Rediseñé el ecosistema de SimplePass: una plataforma web para crear, vender y gestionar eventos, y una app operativa para que los equipos trabajen durante la noche del evento. El proyecto incluyó auditoría, rediseño UX/UI, componentes reutilizables, handoff a desarrollo y una experiencia actualmente usada en eventos reales.
Contexto
SimplePass es una plataforma de ticketing y gestión de eventos que combina dos momentos muy distintos del mismo negocio.
Por un lado, productores y organizadores necesitan crear eventos, configurar entradas, administrar precios, gestionar equipos, revisar ventas y entender la performance antes y después del evento.
Por otro lado, durante la noche, los equipos operativos necesitan validar accesos, revisar listas, coordinar tareas, controlar consumiciones y resolver situaciones rápido, muchas veces bajo presión, con ruido, poca luz y poco margen de error.
El desafío era diseñar una experiencia que funcionara antes, durante y después del evento sin mezclar prioridades.
La plataforma web tenía que ayudar a planificar y tomar decisiones. La app operativa tenía que ayudar a ejecutar sin fricción.
El problema
SimplePass no era un solo producto. Era un sistema con usuarios, momentos y niveles de presión completamente distintos.
El productor trabaja con anticipación: crea eventos, configura tickets, define precios, revisa ventas, organiza equipos y necesita entender si todo está listo antes de abrir puertas.
El equipo de evento trabaja en vivo: escanea QR, valida accesos, revisa listas, resuelve excepciones, coordina tareas y necesita confiar en información mínima, clara y rápida.
El problema aparecía cuando esos contextos se mezclaban. Una interfaz útil para planificación puede ser demasiado lenta o cargada para una persona en puerta. Y una interfaz optimizada para ejecución puede quedarse corta para quien necesita analizar ventas, configurar entradas o detectar riesgos operativos.
Además, había flujos con jerarquías poco claras, falta de estados visibles, roles y permisos que necesitaban ordenarse, y procesos críticos como validación de accesos o gestión de equipos que no podían depender de interpretación.
Approach
Dos principios guiaron el rediseño.
Planificar y ejecutar no son el mismo modo mental. La web debía servir para pensar, configurar y analizar. La app debía servir para actuar. Intentar resolver ambos momentos con la misma lógica hubiera creado una experiencia más pesada para todos.
Durante el evento, menos información puede ser mejor información. En contexto operativo, la interfaz no tiene que mostrar todo. Tiene que mostrar lo necesario, en el momento correcto, con suficiente claridad para tomar una decisión rápida.
El trabajo empezó con una auditoría del producto existente para entender flujos, puntos de fricción, jerarquías y decisiones abiertas. A partir de eso, rediseñamos la plataforma web, la app operativa, los componentes reutilizables y el sistema de handoff para desarrollo.
Decisiones clave
Dividir los flujos por momento de uso
La primera decisión fue separar claramente la experiencia de planificación de la experiencia de ejecución.
La plataforma web quedó orientada a productores y organizadores: crear eventos, configurar fecha, lugar, capacidad, tipos de entrada, precios, descuentos, invitaciones, consumiciones, equipos, venta online, reportes y performance.
La app operativa quedó orientada al equipo que trabaja durante el evento: validación de QR, control de accesos, listas, asistencia, tareas, consumiciones, incidencias y estado del evento en vivo.
Esa separación permitió que cada producto respondiera a su contexto real.
Lo que descartamos: diseñar una sola experiencia que intentara resolver todo. En eventos, el contexto cambia demasiado. Antes del evento necesitás control y configuración. Durante el evento necesitás velocidad y confianza.
Diseñar para velocidad operativa durante el evento
La noche del evento no es un contexto amable para la interfaz.
El equipo puede estar en puerta, con fila, ruido, baja luz, presión de tiempo y personas esperando una respuesta inmediata. En ese contexto, una pantalla cargada no es más completa: es más riesgosa.
La decisión fue reducir la información visible al mínimo accionable. Estados claros, validaciones rápidas, feedback inmediato y jerarquías simples para que el usuario pudiera saber si una persona entra, si hay un problema o si necesita resolver una excepción.
Lo que descartamos: trasladar la complejidad de la plataforma web a la app operativa. El equipo de puerta no necesita analizar el negocio. Necesita tomar decisiones rápidas y confiables.
Hacer visibles los riesgos operativos antes del evento
Muchos problemas de la noche del evento empiezan antes: una entrada mal configurada, un equipo incompleto, una capacidad mal cargada, una lista desordenada o un estado de venta que no se revisó a tiempo.
La decisión fue hacer más visibles esos riesgos en la plataforma web. Estados de venta, accesos, configuración, equipos, capacidad y performance debían ayudar al productor a detectar problemas antes de que llegaran al evento.
El objetivo no era solo administrar eventos, sino anticipar fricciones operativas.
Lo que descartamos: tratar los estados como información secundaria. En este tipo de producto, un estado mal comunicado puede convertirse en un problema real durante la operación.
Ordenar roles y permisos según responsabilidad
No todas las personas que participan de un evento necesitan ver ni hacer lo mismo.
Un productor necesita visión general. Un coordinador necesita controlar equipos y resolver problemas. Una persona de puerta necesita validar accesos. Alguien de barra puede necesitar consumiciones. Un RRPP puede necesitar ver su lista o rendimiento.
La decisión fue diseñar la experiencia considerando responsabilidades distintas, para que cada perfil pudiera acceder a lo necesario sin cargar con herramientas que no le correspondían.
Lo que descartamos: una lógica plana donde todos los usuarios tienen la misma experiencia. En operación de eventos, dar acceso de más puede generar ruido, errores o pérdida de control.
Solución
El resultado fue un sistema rediseñado para cubrir el ciclo completo del evento.
En la plataforma web, productores y organizadores pueden crear eventos, configurar entradas, precios, descuentos, invitaciones, consumiciones, equipos, listas, ventas y reportes. La experiencia prioriza planificación, control y lectura de performance.
En la app operativa, los equipos pueden trabajar durante la noche con una interfaz más rápida y directa: validación de QR, control de accesos, listas, tareas, consumiciones, incidencias y estado del evento en vivo.
El sistema visual mantuvo una identidad marcada de SimplePass, con una dirección moderna, clara y preparada para crecer. También se trabajaron componentes reutilizables y handoff a desarrollo para sostener consistencia entre web y app.
La solución no intentó unificar todos los contextos en una misma interfaz. Los conectó dentro de un mismo ecosistema, pero respetando que planificar un evento y operarlo en vivo son trabajos distintos.
Impacto
El rediseño fue implementado y actualmente se usa en eventos reales.
La plataforma quedó más ordenada para crear, vender y gestionar eventos, con una estructura más clara para productores y organizadores.
La app operativa quedó mejor preparada para contextos de alta presión, donde la velocidad, la claridad y la confianza en la información son críticas.
El proyecto también dejó una base de componentes y jerarquías reutilizables para seguir escalando el producto, sumar nuevos tipos de eventos, roles o funcionalidades sin romper la experiencia existente.
Más que un rediseño visual, SimplePass pasó a tener un sistema más coherente para operar el antes, durante y después de un evento.
Reflexión
SimplePass me recordó que el contexto de uso puede cambiar por completo la definición de una buena interfaz.
La misma información que es útil para un productor frente a una computadora puede ser ruido para una persona validando accesos en puerta. Diseñar bien no era mostrar más. Era entender cuándo mostrar menos.
También fue un proyecto donde la separación de momentos de uso se volvió clave. Antes del evento, el producto tiene que ayudar a anticipar. Durante el evento, tiene que ayudar a actuar. Después del evento, tiene que ayudar a leer resultados.
Lo que haría diferente: hubiera documentado más profundamente desde el inicio la lógica de roles y permisos. En productos operativos, esa capa suele parecer secundaria al principio, pero termina definiendo gran parte de la experiencia real: quién puede ver qué, quién puede resolver qué y qué información necesita cada persona para hacer bien su trabajo.
