Cinyx: rediseñé la compra de entradas de cine en una app móvil para que sea más rápida y clara. Un botón que propone los mejores asientos, compra como invitado y asientos accesibles, probado con cuatro personas.
Empresa
Cinyx · proyecto personal del curso de UX/UI
Duración
4 semanas
Rol
UX/UI Designer, proyecto individual
Proyecto
Resumen del proyecto
Cinyx es una app para comprar entradas de cine desde el celular. Partió de una compra de prueba y de reseñas reales para encontrar dónde se traba la compra, y diseñé el flujo completo en Figma hasta un prototipo interactivo.
El desafío
En una compra de prueba en Showcase, en Rosario, comprar una entrada llevó 16 pantallas y 30 taps. La selección de asientos fue el punto de mayor fricción, y 5 de las 8 reseñas de Google que revisé mencionan fricciones en el flujo de compra.
Mi rol y herramientas
Investigación, UX, UI y prototipado, todo de punta a punta. Herramientas: Figma, Google Drive y Framer, con IA como apoyo (Gemini, Claude y ChatGPT). Detalle en "Cómo usé IA".
Medir antes de diseñar
No hice entrevistas ni encuestas. La investigación se apoya en dos fuentes públicas: un recorrido completo del flujo de compra en Showcase, midiendo pantallas, taps y tiempo, y la lectura de 8 reseñas de Google.
Lo que encontré: - Una compra de prueba: 16 pantallas, 30 taps y unos 2 minutos. - 5 de las 8 reseñas mencionan fricciones en el flujo de compra. - 1 estrella: "Insoportable. Quiero comprar entradas y la única forma es descargar una aplicación. No quiero tu membresía, quiero ir UNA VEZ al cine." - 3 estrellas: "…Pero quisiera saber por qué la web no ofrece la opción de entradas para personas con discapacidad. Omitir esa opción invisibiliza." - 2 estrellas: "…El sistema para elegir el asiento no te deja ver qué asientos están disponibles así que una vez que cargaste todos los datos podés ver la disponibilidad en la sala."
Límite: son datos de un solo recorrido y de reseñas públicas, no de entrevistas. Por eso la persona que sigue es una hipótesis a validar.
Una hipótesis: Sara
Sara, 27 años, Rosario. Content creator y universitaria. Después de un día agotador quiere desconectar viendo una película y resolver todo rápido desde el celular. Busca elegir el mejor asiento sin esfuerzo y completar la compra en poco tiempo. La frustran un mapa de asientos desordenado, no saber cuáles son los mejores lugares y un proceso largo para algo simple.
Sara es una proto-persona: la armé con el recorrido en Showcase y las reseñas, no con entrevistas. Sus frases son hipótesis, no citas de usuarios.
¿Cómo podríamos ayudar a una persona cansada a comprar entradas y elegir buenos asientos con menos pasos y menos decisiones?
De bocetos a un prototipo que se prueba
Diseñé todo yo sola, de punta a punta, y este fue mi orden real:
Partí de un problema que viví como usuaria. Me pasaba a mí al comprar entradas, y lo contrasté con una compra de prueba (16 pantallas y 30 toques) y con las reseñas de Google.
Storyboard con Sara. Creé el personaje para imaginar su recorrido y ponerme en su lugar.
Arquitectura de la información. Definí cómo iban a organizarse las secciones y los contenidos de la app antes de dibujar pantallas.
Bocetos en papel (sketches). Exploré pantallas probando y descartando, sin pensar en estilo.
User flow. Con el recorrido en papel armé el flujo del usuario y ajusté las pantallas y su secuencia.
Sitemap. Cerré el mapa de pantallas y recién ahí pasé a los wireframes.
Wireframes de baja fidelidad (lo-fi) y primer prototipo. Validé la estructura y la jerarquía en gris, sin color ni imágenes.
Diseño de alta fidelidad y UI kit en Figma. Definí paleta, tipografía y componentes reutilizables, y los apliqué en todas las pantallas. Para las herramientas de Figma que no manejaba me apoyé en Gemini, en videos de YouTube y en el curso de UX/UI.
Prototipo final y pruebas. Con todas las pantallas de alta fidelidad armé el prototipo interactivo y recién ahí hice los tests de usabilidad. Después sumé a Claude como segunda opinión para ver qué se podía mejorar.
Cuatro decisiones
a) Un CTA que propone los mejores asientos
Problema: elegir asientos en el mapa lleva tiempo y no queda claro cuáles son los mejores.
Decisión: "Elegir los mejores asientos" es el CTA principal: propone lugares juntos y en el centro. "Elegir en el mapa" queda como CTA secundario. Un microcopy bajo el botón explica el criterio. Al principio los labels eran "Elegir por mí" y "Ver mapa": Guido no sabía si el "mí" era él o el sistema, y Giuliana no entendía qué decisión tomaba con cada botón. Reescribí el microcopy y Guido lo volvió a probar: dijo que ahora se entiende que es un selector con ayuda inteligente.
Evidencia: en el prototipo el selector lleva 8 taps y el mapa 11. Guido terminó la tarea en 26 segundos con el selector y Giuliana en 37,45 eligiendo manualmente. Son dos personas, así que es una referencia y no una comparación.
b) Compra como invitada (guest checkout)
Problema: pedir registro antes de comprar es una barrera de entrada para quien solo quiere ir al cine y puede provocar abandono.
Decisión: "Continuar como invitada": con un correo para recibir las entradas alcanza.
Evidencia: las cuatro personas que probaron el prototipo compraron como invitadas y funcionó bien. Fue el único flujo que probamos, así que no lo comparé con el de registrarse.
c) Cambiar asientos sin volver atrás
Problema: si la sugerencia no convence, tener que empezar de nuevo hace perder tiempo y ganas de comprar.
Decisión: cuando propone asientos, Cinyx explica el motivo con un mensaje claro (por ejemplo: "No hay 3 asientos juntos en el centro. Te sugerimos la fila F, un poco más atrás") y deja siempre a la vista dos acciones secundarias: "Cambiar asientos", que lleva al mapa para elegir a mano, y "Cambiar de función". La persona mantiene el control y decide sin volver atrás.
Evidencia: lo probé yo y también Guido, cuando volvió a probar el prototipo con las mejoras del botón, y funcionó: lleva a elegir los asientos manualmente. Es un edge case y falta probarlo con más personas.
d) Asientos accesibles y amplios
Problema: un mapa donde todos los asientos son iguales deja afuera a quien necesita espacio para silla de ruedas o un asiento más ancho. Una reseña de Google señala que omitir esta opción "invisibiliza".
Decisión: sumé asientos accesibles y amplios en la primera fila, con el símbolo de silla de ruedas, y los expliqué en la leyenda. Tuve en cuenta la accesibilidad en el uso del color: cada tipo de asiento tiene un símbolo o una forma distinta, y la leyenda lo nombra con texto, así que la información no depende solo del color.
Evidencia: todavía sin validar. No lo probé con personas que usen silla de ruedas ni con lectores de pantalla, y todavía no revisé el contraste de color, el tamaño de las áreas táctiles (touch targets) ni la legibilidad de los textos. Es lo primero que quiero validar, y también que el selector no proponga asientos accesibles salvo que la persona los pida.
Sistema de diseño
Los mismos componentes se repiten en todas las pantallas para que el producto se sienta coherente.
Inconvenientes que aparecieron y cómo los resolví
Pantallas que eliminé. En el papel había un menú hamburguesa (un menú lateral desplegable, o navigation drawer) con las opciones de perfil, cartelera y promociones. Lo reemplacé por una barra de navegación inferior fija (bottom navigation), para que las secciones principales estén siempre a la vista y a un toque. También tenía una pantalla separada de "película" y otra de "cartelera": las mejoré y las unifiqué en la cartelera actual.
El bottom sheet de la función quedaba muy abajo. Federico y Lorena, por separado, señalaron lo mismo: en el celular había que hacer scroll para ver los datos de la función, que quedaban fuera del primer pantallazo (below the fold). Quedó como próximo paso reposicionar el bottom sheet.
La barra de navegación no quedaba fija. Muchas veces se movía y quedaba un espacio abajo, y la Home no se comportaba bien al hacer scroll. Ajusté la jerarquía de capas para que el contenido haga scroll por debajo de la barra, fijándola con constraints. En ese tramo me apoyé en Gemini y revisé cada cambio yo.
La grilla de asientos era difícil de mantener. Armarla con butacas sueltas era difícil de escalar. La rehice con componentes, variantes y Auto Layout, que además permitieron manejar los estados (libre, ocupado, seleccionado, accesible, amplio) de forma ordenada.
Un prototipo no es la compra real. No incluye correo ni pago, así que la comparación de 16 a 8 pantallas es orientativa, no un resultado medido.
Lo que mostraron las pruebas
Hice tests de usabilidad del prototipo con 4 personas. Lorena dijo que "siempre supo qué hacer" y que confió en el botón. Federico y Lorena señalaron el mismo problema: el bottom sheet de la función aparece muy abajo en la pantalla del celular.
Resultados
En el prototipo, comprar como invitado lleva 8 pantallas y 8 taps (11 con el mapa), contra 16 y 30 en la compra de prueba. Cuatro personas lo probaron y sus comentarios cambiaron el diseño.
16 → 8: menos pantallas por compra
30 → 8: menos taps por compra
Nota: el prototipo no incluye correo ni pago, así que la comparación es orientativa.
Menos pantallas por compra
Menos toques por compra
Aprendizajes, próximos pasos y uso de IA
Lo que aprendí
Medir pantallas y taps en un recorrido real me dio un punto de partida concreto.
Dos personas distintas, Federico y Lorena, señalaron el mismo problema con el bottom sheet de la función.
Sara es una hipótesis. La armé sin entrevistas, y es el mayor límite del caso.
Próximos pasos
Reposicionar el bottom sheet para que la información clave se vea sin scroll en celulares.
Hacer tests de usabilidad de los asientos accesibles y amplios con personas que los necesiten, y revisar contraste y áreas táctiles.
Entrevistar a usuarios reales para reemplazar a Sara por una persona basada en datos propios.
Cómo usé IA
Uso IA como herramienta de trabajo y la dejo a la vista. Las decisiones de diseño y los datos del caso son míos. El proyecto empezó sin IA y fui sumando Gemini, ChatGPT y Claude a medida que me animé.
Claude, como segunda opinión: después de probar el prototipo, para detectar qué mejorar, y también para ordenar el caso y revisar textos.
Claude, en Figma: para tareas repetitivas, como armar las variantes de los asientos y las leyendas.
Gemini, en el prototipado de Figma: para destrabar el scroll de la Home, fijar la barra de navegación con constraints, ordenar capas y estructurar la grilla de asientos, el bottom sheet, el checkout y los auto layouts.
Decidí yo: a qué problema apuntar y qué dejar afuera, el recorrido en Showcase, las reseñas y las pruebas con personas, y qué cambiar después de cada prueba.
Cierre
Más proyectos: GoCamp en desarrollo.
Me gusta entender el problema antes de diseñar. Si buscás a alguien así para tu equipo, escribime.
