Este proyecto lo diseñé dos veces. La primera, en 2025, salió un sistema coherente, con buena jerarquía y una paleta cuidada. La segunda, en 2026, empecé por leer el reglamento municipal, y doce de los supuestos de la primera versión resultaron estar mal. La primera versión resolvía bien un problema que no era el que había.
Esa diferencia no fue de talento ni de herramientas. Fue de orden. Este artículo no va de la app (para eso está el caso de estudio), sino del proceso que usé en la segunda vuelta: una secuencia en la que nada pasa a la fase siguiente sin superar un punto de control.
1. Leer la norma antes de abrir ninguna herramienta
En un producto regulado, la investigación no empieza por los usuarios, empieza por la norma. Leí enteros el Reglamento, la Instrucción Técnica y la Ordenanza Fiscal antes de dibujar nada.
Fue lo que más cambió el diseño. El horario es partido, con un hueco gratuito a mediodía, y mi primera versión habría vendido ese tiempo. El precio es por minuto, y los bloques de «30 minutos, 1 hora, 2 horas» que yo había dibujado me los había inventado. Y los usuarios no eran tres perfiles de conductor: la norma define seis, con reglas distintas, incluidos repartidores, talleres y autónomos que se mueven por la ciudad.
Punto de control: no diseño ninguna regla sin saber de qué artículo sale.
2. Caminar los recorridos antes de dibujar pantallas
Antes de la primera maqueta escribí cinco recorridos completos, paso a paso, contando toques y anotando dónde fallaba cada uno: el primer uso en la calle, ampliar el tiempo desde un aviso, pedir una autorización, cambiar de zona, descargar mercancía.
El inventario de pantallas salió de ahí, y no al revés. Cuatro pantallas aparecieron porque el recorrido las pedía, no porque estuvieran en una lista. Y antes de dibujarlas, cada una tuvo su tabla de estados: la pantalla de inicio tiene doce, y solo cinco son el camino feliz.
Punto de control: ninguna pantalla existe si no la pide un recorrido.
3. Definir el aprobado antes que la solución
Antes de diseñar la pantalla principal escribí cómo sabría si funcionaba. Se enseña la sesión activa, se retira, y se pregunta cuánto tiempo queda y hasta qué hora. Aprueba si cuatro de cada cinco personas aciertan las dos cosas.
Fijar el criterio antes evita el vicio más cómodo del diseño: justificar a posteriori lo que ya te gustaba.
4. Escribir el texto real desde el boceto
En esta app, las palabras son el diseño. Un botón que dice «Activar aquí · 0,00 €» explica a la vez que la acción es gratis y que hace falta igual. Ningún bloque de texto de relleno habría dejado ver eso, así que la baja fidelidad se hizo con los textos definitivos.
5. Decidir y descartar por escrito
Cada decisión importante quedó documentada junto a la alternativa rechazada y su motivo. Di por hecho durante días que los trámites exigirían Cl@ve, hasta que la Instrucción Técnica me mostró que basta una declaración responsable; exigir certificado habría dejado fuera justo a quien más necesita las bonificaciones. El carsharing quedó para una segunda fase porque la norma no aclara si los operadores pagan, y esa respuesta decide el modelo entero.
Escribir el descarte parece trabajo extra. Es lo que permite volver semanas después sin repetir la discusión, y lo que convierte un diseño en algo defendible ante un equipo técnico o un responsable municipal.
Punto de control: si no sé explicar por qué descarté la alternativa, todavía no he decidido.
6. Revisar el conjunto, no solo las piezas
Revisé cada pantalla antes de pasar a la siguiente, pero el fallo más importante no salió de ahí. Había quitado la pantalla de confirmación tras aparcar, con el argumento de que ver el contador corriendo ya confirmaba. Revisada suelta, la pantalla era correcta. Navegando el prototipo completo, en cambio, la duda aparecía sola: la pantalla cambiaba, pero no quedaba claro que fuera por lo que acababas de pulsar. Con un pago de por medio, esa duda es legítima.
La solución fue un aviso temporal que confirma sin interrumpir, con el importe dentro y diez segundos para deshacer al finalizar. La lección de método es otra: hay errores que solo existen entre pantallas, y para verlos hay que recorrer el producto como lo recorrería alguien.
7. Medir lo que el ojo no ve
Hay decisiones visuales que no se pueden juzgar mirando. La primera ronda de iconos era impecable al tamaño de diseño. A 23 píxeles, su tamaño real en la barra de pestañas, seis de los catorce se convertían en la misma mancha. Rasterizarlos y medir la tinta y el centro óptico de cada uno lo hizo evidente.
Con las ilustraciones de los estados vacíos, en lugar de discutir con adjetivos, fijé un número: ocultando los títulos, ninguna pareja podía diferenciarse en menos de un 10% de sus píxeles. La primera entrega tenía dos que se diferenciaban en un 3,8%. Con ese dato sobre la mesa, la conversación dejó de ser de gustos.
Medir también sirve para corregirse a uno mismo. Rechacé un icono por pesar mucho menos que otro, y al medir el set completo resultó que estaba en la mitad del rango: mi objeción se basaba en comparar solo los dos extremos. Retiré la objeción. En el logotipo cometí dos errores de geometría que solo se confirmaron rasterizando el archivo final. Parte del trabajo visual lo hice colaborando con herramientas de IA, y por eso mismo la verificación era innegociable: producen resultados convincentes muy rápido, pero el criterio sigue siendo de quien diseña.
Punto de control: si algo se puede medir, no lo apruebo a ojo.
8. Entregar también lo que no son pantallas
El proceso termina con tres piezas que casi nunca aparecen en un portafolio: un mapa de cobertura que dice qué estados están dibujados y cuáles no, una hoja con todos los textos de la app (errores incluidos) y un archivo de tokens con nombres semánticos. Son las que permiten que otra persona construya el producto sin tener que adivinar.
Los límites de este proyecto
Nadie ha probado estas pantallas en la calle. Todo lo anterior reduce el riesgo, pero criterio apoyado en normativa no es lo mismo que evidencia. El siguiente paso está definido y es pequeño: la prueba de los tres segundos sobre la pantalla de sesión activa, con desconocidos, en una zona regulada. Cuarenta minutos que siguen pendientes, y que son la primera tarea antes de dar el diseño por bueno.
Tampoco es un proyecto hecho en equipo. En un contexto real, estos puntos de control no serían una lista personal, sino acuerdos con desarrollo, negocio y el cliente público: qué se revisa, quién lo aprueba y con qué criterio. Precisamente por eso me parece útil haberlos escrito. Un método explícito se puede compartir; uno intuitivo, no.
Lo que me llevo
Cuatro principios que ya aplico fuera de este proyecto. Leer las reglas antes de dibujar, porque las restricciones son parte del diseño. Sacar las pantallas de los recorridos, y no los recorridos de las pantallas. Escribir por qué descarto, no solo lo que elijo. Y medir lo que se pueda medir, sobre todo cuando las herramientas producen resultados convincentes muy rápido.
El resultado completo, con las pantallas, el prototipo y las decisiones en detalle, está en el caso de estudio.

