40 clics para pagar dos horas de aparcamiento

Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

6 de julio de 2026
40 clics para pagar dos horas de aparcamiento

La semana pasada estuve de vacaciones, y en varios pueblos he tenido que pelearme con el mismo parquímetro de una empresa bastante extendida en España. El desastre de experiencia de usuario se repetía pueblo tras pueblo.

El año pasado ya escribí sobre lo absurdo que es que en España sigamos atados a una sola app de pago según el municipio. Me sigo reafirmando en eso. Pero esta vez quiero traer una reflexión distinta, más de producto que de competencia: la importancia de contar los clics y los segundos que le cuesta a tu usuario ir desde que llega hasta que consigue lo que ha venido a buscar. En este caso, desde que llega al parquímetro hasta que sale el ticket.

Un flujo con demasiados pasos

Empecemos con el flujo por defecto, que ya venía cargado de fricción:

  • El idioma. La pantalla arrancaba en catalán. Si no lo conoces, el primer paso siempre era buscar el botón de cambiar idioma. Un botón que solo tenía el icono. Lo usable sería poner el icono con la palabra "Language".
  • La matrícula. Pedir la matrícula del coche me parece un paso innecesario para un turista. No le aporta valor.
  • Tarjeta o moneda. No debería ser un paso si no una acción que el usuario toma a la hora de pagar.
  • Los minutos. Y aquí está la joya: para elegir el tiempo de estacionamiento había un único botón de "más", que avanzaba de tres en tres minutos. Si querías aparcar dos horas, tenías que darle al botón unas cuarenta veces. Como le dabas de golpe, acababas pasándote y tenías que darle al botón de "menos" unas cuantas veces.

No sé quién diseñó esa interacción, pero lo normal habría sido dejar subir de media hora en media hora, con opción de ajustar después. Y, sinceramente, ni siquiera creo que ajustar al minuto tenga sentido: cuando no sabes exactamente cuánto vas a tardar, lo normal es dejar margen. Nadie pone 27 minutos si puede poner 30.

Cuando encima la tecnología falla

Sobre ese flujo ya de por sí largo, se sumaban dos problemas técnicos que se repetian:

Mala cobertura. Intentabas pagar con tarjeta y, si la conexión fallaba a mitad del proceso, el parquímetro no te ofrecía la alternativa de pagar con monedas o reintentar: te mandaba directamente al inicio. Vuelta a empezar todo el flujo.

Los triggers de seguridad de los bancos. Con una tarjeta de Revolut, el propio banco a veces desconfiaba de la operación y pedía una confirmación adicional. El problema es que ese flujo de confirmación no estaba contemplado por el parquímetro, así que la operación se cancelaba sola. Y aquí venía lo peor: una vez que el parquímetro fallaba por cobertura o por este tipo de rechazo, se quedaba bloqueado durante cinco minutos. Me lo confirmaron los propios revisores: es un tiempo de recuperación conocido y asumido.

Hubo un momento casi cómico en uno de los pueblos: unos diez turistas alrededor de un único parquímetro bloqueado, y un revisor de zona azul —un chaval joven, contratado para el verano— tan perdido como nosotros sobre qué hacer mientras la máquina se "recuperaba". Nadie sabía si esperar, buscar otra máquina por el pueblo o arriesgarse a la multa. Yo una vez desesperado porque había bloqueado tres parquimetros, acabé poniendo un cartel en mi coche diciendo que lo había intentado pero los parquimetros no funcionaban.

La lección de producto

Creo que esto es un ejemplo perfecto de un problema muy típico en diseño de producto: alguien diseñó este flujo sin pasar por la experiencia real de usarlo bajo presión, con tarjetas extranjeras y virtuales y en zonas de baja cobertura. Si quien lo diseñó hubiera cogido su propio coche y hubiera intentado pagar dos horas de aparcamiento, dudo mucho que el botón de "más" avanzara de tres en tres minutos.

La lección de siempre, pero que conviene repetir: hay que medir el número de clics y los segundos que le cuesta a un usuario completar la acción que ha venido a hacer, del principio al final del flujo. Y sobre todo, hay que usar el propio producto de primera mano, en condiciones reales, para entender qué funciona y qué no. Ese ejercicio tan simple evitaría buena parte de los problemas que van a vivir decenas de millones de turistaa este este verano en España.

También puede interesarte

Iterando el prototipo en vivo mientras los usuarios lo prueban

Siempre he hecho tests de usuario para diseñar mejor. Lo que no había vivido antes era poder implementar el feedback en la propia sesión. Lo que antes tardaba semanas, ahora sale en el día.

Quality vs. time to build is a false dichotomy

One of the traditional battles between PM and PD is how much to implement of a particular feature. This dichotomy has one central false assumption: If you do less, it means you are releasing with less quality.

Go faster by investing time on Research and Scope

At Ontruck, we spend less time on the Design and Build phase. And we spend more time on Research and Scope. Why do we work like this? Does this produce better outcomes?