Case study · 2025
Mobile App
UX Research
Design System
Dark Mode
Rol
UX/UI Design
Illustrator
Equipo
Trabajo individual
Herramientas
Figma (Auto Layout & Variables)
FigJam
Contexto
Diseñé Madrid Parking a partir de mi TFG, con el objetivo de transformar la movilidad en la ciudad. Una aplicación que sustituye las dudas al volante por un guiado claro: detecta los permisos de tu coche, te alerta antes de entrar en calles restringidas y simplifica la búsqueda de plaza mediante avisos rápidos y un diseño limpio.
01 / el problema
Aparcar en Madrid se ha convertido en un auténtico dolor de cabeza.
Entre las distintas tarifas (zona verde y azul), los límites de tiempo y las restricciones de acceso según la etiqueta de tu coche, encontrar sitio genera estrés, pérdida de tiempo y la preocupación constante de meterte por una calle no permitida y recibir una multa.
02 / La solución
Una app pensada para consultar en segundos y sin distracciones.
Inspirada en el guiado de los parkings privados, te muestra en tiempo real solo las zonas y plazas donde puedes aparcar según el distintivo de tu coche, te avisa antes de entrar en calles restringidas y te permite gestionar el parquímetro y anticipar atascos desde un mismo lugar.
[01]
Case study
Investigación UX.
Investigué el proyecto con la metodología Design Thinking, combinando investigación de campo, análisis de la competencia y herramientas de síntesis para entender las fricciones reales del conductor y priorizar soluciones que eliminen el estrés y la incertidumbre en la ciudad.
Metodologías Design Thinking
Investigar:
Desk Research
Netnografía
Benchmarking
DAFO
Research Questions
Encuestas
Entrevistas
Sintetizar:
User Personas
Mapa de Empatía
Customer Journey
Matriz de Necesidades
Ideación:
Findings & Insights
Matriz In-Out
Moskow
Business model
Arquitectura de Información
UI & Validación:
Wireframing
Atomic Design
Design system
Test de Usabilidad
Síntesis de entrevistas y encuestas
Investigación UX
¿Qué necesitan realmente los conductores?
Aparcar en las ciudades es un problema desde los años 60. Sintetizo entrevistas y encuestas para entender qué lo hace tan difícil hoy en Madrid.
Hallazgos clave
01
Pain point
Gestionar las zonas SER genera estrés real
Gestionar las zonas SER y los distintivos DGT genera estrés en la mayoría de conductores, que además duda con frecuencia si puede entrar en Madrid Centro por la señalización confusa.
02
Necesidad
Quieren pagar el parquímetro sin moverse del coche
Todos los entrevistados pagan o están interesados en pagar desde una app — solo el 16% prefiere seguir usando el parquímetro físico.
78%
De los conductores experimenta estrés al interpretar zonas SER y distintivos DGT
83,3%
De los usuarios encuestados no tiene etiqueta Eco — tienen tipo C o B
100%
De los encuestados cree útil que la app avise al entrar en una zona no permitida para su vehículo
El hallazgo que lo cambió todo: las funciones “secundarias” —avisos de Madrid Central, trayecto asistido, pago remoto— importaron más a los usuarios que la idea original de ayuda para aparcar.
Customer Journey
01. Antes del trayecto
Acción
Necesidad de ir al centro en coche; duda sobre el tráfico. Descarga la app
Pensamiento
«¿Puedo entrar al centro con mi coche? Seguro que hay atasco y no sé dónde aparcar.»
Emoción
Frustración inicial
Oportunidades UX
Difundir la app y clarificar los permisos de circulación de forma intuitiva.
02. Registro
Acción
Apertura de la app y configuración de la etiqueta ambiental y datos del coche.
Pensamiento
«Qué pereza meter tantos datos antes de empezar a conducir…»
Emoción
Pereza, confusión
Oportunidades UX
El registro del coche debe de tener un flujo agil, para no frustrar al usuario al inicio.
03. En ruta
Acción
Conducción hacia el destino con la app activa. Recibe alertas de atasco
Pensamiento
«Genial el aviso de atasco, me ahorro dar vueltas innecesarias.»
Emoción
Confianza
Oportunidades UX
Alertas contextuales: avisos claros de atascos y calles con acceso restringido
04. Estacionamiento
Acción
Llegada a la zona de destino y búsqueda de plaza libre.
Pensamiento
«La app me indica plazas libres en zona azul en tiempo real.»
Emoción
Satisfacción
Oportunidades UX
Disponibilidad en vivo: detección y guiado a plazas libres de estacionamiento regulado
05. Post-estacionamiento
Acción
Gestión y ampliación del tiempo del parquímetro en remoto.
Pensamiento
«Puedo ampliar el parquímetro desde el móvil sin tener que volver al coche.»
Emoción
Satisfacción
Oportunidades UX
Gestión integral del ticket: pago rápido, temporizador visible y ampliación remota.
User Flow
Moscow
Must have
•
Notificaciones de aviso de que el usuario está entrando en Madrid Central
•
Personalización del usuario: introducir tipo de coche y modelo en la app
•
Mapeado de las plazas libres de aparcamiento en tiempo real
•
Pago de parquímetro desde la app con posibilidad de ampliación de tiempo
•
Aviso de incidencias en carretera
Should have
•
API de Madrid Movilidad
•
Referencias cercanas en el mapa (edificios o tiendas) para ubicar el coche aparcado
•
Pronóstico de dificultad de aparcar según hora y lugar, en base al histórico de usuarios
•
Localización GPS del coche para recordar dónde está aparcado
Could have
•
Información de carretera de la DGT (si la app llega a ser pública)
•
Que los propios usuarios ayuden a mapear qué zonas están ocupadas y cuáles libres
Won’t have
•
APIs de empresas de sensores IoT
•
Sensores IoT en las plazas que indiquen si están libres u ocupadas
•
Ayuda de aparcamiento en zona no regulada (zona blanca)
•
Combinaciones de transporte público si es difícil aparcar
Arquitectura de la información
La app tiene 4 rutas principales claramente marcadas — pronóstico de lluvias, cálculo de trayecto, aparcamiento asistido y pago de parking — que en realidad son tramos de un mismo recorrido. Desde el Menú Principal el usuario puede entrar directamente por el punto que necesite: por ejemplo, pagar el parking sin pasar por el resto del flujo.
Findings & Insights
Findings
Los usuarios tardan en encontrar plazas de aparcamiento libres.
La mayoría tiene coches con restricción de entrada en Madrid Central y considera que la señalización no está bien especificada.
Las apps de la competencia no ofrecen toda la información necesaria ni son precisas indicando la zona en la que te encuentras.
Quienes hacen trayectos largos sufren atascos y retenciones con frecuencia.
Insights
Un mapeado en tiempo real de plazas libres cercanas resolvería la mayor fricción del proceso.
Notificar al entrar en zona restringida y resaltar el mapa en otro color hace visible el problema antes de que ocurra.
Un trayecto con pronóstico de duración, rutas alternativas y avisos de incidencias reduce la incertidumbre en viajes largos.
Permitir pagar y ampliar tiempo en zonas reguladas desde la app elimina la fricción de volver al parquímetro físico.
[02]
Case study
Wireframing.
Empecé los wireframes de baja fidelidad en papel — me siento más cómodo desarrollando esa primera fase a mano. Después pasé directamente a fidelidad media/alta en Figma, para poder validar el recorrido completo de la ruta con rapidez antes de invertir tiempo en el detalle visual.
Low-Fidelity Wireframes
Bocetos esquemáticos en blanco y negro en papel para validar la arquitectura y el flujo rápido de la app antes de invertir en detalle visual.
Mid / High-Fidelity Wireframes
Esquemas estructurados con jerarquía tipográfica, distribución de tarjetas y colocación de elementos clave antes de aplicar la UI final.
[03]
Case study
Design System.
A partir de los wireframes de baja fidelidad, construí un sistema visual propio para la app: tipografía optimizada para lectura rápida al volante, una paleta de alto contraste pensada para modo oscuro, y una librería de componentes con estados documentados (Default, Hover, Active, Disabled) sobre un grid de 8px.
Tipografía
Nunito Sans
¿Por qué esta tipografía?
Necesitábamos una tipografía que se pueda leer de manera ágil. En las investigaciones descubrí que esto era un punto importante, dado que los usuarios van a utilizar la app mientras conducen.
Por eso elegí una tipografía con bordes no redondeados y san serif.
Paleta cromática
Purple 500
rgb: (92, 65, 210)
HEX: #5C41D2
Purple 400
rgb: (125, 103, 219)
HEX: #7D67DB
Purple 300
rgb: ((157, 141, 228)
HEX: #9D8DE4
Purple 200
rgb: (190, 179, 237)
HEX: #BEB3ED
Purple 100
rgb: (242, 240, 251)
HEX: #F2F0FB
Dark Purple 100
rgb: (84, 69, 176)
HEX: #5445B0
Dark Purple 200
rgb: (63, 52, 131)
HEX: #3F3483
Dark Purple 300
rgb: (46, 38, 96)
HEX: #2E2660
Dark Purple 400
rgb: (28, 22, 69)
HEX: #1C1645
Dark Purple 500
rgb: (19, 14, 48)
HEX: #130E30
Green 500
rgb: (68, 203, 56)
HEX: #44CB38
Red 500
rgb: (231, 38, 38)
HEX: #E72626
Soft Grid & Espaciado
Definí un sistema de espaciado basado en múltiplos de 8px (con pasos intermedios de 4px) para que paddings, gaps y tamaños de componentes fueran predecibles y fáciles de mantener.
Librería de componentes
Botones, campos de texto, tarjetas e iconografía con variantes Default, Hover, Active y Disabled documentadas como Variables de Figma.
Grid System
Mobile Grid
Rejilla base — Frame 393 × 852
Columnas
4
Ancho de columna
76px
Margen
20px
Gutter
16px
[04]
Case study
Pantallas.
Conclusiones
TFM individual, rediseñado dos veces: primero con la guía de mi profesor Iván Rico (UI, componentes, ilustraciones), y en esta última vuelta rediseñando la UI, mejorando el sistema de diseño y puliendo partes del UX sobre la investigación y las rutas ya definidas en la primera versión.
Impacto de la solución
En esta segunda vuelta rediseñé la UI, mejoré el sistema de diseño y afiné algunas partes del UX, manteniendo las 4 rutas principales —trayecto, aparcamiento asistido, pago y pronóstico— que ya nacieron en la investigación original.
Aprendizajes clave
Retomar el proyecto con perspectiva significó ver con otros ojos decisiones de UI que no tenían tanta base, y comprobar que un sistema de componentes bien planteado ahorra mucho más tiempo en la segunda vuelta.
© 2026 Daniel Castiñeiras. Todos los derechos reservados.
Diseñador UX/UI en Madrid ·