Trabajando junto con UNICEF en la mitigación de riesgos socio-ambientales en las favelas de Río. Parte II

Esta foto del puente Uga-Uga, en la favela del Morro dos Prazeres, barrio de Santa Teresa (Río de Janeiro), fue tomada cuando la ONG brasileña CEDAPS, con el auspicio de UNICEF y el soporte tecnológico del MIT, comenzó con la puesta en funcionamiento del primer workshop de Mapeo Digital de Riesgos Socio-Ambientales Liderado por Jóvenes en dicha comunidad a mediados del año pasado, al que luego le seguirían otros cuatro –Macacos, Borel, Urubus y Rocinha –. Éste representa tan sólo uno de los tantos peligros potenciales que se ciernen sobre los pobladores de las favelas de Río, y muy especialmente sobre los niños...

En nuestro post anterior prometimos que en esta oportunidad relataríamos cómo en poco más de un mes, entre el primer taller del que participó el equipo del InSTEDD iLab América Latina, en el Morro do Borel, y el segundo, en el Morro dos Urubus, se logró optimizar la usabilidad de la plataforma tecnológica de relevamiento, y que incluso te mostraríamos casos concretos que ilustrasen el impacto tangible de esta iniciativa.

Pues bien, a continuación te presentamos cómo las autoridades municipales, de la mano de Defensa Civil, repararon el puente ni bien se enteraron informalmente de este riesgo socio-ambiental detectado por los propios chicos de la favela.

Resulta muy alentador comprobar que una experiencia piloto que partió de humildes talleres con líderes comunitarios y niños y adolescentes, que se nutrió del trabajo de campo de jóvenes del lugar, está empezando a dar sus frutos concretos. También disponemos de imágenes del saneamiento de un gran basural en Prazeres, que hasta hace poco lucía así:

Y gracias al esfuerzo mancomunado de los propios pobladores de la comunidad y de un equipo de trabajadores provisto por Defensa Civil ahora se ha librado de tantos desechos insalubres, recuperándose de esta manera un valioso espacio público.

Resolviendo problemas técnicos y de usabilidad de la plataforma

Veamos ahora cuáles fueron los problemas técnicos y de usabilidad de la plataforma de mapeo digital de riesgos que fueron detectados por Martín Verzilli y Ary Borenszweig –iLab América Latina– e Ives Rocha y Alexei Dunaway –CEDAPS– luego del taller en el Morro do Borel, y cómo se superaron, lo que permitió que en el siguiente workshop, un mes después, en el Morro dos Urubus, los jóvenes pudieran generar sin ningún inconveniente sus reportes, y que éstos, a su vez, pudieran ser subidos al sitio web satisfactoriamente.

Alexei Dunaway - Ives Rocha (CEDAPS)

Ary Borenszweig - Martín Verzilli (InSTEDD iLab América Latina)

Ives Rocha, encargado de Monitoreo y Evaluación del CEDAPS, narra su experiencia junto con el equipo del InSTEDD iLab América Latina en el despliegue del proyecto de Mapeo Digital de Riesgos Socio-Ambientales Liderado por Jóvenes en favelas de Río de Janeiro, inmediatamente después del workshop en el Morro do Borel.

Por otro lado, Alexei Dunaway, un egresado de la Universidad de Stanford  –Relaciones Internacionales– que trabaja como voluntario en el CEDAPS desde hace unos meses, en esta breve entrevista se refiere a su percepción de aquello que podría mejorarse de la aplicación para que ésta se torne más escalable y abierta al público masivo en instancias futuras.

Y ahora sí, entrando de lleno en el abordaje de los problemas detectados y de los antídotos que se fueron aplicando para superarlos, pasemos a la entrevista a Martín Verzilli, Líder de Proyectos del InSTEDD iLab América Latina, narrando todos los pormenores pertinentes.

Morro dos Urubus

Martín, ¿podrías enumerar cuáles fueron los problemas técnicos y de usabilidad que detectaste después del primer workshop (Borel), y cuáles fueron los antídotos respectivos aplicados para que en el segundo (Urubus) todo funcionara correctamente?

Sí, pero ante todo me gustaría destacar que aquí todo debe ser analizado a la luz de una restricción fundamental del trabajo, que es la limitación temporal, es decir, había que resolver los problemas rápidamente. Si bien –en tren de ponernos exigentes en extremo– podríamos decir que la plataforma, así como quedó luego de las correcciones, todavía dista de ser la ideal, el objetivo era obtener algo suficientemente funcional y “usable”, y que pudiera ser desarrollado en el exiguo lapso de un mes para lograrlo. Éste es un detalle muy importante a la hora de analizar las recomendaciones que hicimos, porque si no hubiera sido ése el caso, el estado ideal al que debería haber llegado la aplicación debería ser otro... Ello pone de relieve lo importante que es el concepto de que el diseño de interacción es una actividad contextual: no existe una solución ideal en abstracto, para cualquier tipo de escenario, sino que debes analizar cuáles son tus problemas hoy y cuál es el universo de soluciones factibles para este tiempo y este lugar.

