Madrid PAU Design (Diseño) study materials
Madrid PAU Design (Diseño) study resources

App de reserva de pistas municipales: quitar el peaje antes de dar valor

Madrid PAU Design (Diseño) · Put your knowledge to work in context.

All case studies

App de reserva de pistas municipales: quitar el peaje antes de dar valor

El Ayuntamiento de Zaragoza lanza una aplicación para reservar pistas deportivas municipales. La usan 40.000 personas, muchas mayores de 60 años que reservan pistas de pádel y de petanca. Los datos del piloto son contundentes: el 38 % abandona en el segundo paso, el más frecuente es «iniciar sesión con Cl@ve», y el tiempo medio para completar una reserva es de 4 min 20 s. La app se usa sobre todo en Android de gama baja, con 3G y a menudo al aire libre con sol directo. El equipo de diseño ha propuesto botones de 32 px, texto gris claro sobre blanco, iconos sin etiqueta y un mensaje de error que dice «Error 403: sesión no válida». La accesibilidad del consistorio exige cumplir la norma EN 301 549 y el nivel AA de las WCAG 2.2. El cliente quiere mantener la posibilidad de reservar sin registro previo.

1. Identifica los tres problemas de usabilidad que explican el abandono y tradúcelos en decisiones concretas de diseño.

Read the worked answer

El abandono en el paso 2 no es falta de motivación: es que la app cobra un peaje (Cl@ve) antes de haber demostrado nada.

  1. Barrera de autenticación. El 38 % se pierde justo donde se pide el certificado. Decisión: reserva como invitado con nombre y teléfono o correo, y ofrecer «guarda mis datos» después de confirmar. Cl@ve solo para los trámites que la exijan legalmente.
  2. Legibilidad en exterior y baja visión. Botones de 32 px y gris claro sobre blanco incumplen los criterios de contraste y de tamaño de objetivo. Decisión: áreas táctiles de 48 × 48 dp con 8 dp de separación, texto base de 18 sp, gris #333333 sobre blanco (relación en torno a 12:1), peso medio en lugar de ligero para el sol directo e iconos siempre acompañados de etiqueta.
  3. Mensajes técnicos. «Error 403» no dice qué hacer. Decisión: lenguaje claro con acción: «No hemos podido validar tu sesión. Puedes reservar como invitado o volver a entrar», más botón de reintento y referencia de incidencia.

Extras obligados por el contexto: soportar el escalado de texto al 200 % sin romper la maquetación, imágenes por debajo de 100 KB y estados de carga visibles para la red 3G.

2. Rediseña el flujo de reserva sin registro previo, indicando número de pasos y qué información pides en cada uno.

Read the worked answer

Objetivo: pasar de cinco o seis pantallas a cuatro pasos más confirmación, con menos de 90 segundos.

  1. Deporte y pista. Las tres pistas más cercanas, con geolocalización opcional, y filtro por día. No se pide ningún dato personal.
  2. Día y hora. Calendario semanal con franjas libres y ocupadas; el color no va solo, se escribe «Libre 10:00-11:30». Al tocar, resumen flotante con precio.
  3. Datos mínimos. Nombre, teléfono y correo, con teclado numérico y autocompletado. Casilla «guardar mis datos para la próxima vez»: eso sustituye al registro.
  4. Pago y confirmación. Tarjeta o pago en pista; pantalla final con código de reserva en cuerpo grande, «añadir al calendario» y «compartir». Si el usuario se registra después, la reserva se asocia a su cuenta.

Decisiones justificadas: eliminar la elección previa de instalación (se deduce de la pista), no pedir contraseña, no usar gestos ocultos -el público mayor no los descubre- y mantener «atrás» siempre visible. Cada pantalla lleva «Paso 2 de 4» para reducir la incertidumbre, que es una de las causas de abandono en tareas largas.

3. ¿Cómo verificarías la mejora con usuarios reales y con qué métricas?

Read the worked answer

Antes de lanzar. Prueba de usabilidad moderada con 10-12 personas, la mitad mayores de 60 y al menos 2 con temblor o baja visión. Tarea: «reserva la pista de pádel del sábado a las 10:00». Métricas: éxito de la tarea (≥ 90 %), tiempo (≤ 90 s), errores y ayudas solicitadas, más un cuestionario SUS o SEQ de un ítem. Repetir en contexto: pleno sol, 3G limitado y texto al 200 %. Auditoría contra EN 301 549 y WCAG 2.2 AA (contraste, tamaño de objetivo, etiquetas accesibles, foco, TalkBack).

Después del lanzamiento. Analítica del embudo por paso (abandono y tiempo por pantalla), comparación A/B entre registro obligatorio y reserva como invitado, y tasa de reservas completadas sobre iniciadas. Encuesta de una pregunta tras la confirmación y seguimiento de las llamadas al consistorio, que son un indicador indirecto de fallo.

Criterio de éxito comprometido: bajar el abandono en el paso de identificación del 38 % a menos del 10 % y el tiempo medio de 4:20 a menos de 1:30. Si no se alcanza, el problema no era la interfaz sino el requisito de autenticación, y habría que renegociarlo con el ayuntamiento.