Resumen
Got2Park conectaba a conductores con plazas de aparcamiento privadas sin usar por toda Barcelona, una ciudad en la que entran 500.000 vehículos cada día para solo 150.000 plazas públicas. La idea era buena, pero los usuarios abandonaban: no podían buscar, no entendían la ventana de reserva de 15 minutos y se quedaban atascados ante puertas que no se abrían mientras la app seguía cobrando. Junto con otros dos diseñadores de producto, llevé el producto para el cliente desde la investigación hasta un rediseño en alta fidelidad y testeado de todo el recorrido, de la búsqueda a la salida del parking.
Rol
Diseñador de producto, equipo de tres
Cliente
Got2Park, Barcelona
Alcance
De la investigación a un prototipo hi-fi testeado
Plataforma
App móvil
En detalle
Los métodos y herramientas que elegí para este proyecto. Cambian en cada proyecto, según lo que necesite el problema.
Encontrar dónde se atascan los usuarios
- Tests de usabilidad
- Seis usuarios objetivo: comerciales y conductores jóvenes
- Auditoría de contenido
- 52 pantallas
- Benchmark
- Cuatro competidores directos, más otros indirectos como Cabify y Yego
Cuatro problemas aparecían una y otra vez:
- Sin búsqueda
- Una cuenta atrás estresante de 15 minutos
- Opciones de pago poco claras
- Llaves digitales que nadie entendía

Probar el servicio real
Reservamos y usamos nosotros mismos una plaza real de Got2Park. Tardamos casi 20 minutos, por culpa de:
- Una entrada poco clara
- Indicaciones basadas en columnas idénticas
- Un número de plaza que no vimos
- Una puerta que falló nueve veces mientras el contador seguía corriendo
Después reconstruimos el recorrido como un desktop walkthrough con papel y pósits para mapear cada punto de contacto, online y offline.

Mapear el recorrido
El journey map dividió el servicio en cinco momentos, con objetivos, problemas, emociones y oportunidades para cada uno.
- BuscarEncontrar una plaza
- ReservarGuardarla
- EntrarAcceder
- AparcarEncontrar la plaza
- SalirSalir y pagar
Nos llevó a un único problem statement:
Got2Park necesita una forma de guiar a quienes buscan aparcamiento para que consigan encontrar plaza.

Prototipado y tests
- Crazy 8s
- Prototipo en papel · testeado con 8 personas
- Fidelidad media · testeado con 10
- Alta fidelidad
Iteramos después de cada ronda: una jerarquía de acciones más clara, el pago al final del recorrido como en las apps de VTC, y un paso de confirmación para asegurarnos de que el usuario había salido del parking antes de terminar.



Diseñar para el fallo
La tecnología de las puertas aún estaba en beta, así que en lugar de esconder los fallos diseñamos para ellos:
- 1 · ConectandoUn mensaje mientras el móvil se conecta a la puerta.
- 2 · «¿Puerta abierta?»Una comprobación con reintento, hasta tres veces.
- 3 · Sigue fallandoUn siguiente paso claro, para que nadie se quede atascado.
Los usuarios siempre sabían qué estaba pasando y qué hacer a continuación.


La experiencia final
Qué cambió
- Búsqueda y un atajo de reserva rápida para conductores habituales
- Los 15 minutos replanteados como «te guardamos la plaza» en lugar de una cuenta atrás
- Guía dentro del parking: indicaciones de planta, plaza y giro a giro
- Opciones de pago claras



Aprendizajes
Lo más importante que me llevo del proyecto.
- Los mayores problemas no estaban en la pantalla. Probar el servicio real destapó problemas que ningún test de usabilidad habría encontrado.
- Diseñar para el fallo genera confianza. Cuando la tecnología no es fiable, los mensajes claros importan más que un happy path perfecto.
- Las palabras cambian el comportamiento: los mismos 15 minutos se sentían como presión en forma de cuenta atrás y como una ventaja en forma de reserva.
- Lo que haría hoy: definir métricas de éxito desde el principio (reservas completadas, llamadas a soporte por las puertas) para medir el impacto del rediseño tras el lanzamiento.