Pues bien, teniendo en cuenta esto, la mayoría de nuestras sugerencias giraron en torno a simplificar y a remover elementos superfluos de la interfaz, o que no fueran imprescindibles. Partir de un conjunto muy simple de funcionalidades, los más sencillas posible, y poder concentrarlas todas en una aplicación reducida. De esta manera se logran dos cosas: mientras uno tiene menos elementos en una interfaz, y menos factores en juego, más simple es para el usuario entenderlo, y, a la vez, más simple es para un desarrollador pensar todas las posibles formas en las que esa interfaz podría llegar a fallar; entonces, es más fácil lograr llegar a buen puerto, a un buen producto, cuando se cuenta con un diseño más simple, con menos componentes, más despojado...

OK, hecha esta aclaración, pasemos entonces a los distintos problemas detectados y a sus soluciones respectivas.

1. Lo primero que traía problemas en cuanto a la usabilidad era que la versión que había antes de que nosotros fuéramos incorporados al proyecto permitía que los usuarios recorrieran varias pantallas de la aplicación en cualquier orden, y pudieran avanzar y retroceder a través de esas pantallas constantemente, a voluntad. Si bien esto –la navegabilidad irrestricta–, a priori, pareciera ser una ventaja, una libertad de uso deseable, en realidad es contraproducente... Ello provocaba que el foco del usuario se dispersara, ya que se le agregaba un paso de toma de decisión absolutamente innecesario en esa instancia del procedimiento. Era preciso simplificar, buscando que el cambio implicase eliminar funcionalidades superfluas en vez de agregar componentes nuevos. Eso repercutiría en la ganancia de tiempo, y, por ende, en la factibilidad de la solución. Las pantallas eran las siguientes: uno entraba a la aplicación para crear un reporte, y debía completar los campos de tres solapas: a) Ubicación; b) Título / Descripción del riesgo / Tag; c) Elemento multimedia (foto o video). Entonces uno podía ir saltando de una pantalla a la otra, y los chicos se la pasaban haciendo eso, y nunca terminaban de cerrar ningún reporte...

Captura de pantalla de Android que muestra la interfaz anterior de la aplicación

La solución que habíamos barajado inicialmente había sido incorporar todo en un modo secuencial de pantallas. Sacas la foto, aprietas “Siguiente”, llenas la información, nuevamente “Siguiente”, permites que el GPS detecte la ubicación, y listo. Lo que finalmente terminamos haciendo, consensuándolo con el equipo de desarrollo del MIT, fue incluir todo en una sola pantalla, en la que naturalmente uno va leyendo de arriba hacia abajo.

Captura de pantalla de Android que muestra la interfaz actual de la aplicación 

2. La segunda dificultad superada fue una combinación de problemas técnicos y de usabilidad, que repercutía en la posterior subida eficiente del componente multimedia (foto y/o video). Algo que descubrimos observando el trabajo de campo de los jóvenes y viendo cómo usaban la aplicación fue que como había dos campos, uno para título y otro para descripción del riesgo detectado, eso les resultaba un tanto excesivo, ya que estabábamos forzando al usuario a llenar un campo más, cuando no es tan fácil tipear en un teclado touch, y además lo que terminaba pasando era que siempre el título era parte de la descripción, o tener que dirimirlo los confundía, o les hacía perder tiempo innecesariamente. Entonces decidimos reducirlo a un único campo, cosa de exigirle al usuario un único input, por un lado, y por el otro, tener la interfaz más limpia. Seguimos guiados por el mismo principio regente de simplificar que te había mencionado al principio.

3. La aplicación originalmente permitía subir tanto una foto, sacándola en el momento o bien eligiéndola de una galería de fotos y agregándola posteriormente, como un video, pero las últimas dos opciones no estaban funcionando. Entonces propusimos que nos concentráramos en el caso principal (foto sacada en el momento de creación del reporte) y descartáramos las otras dos, por ahora. Seguimos achicando. Eso nos permitió desplegar todo lo relativo a multimedia en una misma pantalla. El título, el ícono de una camarita... Puedes verlo aquí:

Finalmente quedó el título del reporte, un campo donde se indica si el GPS ya ubicó la posición del celular, el botón para la foto y los tags. En la versión anterior había componentes extra que distraían. Éste es un ejemplo que involucra ambos problemas: técnico y de usabilidad. La solución a la que arribamos simplificó la interfaz, permitiendo una sola opción, por un lado, y por el otro, le facilitó al equipo técnico concentrarse en que eso funcionase, lo que obviamente insume menos tiempo que enfocarse en que tres cosas anden bien simultáneamente...

