Por qué elegí este problema
Buscaba un ejercicio que no se pudiera resolver con buen gusto. Tres cosas lo hacían interesante:
Es un producto obligatorio.
Nadie usa una app de aparcamiento por placer. No hay margen para encantar: o resuelve o estorba.
Está regulado hasta el detalle.
Las reglas existen, son públicas y no se pueden negociar. Eso convierte la investigación en lectura, no en suposición.
El diseño puede costar dinero real al usuario.
Un contador mal puesto es una multa. Eso obliga a un rigor que un producto de consumo no exige.
Y había una oportunidad de calendario: el contrato nuevo se adjudicó en junio de 2026 y la app llega con él. El problema estaba abierto y documentado.
El punto de partida
Zaragoza tiene desde 2014 una app oficial de estacionamiento regulado. Más de cincuenta mil usuarios y una queja que se repite en todas las reseñas: no te dice si sigues aparcado ni cuánto te queda.
En junio de 2026 el Ayuntamiento adjudicó un contrato nuevo que triplica largamente las plazas reguladas, integra la Zona de Bajas Emisiones e introduce modalidades que hoy no existen. Con él llega una app nueva.
La pregunta de diseño no era «cómo mejoramos esta app», sino «qué tiene que responder una app municipal de aparcamiento en el primer segundo».
Cómo trabajé
El orden importa más que las herramientas, así que lo dejo explícito:
Leer la normativa.
Reglamento, Instrucción Técnica y Ordenanza Fiscal, enteros.
Caminar los recorridos
antes de dibujar nada: primer uso en la calle, ampliar desde el aviso, pedir una autorización, mover el coche de zona, descargar mercancía. Escritos paso a paso, contando toques.
Sacar el inventario de pantallas de los recorridos,
y no al revés. Ahí aparecieron cuatro que no existían.
Tablas de estados
antes de la primera maqueta. La pantalla de inicio tiene doce, y solo cinco son el camino feliz.
Baja fidelidad con texto real.
Sin relleno: en este producto las palabras son el diseño.
Alta fidelidad y prototipo navegable
en HTML, un solo archivo, para poder enseñarlo en un móvil de verdad.
Traspaso:
tokens con nombres semánticos y hoja de textos con todas las cadenas, errores incluidos.
Las pantallas fueron el sexto paso de siete. Los cinco anteriores son los que explican por qué son así.
Los recorridos antes que las pantallas
Antes de dibujar nada caminé cinco recorridos de principio a fin, contando toques y anotando dónde falla cada uno. De ahí salió el inventario de pantallas, y no al revés: cuatro pantallas aparecieron porque el recorrido las pedía, no porque estuvieran en una lista.
Lo primero fue leer
Antes de dibujar nada leí el Reglamento Municipal entero, la Instrucción Técnica y la Ordenanza Fiscal. No fue diligencia: fue lo que más cambió el diseño.
Supuestos corregidos en la primera lectura
12
Funciones inventadas que hubo que tirar
4
De desviación en los precios que había supuesto
2×
Algunos ejemplos de lo que cambió:
El horario es partido,
de 9:00 a 14:00 y de 17:00 a 20:00. Mi primer diseño vendía tiempo continuo hasta las 20:00, lo que habría hecho pagar a la gente una franja gratuita.
La tarifa no sube a la misma hora en todas las modalidades:
a los 120 minutos en zona azul, a los 60 en naranja y a los 30 en alta rotación.
El precio es por minuto,
con un mínimo de 20. Los bloques de «30 min / 1 h / 2 h» me los había inventado yo.
La prohibición de reiniciar
exige dos condiciones a la vez, no una: menos de 60 minutos y menos de 200 metros.
La segunda hora en zona azul cuesta más del doble que la primera.
Seis usuarios, no uno
No inventé personas. El reglamento define seis perfiles con reglas distintas, y cada uno cambió pantallas de verdad: no es segmentación decorativa, es que el mismo botón hace cosas distintas según quién lo pulse.
Visitante ocasional
De pie en la acera, con prisa y a veces con lluvia. No conoce la zona.
La hora de fin manda sobre la duración: nadie piensa «noventa minutos», piensa «hasta la una y media».
Todo funciona sin cuenta hasta el momento de pagar. Pedir registro antes de mostrar nada mata la conversión.
El widget con la cuenta atrás en la pantalla de bloqueo, porque abrir la app ya es demasiado.
Residente
En casa, sin prisa. Lo que importa no son los segundos, sino no equivocarse ni repetir el trámite.
En su zona no compra minutos, compra bonos de día, cinco días o veinte. El selector de tiempo desaparece.
La solicitud enseña lo que la administración ya sabe —padrón, titularidad, pagos— y solo pide lo que falta.
El seguimiento dice qué pasa mientras tanto: sigues pagando como visitante. Sin esa frase, mucha gente deja de pagar.
Taller mecánico
Mueve coches de clientes todo el día. Tres matrículas a la vez y ninguna más de diez días seguidos.
Multivehículo real con contador de cupo visible: «1 de 3 en uso».
Un contador de días por matrícula, con aviso el día 9. Es un límite invisible que desautoriza el coche sin avisar.
Alta rotación bloqueada: el reglamento se la prohíbe, así que la app lo dice antes de que lo intente.
PYME itinerante
Electricista o fontanero con seis avisos al día. Aparca gratis, pero debe declararlo cada vez que cambia de zona.
La acción no dice «Aparcar» sino «Activar aquí · 0,00 €». El cero explica que es gratis; el verbo, que hace falta igual.
El cambio de zona es el disparador: la app detecta y pregunta, porque sin pago no hay fricción que recuerde nada.
El historial del día a la vista, para que preguntarlo por cuarta vez no parezca un fallo.
Repartidor
Entre quince y cuarenta paradas diarias. Treinta minutos por reserva, prorrogables quince una sola vez.
Inicio y pestañas propios: un botón grande y un contador. Ni mapa de zonas, ni saldo, ni denuncias en primer plano.
Aquí las chinchetas sí valen: las reservas están numeradas y el contrato exige detector de ocupación.
El aviso de que la reserva caduca y la plaza pasa a zona azul. Es el error más caro de este perfil y hoy no lo avisa nadie.
Empresa de carsharing
Vehículos sin conductor fijo, que declara la empresa. Aplazado a fase 2.
La pieza principal no es una pantalla, es una integración: nadie va a abrir una segunda app para declarar veinte minutos.
Las pantallas son de la empresa y sirven para una sola cosa: enterarse cuando la integración falla.
Aplazado a propósito: no se sabe si pagan o están exentos, y eso decide el modelo entero.
Las personas al uso —nombre, edad, aficiones— las haré cuando tenga entrevistas reales. Inventarlas ahora sería ponerle cara a una suposición.
Cómo sabré si funciona
Definir el criterio antes que la solución evita justificar a posteriori.
La prueba de los tres segundos.
Se enseña la pantalla de sesión activa, se retira, y se pregunta cuánto tiempo queda y hasta qué hora. Aprobado: cuatro de cada cinco aciertan las dos.
El resto de criterios están definidos y pendientes de la prueba.
Cinco decisiones
Decisión 01 de 05
El mapa no es una leyenda: es una respuesta
El contrato nuevo tiene cuatro modalidades de plaza más dos capas de restricción de acceso. Seis códigos visuales simultáneos, con el rojo ya ocupado por la marca municipal. Intenté resolverlo con la paleta durante un rato y no hay paleta que aguante eso.
La salida fue reformular la pregunta. El mapa no tiene que representar la normativa: tiene que responder «dónde puedo aparcar yo». Filtrado por vehículo y por condición del usuario, las cuatro modalidades colapsan en dos estados —puedes o no puedes— y se libera el canal de color para lo único que la gente busca: dónde hay sitio.
Quedan dos codificaciones ortogonales y ninguna más: color igual a ocupación, trazo igual a modalidad. Todo lo demás pasa a modos aparte, con píldoras en vez de casillas, porque una lista de capas invita a encenderlo todo a la vez.
Decisión 02 de 05
El tiempo se pausa, y eso puede costarte dinero
En Zaragoza, si no cancelas al cerrar el horario, el tiempo no consumido se congela y se reanuda al abrir el siguiente tramo. A mediodía es benigno: lo normal es volver.
Al final del día no. Alguien paga a las 19:50, se marcha, y a las 9:00 de la mañana siguiente su saldo empieza a consumirse en una calle donde ya no está el coche.
Una regla pensada para no perjudicar al ciudadano acaba perjudicándole si el software no la acompaña.
El diseño no puede cambiar la norma, pero sí proteger de ella. El aviso de las 19:50 no es neutro como el de mediodía: pregunta «¿te vas ya?» y pone finalizar como opción destacada. Y hay un segundo aviso a las 8:50, justo antes de que el contador arranque, que es la última oportunidad de recuperar el dinero.
Decisión 03 de 05
El sistema visual
Color. La identidad corporativa de Zaragoza es roja, y en una app que avisa de vencimientos y multas el rojo es el color que más falta hace para otra cosa. Probé tres caminos y ganó el neutro: acción en negro —que también es color corporativo, así que no requiere excepción— y rojo reservado a urgencia o consecuencia económica.
Tipografía. Entre las dos finalistas no decidí por estética: miré las tablas OpenType. DM Sans no incluye cifras tabulares —su «1» mide 0,342 em y su «0», 0,656—, y en un contador que cambia cada minuto el número baila en cada salto. Plus Jakarta Sans tiene tnum, mismo registro geométrico y licencia libre.
Logotipo. Tres direcciones: la inicial de la ciudad trazada como marca vial, una bahía de aparcamiento vista desde arriba y una plaza con un punto dentro. Las tres se leían a 26 píxeles, así que la decisión era de significado: la bahía se leía como un corchete y la plaza pedía aprendizaje. El logotipo de una app municipal debe decir Zaragoza antes que aparcamiento.
La regla que quedó escrita, para que sobreviva a quien la construya, es corta: si algo rojo no cuesta dinero ni tiempo, está mal puesto.
Decisión 04 de 05
Un set de iconos propio, validado a 23 píxeles
Los iconos genéricos cumplen, pero no dicen nada. Encargué un set propio y el proceso dio la lección más útil de todo el proyecto: un icono se juzga al tamaño al que vive, no al que se dibuja.
La primera ronda era impecable a 112 píxeles. A 23, que es el tamaño real en una barra de pestañas, se caía: Inicio se leía como un cero entre dos barras y Mapa como tres rayas diagonales. Seis de los catorce eran «un rectángulo redondeado dentro de otra cosa» y a ese tamaño colapsaban en la misma mancha.
El método que lo arregló fue medir en vez de opinar: rasterizar cada icono a 23 píxeles y comparar píxeles de tinta y centro óptico contra el resto del set.
Decisión 05 de 05
Los estados vacíos, o cómo cerrar una discusión con un número
Cuatro pantallas no tienen nada que enseñar: sin denuncias, sin vehículos, sin movimientos, y el buscador sin resultados. Son las que casi nadie diseña y, en esta app, dos de ellas son lo primero que ve alguien recién registrado.
Cada una tiene tres partes: una ilustración, una frase que dice qué significa el vacío, y otra separada que explica qué aparecerá ahí cuando haya algo. Esa tercera es la que convierte un hueco en una promesa, y la que se olvida siempre.
El criterio que evitó ocho rondas
La primera entrega era bonita y no servía: las cuatro eran casi el mismo dibujo. Discutirlo con adjetivos habría dado para semanas, así que lo convertí en una medida: rasterizar las cuatro a 132 píxeles, taparles el titular, y contar qué porcentaje de píxeles las diferencia.
Dos de ellas se distinguían en un 3,8%. Eran literalmente la misma imagen con el coche en línea continua o discontinua. Con ese número encima de la mesa, la conversación dejó de ser sobre gustos.
Aprobado: que ninguna pareja baje del 10%. La versión final queda en 10,5%.
Lo que hice mal
Un caso de estudio sin errores es un caso de estudio editado.
El resultado
Cinco recorridos caminados de principio a fin, un inventario de 28 piezas con sus estados, 72 pantallas en alta fidelidad y un prototipo navegable en un solo archivo.
Y tres entregables que no son pantallas y que suelen faltar:
Un mapa de cobertura
que dice, estado por estado, qué está dibujado y qué no. Un inventario que oculta sus huecos engaña a quien lo revisa.
Una hoja con todas las cadenas de texto,
incluidos los errores que nadie escribe hasta que fallan: tarjeta rechazada, etiqueta no consultable, cupo agotado.
Un archivo de tokens
con nombres semánticos —accion, alerta, marca— para que cambiar el color corporativo sea tocar cuatro valores y no repasar 72 pantallas.
Dos criterios que gobiernan todo
No existe «la tarifa de la zona».
El precio sale de la modalidad, el instante, la etiqueta ambiental del vehículo y la condición del titular. Ninguna pantalla muestra el precio de una calle; todas muestran el precio de esa calle para ese usuario con ese vehículo. La consecuencia técnica es que la tarifa es un servicio, no un campo de una tabla.
La accesibilidad no es una fase de pulido.
El Real Decreto 1112/2018 obliga a las apps del sector público al nivel AA, y su artículo 7 dice que la falta de prioridad, de tiempo o de conocimiento no justifica la excepción. Eso condiciona el primer token, no el último sprint: contraste mínimo, área táctil de 48, texto escalable al 200% sin romper, y ningún estado comunicado solo por color.
Qué gana quien lo paga
Esta app vive dentro de un contrato de concesión de 81 millones a diez años. Diseñar solo para el ciudadano sería diseñar la mitad del problema.
Rotación.
Es el objetivo declarado del servicio. Enseñar el escalón de tarifa antes de cruzarlo hace que la gente compre el tiempo que necesita; esconderlo y cobrarlo después recauda lo mismo una vez y genera una queja.
Menos reclamaciones.
El aviso antes de la pausa nocturna evita que alguien consuma saldo con el coche en otro sitio. Cada uno de esos casos, sin aviso, acaba en el 010.
Menos atención presencial.
La consulta de derechos y la solicitud con declaración responsable sacan de la oficina los trámites que hoy llenan la cola, y la Instrucción Técnica ya los permite por app.
Un diseñador que solo piensa en el usuario está diseñando interfaces. El producto aparece cuando las dos partes ganan con la misma decisión.
Lo que cambió respecto a la primera versión
Este proyecto ya lo había hecho una vez. En 2025 rediseñé la app existente analizando su interfaz: entradas, flujo de pago, jerarquía de la información. Salió un sistema coherente, con paleta azul y una pantalla de inicio de cinco entradas.
Volví a él en 2026, con el contrato nuevo adjudicado, y empecé por donde debí empezar la primera vez: leyéndome el reglamento. Media docena de decisiones de la primera versión no sobrevivieron.
Azul, sustituyendo al rojo corporativo
Cambiar el color de una marca municipal no es una decisión de diseño: es una que no te corresponde. La segunda versión mantiene el rojo oficial y lo reserva para urgencia y dinero.
Cinco entradas principales
Un menú no responde la pregunta que trae el usuario. La segunda versión abre con el veredicto: dónde estás, si se paga y cuánto.
Un precio por zona
El reglamento la calcula con cuatro variables: modalidad, instante, etiqueta del vehículo y condición del titular. No existe «la tarifa de la zona».
Continuo
Es partido, con un hueco gratuito de 14:00 a 17:00. La primera versión habría vendido tiempo que no hay que pagar.
Tres perfiles de conductor
La norma define seis con reglas distintas, incluidos repartidores, talleres y PYMES itinerantes. Tres de ellos necesitan pantallas propias.
Outfit
No incluye cifras tabulares. En una app cuyo elemento central es un contador que cambia cada minuto, eso no es un matiz.
La diferencia entre las dos versiones no es de gusto: es que la segunda leyó la normativa antes de dibujar.
Ninguno de los cambios salió de una crítica externa ni de un dato nuevo de usuarios. Salieron de un documento público que llevaba dos años publicado y que no me había leído. La primera versión resolvía bien un problema que no era el que había.
Qué haría distinto
Habría leído la normativa antes de la primera pantalla, y no en la segunda vuelta al proyecto. La tabla de arriba es la factura de no haberlo hecho: seis decisiones rehechas, un sistema visual entero y una semana de trabajo que se reaprovechó a medias.
Y habría validado antes. Tengo el criterio de aprobado escrito y el prototipo listo desde hace semanas; lo que falta son cuarenta minutos en la calle. Diseñar es lo cómodo, y enseñárselo a desconocidos es lo que mueve el proyecto. Es la deuda que tiene este caso y la primera tarea del siguiente.
Este caso está terminado como pieza de diseño y sin terminar como producto. Las dos cosas son ciertas a la vez, y decirlo me parece más útil que elegir una.