Un caso, no un formulario

Primero, el problema — mapeado por actor

Antes de una sola pantalla, seis meses de investigación mapearon qué se rompe para cada actor: el ciudadano que no puede confiar en su reporte, el supervisor que no puede priorizar lo que no ve, las instituciones que reciben quejas sin forma de cerrarlas con credibilidad. El mapa decidió el producto.

El modelo: un caso con vida

Un reportero abre el caso en nombre del ciudadano y lo enruta a la institución responsable — obras públicas al MOPC, y así. Desde ahí el caso tiene una vida que el ciudadano puede mirar: su estado se mueve, su prioridad se ve, y el hilo mantiene la conversación mientras avanza. El paso de cierre es el producto entero: que una persona te diga que se resolvió — con pruebas.

Construido sobre un plan con fechas

Diseñé la app completa, con un desarrollador móvil, dos de backend y un data scientist, contra un plan con dueños y fechas: app ciudadana, app admin, sistema de tickets, dashboard. Tres palabras gobernaron cada pantalla: Confiable — pasos cortos e información útil; Empatía; Consistente.

Lenguaje llano, y el lanzamiento

El cambio de mayor efecto nunca fue visual: negarse a poner vocabulario administrativo delante del ciudadano. Las instituciones escriben como se organizan; cada código interno en un formulario le dice a alguien que este sistema no es para él. Reescribir eso es lento y político — y es el trabajo. Después, lo llevamos a las instituciones.

6

Meses de investigación antes de asentar el diseño

3

Estados por los que vive un caso, visibles para el ciudadano

1

Hilo por caso, vivo hasta cerrarse con pruebas