4. Fíjate en la versión anterior, y vas a ver que la pantalla está prácticamente vacía, y hay un botón que dice “Localización”. Bueno, ahí se supone que hay un mapa... Ahora bien, como estos celulares Android terminaron siendo utilizados en lugares que carecían de conectividad a internet, ya sabíamos que no se podría usar el mapa en el campo. Por lo tanto, en vez de ayudar, porque eso te permite ver el mapita y el punto en el que tú te encuentras en ese momento, esa funcionalidad entorpecía la usabilidad... Confundía, porque uno veía un gran fondo gris que no servía para nada... Entonces, la sugerencia fue que si no íbamos a poder ver mapas durante el trabajo de campo, no mostráramos un espacio gris. Que sólo nos limitáramos a lo que pudiésemos ver. Por lo tanto, la funcionalidad original se transformó en un texto que dice “Buscando...”. Éste es un claro ejemplo de cómo el tiempo pesa en estas decisiones, porque la verdad es que reducir el tema de la ubicación a un texto no es lo ideal... Pero la complejidad técnica que hubiese requerido poder ver mapas en lugares sin conectividad habría tornado infactible su resolución en el escaso tiempo del que disponíamos.

5. Y eso se relaciona con otro de los problemas de usabilidad: el GPS. Por un tema técnico, lleva un buen rato obtener la ubicación del celular vía GPS. Había que pedirles a los jóvenes que permanecieran parados en esa pestaña de “Localización” durante un buen rato, de entre 1 minuto y 1 minuto y medio, hasta que el satélite geo-localizase el celular. Si bien no parece tanto tiempo, ten en cuenta que tienen que estar más de un minuto mirando el celular, sin moverse, que encima se trata de niños y adolescentes inquietos, que están recorriendo su comunidad, en un workshop, que es una actividad que naturalmente provoca mucho entusiasmo...

Entonces acá seguramente la solución provino más del lado humano que del técnico, como pedirles a los chicos que tuvieran paciencia, ¿no..?

No, fíjate qué interesante... Si bien uno no puede luchar contra ese delay impuesto por una cuestión técnica insalvable, sí podíamos trabajar en reducir lo que generalmente se denomina “user percieved waiting time”, o sea, el tiempo que el usuario percibe que está esperando. Acá había dos problemas: dejar esperando al usuario durante 1 minuto o más, y el otro problema es que ése era el primer paso de la creación del informe, y además, para colmo, si el chico pasaba a otra pestaña, el proceso se interrumpía, por lo cual había que comenzar de nuevo y volver a esperar. Volviendo a tu pregunta... Cuando uno se topa con problemas de esta naturaleza se le abren dos caminos: uno es echarle la culpa al usuario y pedirle que modifique su comportamiento, lo cual no nos parece adecuado; y el otro consiste en tratar de usar más la cabeza y pensar cómo se puede mejorar la situación sin modificar artificialmente el comportamiento del usuario. 

Confieso que has captado toda mi atención... Estoy muy intrigado por saber qué hicieron...

Algo muy sencillo... Por empezar, partimos de la idea de no obligar al usuario a estar mirando su celular sin hacer nada durante ese minuto, mientras la aplicación localiza al aparato, que es lo que pasaba con la versión anterior... Lo que hicimos fue cambiar el orden del procedimiento... Apenas uno comienza a crear el reporte, desde ese momento empieza a buscarse tu ubicación. Originalmente no era así. No se lo hace esperar al usuario hasta que no termina de llenar los campos, de ingresar toda la información: poner el título, sacar la foto y agregar alguna etiqueta (si quiere), y apretar “Grabar”. Recién ahí, si todavía el GPS no logró ubicarlo, le aparece un mensaje que dice: “Por favor, espera, que tengo que terminar de localizarte”, y además se le explica por qué es importante que espere, en ese mismo mensaje: “Es importante que te quedes quieto en el lugar en el que estás porque después eso nos permitirá mostrar tu reporte en la ubicación del mapa que corresponde”.

¿Cómo se dio la sinergia tecnológica iLab-MIT en la resolución de este problema en particular?

Buena parte de la programación de estos cambios corrió por cuenta de Ary y de mí, con el consenso de los miembros del equipo del MIT. Fue un ida y vuelta, entre todos fuimos consensuando cuál sería la mejor solución. Dijimos: “No hay que pensar más en nada durante este mes que en la subida de una foto por reporte, y en que la geo-localización sea rápida, o, mejor dicho, que el tiempo que el usuario percibe que está esperando se achique tanto como sea posible... Ésos son nuestros dos objetivos prioritarios de acá a un mes, todo lo demás es accesorio”. Creo que una de las cosas más meritorias de nuestro trabajo fue haber señalado esas dos prioridades, que eran atacables en el lapso de un mes, porque si hubiéramos dicho “No, hay que tirar todo abajo y empezar de cero”, eso habría sido un despropósito, porque no habríamos aprovechado los aciertos de la plataforma, ni los seis meses de trabajo, amén de que algo semejante habría insumido tiempo y dinero extra.

