Este caso empezó como un proyecto de fin de semana y se convirtió en otra cosa un año después. Vale contarlo en ese orden, porque la segunda pasada cambió lo que yo entendía de la primera.
El punto de partida
El tema del hackathon era Vertical Smart Cities. Éramos ocho equipos al principio y la mitad llegó al final. Trabajé con dos personas más, y me encargué de la investigación, los flujos, la interfaz y la presentación al jurado.
Era mi primer hackathon. Tenía ganas de participar en uno desde hacía tiempo y nunca había aparecido la oportunidad.
Elegimos estacionamiento porque es un problema urbano que todos en la sala habían vivido. Esa es una buena razón para elegir un tema y una pésima razón para creer que ya se conoce el problema. Fue lo que mostró la investigación.
El concepto nació con dos lados. Por uno, el conductor que busca plaza. Por otro, el dueño del estacionamiento, que necesita llenar las plazas que tiene, y para quien el segundo objetivo declarado del proyecto era maximizar la ocupación y los ingresos. En el plazo del fin de semana solo se diseñó el lado del conductor, y de ese trata este caso.
El camino tampoco fue lineal, y el proyecto lo registra de una forma que no quise perder al traerlo aquí.
El proceso tal como se cuenta después: cuatro etapas, en línea recta.
Descubrimiento (Discovery)
- Desk research
- Análisis de la competencia
- Survey
- Entrevistas con usuarios
- How might we
Definición (Define)
- Definición del problema
- Proto personas
- Service blueprint
Ideación (Ideate)
- Arquitectura de la información
- Userflow
- Wireframes
- Moodboard
Desarrollo (Develop)
- Dirección visual
- Interacción
- Alta fidelidad
El botón de arriba existe porque la versión limpia es siempre la que se cuenta después. No todo lo previsto ahí se completó a tiempo, y de eso trata el final de este caso.
La investigación
Monté dos frentes, con propósitos distintos.
Entrevistas en profundidad, con un guion de diez preguntas organizadas en cinco ejes: comportamiento y hábitos, dolores y frustraciones, percepciones y necesidades, experiencia con tecnología, sugerencias y mejoras. Hechas en persona y por videollamada.
Antes de cada conversación leía un guion de apertura pidiendo autorización para grabar el audio, y explicaba por qué: grabando, yo no necesitaba escribir durante el relato y no interrumpía el razonamiento de la persona. Parece burocracia. No lo es. Es lo que permite escuchar de verdad, en vez de tomar notas.
Una encuesta estructurada, con once participantes y ocho preguntas, tabulada en una matriz de participante por pregunta. Las entrevistas servían para entender cómo deciden las personas; la encuesta, para saber cuántas piensan parecido.
Once personas en un fin de semana no son muestra para generalizar, y nada de esto debe leerse como estadística. Es muestra para encontrar dirección, que era lo que el plazo permitía y lo que la decisión exigía.
Todos los recuentos de este caso salen de aquí.Nada se redondeó para que sonara mejor.
Lo que dijeron los datos
Estacionar es rutina diaria, y la dificultad también. Siete de los once participantes estacionan todos los días. Y ninguno respondió que nunca tiene dificultad para encontrar plaza: dos dijeron "siempre", cinco "frecuentemente" y cuatro "a veces". No era un contratiempo ocasional de fin de semana.
El dolor más fuerte no era la plaza. Era la inseguridad. Fue el hallazgo que más cambió el proyecto, porque no era lo que yo esperaba encontrar. Ocho de las once respuestas a la pregunta abierta sobre frustración hablan de miedo, robo o falta de seguridad, y de formas muy concretas:
"Falta de plaza o un gorrilla cobrando por vigilarte el coche."
"Pagar zona azul para que el coche se quede desprotegido en la calle."
"El peligro de volver y no encontrar el vehículo."
Yo había entrado creyendo que el problema era el tiempo perdido. El tiempo aparece en los datos, pero pierde contra el miedo a dejar el coche en algún sitio y no encontrarlo después.
El comportamiento cambia según se conozca el lugar. Dos personas describieron la misma estrategia sin ponerse de acuerdo:
"Si es un sitio conocido, ya sé dónde hay una zona más amplia para aparcar y ya sé el camino. Cuando no lo es, entonces busco un poco."
Las personas ya describían el producto solas. Preguntado por lo que le gustaría ver en una aplicación, un participante respondió con un modelo hecho:
"Precio, sitio, reservar. Igual que Uber: sitio y hora."
Pero la función más pedida en la encuesta no fue reservar. Fue ver la disponibilidad en tiempo real: nueve de los once marcaron esa opción, frente a seis que marcaron reservar con antelación. Antes de asegurar la plaza, la gente quería saber si había plaza.
Los dos hallazgos más fuertes acabaron en la misma pantalla. La home abre con el mapa mostrando cuántas plazas libres tiene cada estacionamiento en ese momento, que era la función más pedida, y la línea sobre el buscador dice "vamos a encontrar una plaza segura", porque seguridad era la palabra que más se repetía.
Los dos hallazgos de la investigación, en la primera pantalla.Disponibilidad en tiempo real en el mapa, y la palabra seguridad en la línea de búsqueda.
Y nadie conocía la categoría. "Nunca la he usado." "Nunca la he usado, no conozco ninguna." "Nunca he visto ninguna app que haga eso." No se trataba de mejorar algo que ya existía en la cabeza de la gente. Era introducir una idea.
Había un techo de precio, y era bajo. Ningún participante aceptó pagar más de diez reales por reserva, y cuatro esperaban que fuera gratis. Cualquier modelo de negocio tendría que caber ahí.
Y apareció un dolor que el producto no resuelve. Dos personas trajeron, sin que se les preguntara, que su dificultad era maniobrar:
"Aparcar en línea es una dificultad."
No estaba en la encuesta, así que no sé el tamaño de eso. Queda anotado como pista, y no como hallazgo: StopCar ayuda a encontrar y reservar, pero aparcar el coche sigue siendo cosa de la persona.
Las decisiones
Separar a quien necesita ahora de quien está planificando
El comentario sobre el sitio conocido y el desconocido describe dos situaciones que parecen la misma y no lo son. Quien ya está en la calle buscando quiere resolver en segundos. Quien va a salir de casa dentro de tres horas quiere elegir con calma.
Un flujo único obligaría a ambos a recorrer el mismo camino, y el camino bueno para uno es malo para el otro: demasiado filtro estorba a quien tiene prisa, y demasiada prisa estorba a quien quiere comparar.
Por eso la entrada se divide al principio, en reservar para ahora y planificar tu reserva. Las pantallas siguientes convergen, porque la elección de duración, vehículo y extras es la misma en los dos casos. Lo que cambia es la puerta.
Quien planifica empieza buscando un sitio.Quien tiene prisa ya empieza con el sitio resuelto.
Enseñar lo suficiente para decidir sin ir hasta el lugar
Como nadie conocía la categoría, la barrera no era usar la aplicación. Era confiar en ella. Reservar a ciegas un sitio donde vas a dejar tu coche es exactamente el miedo que reveló la investigación.
La pantalla de detalles reúne ubicación, disponibilidad, precio, horario e información del estacionamiento antes de cualquier confirmación. Y la elección baja hasta la planta y la plaza concreta, lo que responde al tema del hackathon por un camino concreto: estacionamiento vertical, con la plaza identificada en altura, y no una dirección genérica.
La plaza tiene planta y número.El mismo dato reaparece en la confirmación, porque es el que la persona va a buscar cuando llegue.
No terminar en el pago
La reserva confirmada no es el final de la tarea. La persona todavía tiene que llegar al sitio, entrar, y a veces quedarse más tiempo del previsto.
El flujo continúa después del pago: navegación hasta el estacionamiento con tiempo y distancia, inicio de la reserva, ampliación del periodo e historial. Si el producto existía para reducir la inseguridad, abandonar a la persona en el momento en que todavía está lejos del coche sería contradecir la propia premisa.
El botón de ir después existe porque no toda reserva es para ahora.La pantalla tenía que servir a los dos comienzos.
Del flujo a la pantalla
Antes de dibujar pantalla, dibujé camino.
El diagrama de flujo cubre la entrada al producto y los puntos en que la persona decide: activar o no la ubicación, entrar por teléfono, Apple, Facebook o Google, y qué cambia cuando el usuario es nuevo. Cada salida de rombo tiene destino, incluidas las que no siguen adelante.
Flujo de entrada con las decisiones explícitas.Cada salida tiene destino, incluidas las que no siguen.
El blueprint de servicio fue más allá de la pantalla. Para cada etapa separa lo que la persona hace, lo que ve ocurrir, lo que el sistema hace por debajo y de qué herramienta depende eso. Ahí queda registrado que "plaza disponible" no es información de interfaz: es una consulta a una base de datos que además tiene que bloquear la plaza temporalmente mientras la reserva no se confirma.
Lo que la persona ve, lo que el sistema hace y de qué herramienta depende, etapa por etapa.
Y el mapa de pantallas enseña el tamaño real de lo diseñado, mucho más allá de las pantallas que este caso puede mostrar una a una.
El producto entero, pantalla a pantalla.Las de este caso son un recorte.
El sistema detrás
Antes de las pantallas vino el mapa. Cada área del producto con lo que cabe dentro, de las más obvias, como buscar y reservar, a las que solo aparecen después, como vehículos registrados, favoritos e historial.
El producto entero en una página.Es aquí donde queda claro que la reserva era solo una parte de él.
La marca vino del mismo sitio. El símbolo es un pin de ubicación ocupando el lugar de la "a" de StopCar, lo que resuelve nombre e icono con un solo dibujo, y sigue siendo legible invertido sobre fondo oscuro.
Un dibujo que sirve de logotipo y de icono de la app, sin necesitar dos soluciones.
Además de los flujos, monté la base visual: paleta con los contrastes anotados, escala tipográfica y biblioteca de iconos.
Las marcas AAA y AA en cada tono no son adorno: era la comprobación de contraste hecha antes de usar el color, no después.
Y, sobre esa base, una hoja de componentes reutilizados entre pantallas.
En un hackathon eso parece un lujo, y es lo contrario: con el tiempo corto, tener el componente hecho fue lo que permitió rediseñar el flujo sin rediseñar la pantalla.
Cada pieza de aquí aparece en más de una pantalla.Eso fue lo que dejó rehacer el flujo sin rehacer la interfaz.
El producto funcionando
El caso hasta aquí muestra decisión. Esta sección muestra su resultado en movimiento: las grabaciones del prototipo de alta fidelidad.
Fíjate en lo que aparece aquí y no vino de la investigación. Vehículos registrados e historial salieron del mapa de arquitectura, no de un hallazgo con usuarios. Son lo que el producto necesitaba tener para existir, no lo que necesitaba resolver. En un hackathon no sobra tiempo para validar esa parte, y entró igualmente.
12 grabaciones, 6 min en total
Permiso de ubicación
Llegada al estacionamiento
Confirmación de la ampliación
Registro simple, rápido e intuitivo para los usuarios.
Revisa todos los detalles del estacionamiento donde quieres reservar tu plaza.
Reserva una plaza para ahora, y entra de inmediato.
Reserva una plaza para después y asegura el día y la hora que quieres.
Pago fácil y rápido para asegurar tu plaza sin complicaciones.
Inicia el trayecto y deja que la navegación en pantalla te lleve.
Empieza tu reserva con un toque y, si lo necesitas, amplía el periodo.
Guarda tus vehículos para reservar con menos toques la próxima vez.
Accede a todo tu historial de reservas.
Lo que pasó
StopCar quedó en primer puesto. El jurado señaló la innovación de la propuesta como el motivo.
La pieza que fue al jurado.Marca, producto y posicionamiento en una sola composición.
Vale decir lo que esto no es. Un hackathon premia propuesta, no producto en uso: StopCar nunca se lanzó, nunca tuvo usuarios de verdad y no tiene números de adopción que enseñar. Lo que este caso demuestra es el razonamiento hasta la decisión, y no su efecto en el mundo.
La investigación que no se sintetiza se convierte en memoria
Volví al proyecto en 2024, y lo más revelador no fue una pantalla: fue descubrir que yo había recogido la investigación y nunca la había sintetizado.
El tablero de 2023 tiene objetivo, guion, transcripciones y la matriz de resultados tabulada. Tiene también dos columnas, insights y "how might we", con los post-its en blanco, todavía con el texto por defecto de la herramienta. En el ritmo del fin de semana, los datos se convirtieron en decisión directamente, sin pasar por la etapa que transforma respuesta en conclusión.
Las decisiones acabaron siendo correctas. Pero eran correctas por intuición bien informada, y no por un razonamiento que yo pudiera enseñarle a alguien. La síntesis que sostiene este caso se hizo después, releyendo el material original, y fue solo entonces cuando el hallazgo sobre la inseguridad se me hizo visible. Estaba en los datos desde 2023.
Ese es el aprendizaje que me llevo, y no va de estacionamientos: la investigación que no se sintetiza se convierte en memoria, y la memoria no se audita.