Un caso, no un formulario

Veinte días antes de la primera pantalla

Nos dijeron quiénes eran los usuarios. Después fuimos a conocerlos: más de 20 días por todo el país, en los destacamentos donde la app se iba a abrir de verdad. Los oficiales no se parecían en nada a la descripción. La media pasaba de los cuarenta, y casi todos manejaban el teléfono perfectamente — que tampoco era lo que nos habían contado.

Ese es todo el argumento para ir. Un brief describe al usuario que la institución imagina. Veinte días describen al que la va a abrir un martes.

Un reporte que tiene que volver

Casi todas las herramientas públicas de reportes son un formulario con un botón de enviar, y el ciudadano no vuelve a saber nada. La decisión de diseño aquí fue que un reporte es un caso con vida: un estado, una prioridad, una institución con nombre que lo asume, y un hilo que solo se cierra cuando la institución sube la evidencia de que se hizo.

Seis tipos de usuario, una app

Ciudadano, oficial, oficiales por zona o jurisdicción, institución, administrador, superadministrador. Cada uno necesita algo distinto del mismo objeto, y una división mal hecha aquí cuesta reconstruir. Así que se mapeó antes de dibujarse: el sistema de tickets, la app ciudadana y la app de administración en un solo tablero, con fechas.

Qué salió de las pruebas

Más de 200 oficiales la probaron y se crearon más de 400 reportes durante las pruebas. La lección que me llevo no es sobre la app: es que la gente usa el teléfono de una forma que no se parece en nada a lo que supone un organigrama, y que la simplicidad abre una puerta que ninguna capacitación abre.