O sea, aprovecharon la plataforma del MIT, quitaron los superfluo y optimizaron lo que quedó...

Exacto...

6. Adicionalmente, había otras pantallas en las que se usaban mapas, y procedimos de la misma manera, quitándolos. Eso nos permitió, una vez más, limpiar la interfaz y ganar espacio de pantalla, que es un bien muy preciado en un teléfono móvil. 

Para finalizar, ¿podrías profundizar un poco acerca del deseo que expresa Alexei en la entrevista, en el sentido de que esta aplicación sea menos restrictiva en cuanto a su uso masivo?

Eso surge de algo que hablamos con Alexei en su momento, en cuanto a que todo lo que hace InSTEDD es recurrente en el sentido de intentar que las soluciones desarrolladas sean accesibles para la mayor cantidad de gente posible. Cuando tú encaras un proyecto que aspira a extenderse a toda la comunidad, y no sólo a un pequeño grupo que participa de una experiencia piloto, en un workshop, si dices “Voy a usar una aplicación Android para esto”, automáticamente estás dejando a un montón de gente afuera, porque esa tecnología todavía resulta inaccesible para muchísimas personas... Desconozco la proporción exacta comparativa, pero, obviamente, hay una cantidad inmensa de personas que tienen celulares comunes, y no Androids. Y cualquier celular, hasta el más barato, si bien carece de GPS, está habilitado para intercambiar SMS. Podría especificarse vía SMS la intersección de las calles donde se localizó el riesgo. O podría implementarse un sistema de grilla o cuadrícula preestablecido, para los alrededores de tu casa, y tú podrías enviar un SMS diciendo: “Encontré este problema en el cuadrante B-2”, por ejemplo, que es una alternativa que podría ponerse en práctica mediante una aplicación como Walking Papers.

De esta manera no se exigiría que el usuario tuviera un smartphone para participar de la experiencia. Obviamente, no se tendría el mismo nivel de precisión que con el Android, no podrías pedirle al usuario que respondiera todas las preguntas, como en este caso, para armar un reporte preciso, pero serviría, sobre todo para validar información. Se me ocurre el siguiente flujo: un usuario reporta basura en determinado lugar; tú le envías un SMS a alguien que se haya inscripto como voluntario para validar reportes, pidiéndole que vaya a chequear si el dato es cierto. La persona va y responde por sí o por no. De esta manera estarías incluyendo a alguien que de otra forma tal vez no habría podido participar del relevamiento, y así le estarías permitiendo que aporte su granito de arena a la causa. 

Infografía producida por UNICEF

Para concluir con esta crónica en dos capítulos nos gustaría compartir contigo algunos fragmentos del reporte que Alexei Dunaway le envió a Joe Agoada (Coordinador de Desarrollo Tecnológico de UNICEF), como buen exponente de los notables adelantos percibidos en el workshop de Urubus respecto del anterior en Borel, y que gentilmente nos autorizó a reproducir:

“El entrenamiento fue fantástico. La aplicación funcionó correctamente, lo que marcó una gran diferencia respecto del workshop anterior, en el Morro do Borel. La nueva interfaz, mucho más simplificada, permitió que resultara mucho más fácil entrenar a los jóvenes en el uso de la aplicación, y fueron capaces de crear 150 reportes en una sesión de mapeo de tan sólo una hora y media. También pudimos recoger un poco de feedback acerca de cómo mejorar aún más la aplicación, a pesar de que se presentaron muchos menos motivos de crítica y/o frustración en comparación con los talleres anteriores. Todavía nos quedan cosas por mejorar en la plataforma, pero nos alivia constatar que ésta funciona satisfactoriamente”. 

“Los chicos se comportaron estupendamente bien; verdaderamente comprendieron lo sustancial del entrenamiento y se mostraron sumamente comprometidos con la causa. Incluso fuimos incorporando nuevos participantes sobre la marcha, y el número de jóvenes subió de 26 a 32 el segundo día...”.

Contáctanos...

Esperamos que esta experiencia que hemos compartido contigo a lo largo de estos dos posts te haya inspirado y funcione como disparador para que se te ocurran ideas análogas que puedan ser aplicadas en tu propia comunidad. Si estás interesado en que exploremos posibles abordajes conjuntos, no dudes en consultarnos: http://www.ilabamericalatina.org/contactanos.