Caso de estudio · Micrositio de campaña
Un proyecto enfocado en decisiones prácticas y restricciones reales de un festival cultural independiente.
El festival tenía una agenda impresa en PDF y un formulario de Google para reservar entradas. La información llegaba tarde, los cambios de horario se comunicaban por redes sociales y el equipo organizador perdía horas respondiendo consultas repetidas por correo.
El encargo fue claro: centralizar la reserva de entradas por día y turno, mostrar la programación en tiempo real y reducir la carga administrativa del equipo.
Trabajamos con una paleta vibrante y tipografía display para reflejar la identidad del festival, pero el flujo de reserva se mantuvo deliberadamente sobrio: tres pasos, sin registro obligatorio y con confirmación inmediata por correo.
El mapa del recinto se construyó con marcadores por escenario y horario. Cada artista tenía una ficha breve con link a su perfil, y la agenda se actualizaba desde un panel interno sin necesidad de tocar el código.
El micrositio se desarrolló con un stack liviano: HTML semántico, CSS con variables y JavaScript vanilla para el filtrado de la agenda. La base de datos de reservas se manejó con una planilla sincronizada, lo que permitió al equipo modificar cupos y horarios sin depender de un desarrollador.
El mayor desafío fue el tiempo: el festival se anunció con seis semanas de anticipación y el sitio tenía que estar listo antes de la venta de entradas. Recortamos funciones secundarias, priorizamos el flujo de reserva y dejamos las animaciones decorativas para la segunda semana de desarrollo.
El flujo de reserva quedó operativo en tiempo récord. El equipo dejó de responder consultas por correo y los asistentes pudieron planificar su día con la agenda actualizada al minuto.
Proyecto 02
Un proyecto enfocado en decisiones prácticas y restricciones reales de calendario.
Un pequeño operador turístico de la costa necesitaba ordenar su temporada alta. Hasta ese momento, las reservas se manejaban por correo y una planilla compartida que cada semana terminaba con datos cruzados. El encargo fue claro: un flujo de reservas que funcionara sin depender de una persona específica.
Trabajamos con un calendario real de disponibilidad, bloques de temporada y reglas de pago por adelantado. La parte más delicada no fue el diseño, sino definir qué pasaba cuando un cliente quería mover una fecha ya confirmada.
En lugar de permitir cualquier fecha, el sistema muestra solo los rangos disponibles según la temporada. Esto redujo las consultas de clientes que intentaban reservar fuera de temporada.
El cliente elige fecha, ve el precio estimado y recién después ingresa sus datos. Separar la selección del formulario evitó abandonos por fricción innecesaria.
Definimos que los cambios de fecha se podían hacer hasta 7 días antes sin cargo. Después de eso, se trataba como nueva reserva. Esta regla se comunicó desde el inicio y evitó discusiones posteriores.
El flujo más simple no siempre es el mejor. En este caso, una regla de modificación explícita fue más valiosa que cualquier animación o efecto visual. El cliente sigue usando el sistema dos temporadas después.