Un verificador de datos cartográficos que funciona sin conexión

Sustituir un programa de Windows en vías de desaparecer que revisaba los datos cartográficos de los contratistas para el programa de datos cartográficos de una agencia federal, por una app en React construida sobre el propio sistema de diseño del gobierno

Mi papel

Diseñador UX sénior

Empleador
World Wide Technology
Cliente
El programa de datos cartográficos de una agencia federal
Años
2018 a 2020
Equipo
Diseñador principal en un equipo de diseño de cuatro personas, junto a ingenieros de front end y de Python
  1. Dirigí la UX del programa que revisa los datos cartográficos antes de que lleguen a la agencia y construí sus pantallas en React.
  2. Establecí el ritmo semanal: una demostración con lo aprendido de los usuarios, los prototipos y las funciones terminadas, con investigación cada dos semanas.
  3. Dirigí el diseño de más de 40 piezas que le faltaban al sistema de diseño del gobierno, y ayudé a construirlas, cada una con instrucciones y pruebas automáticas.
  • Días→horas para revisar un lote de datos cartográficos, según nos contaron los contratistas; nadie lo cronometró
  • 2,000+ archivos cartográficos revisados en el primer mes, según los propios recuentos del equipo de entrega
  • 40+ piezas de pantalla que le faltaban al sistema de diseño del gobierno, construidas en React con pruebas
  • WCAG 2.1 AA estándar de accesibilidad cumplido, comprobado por nosotros con herramientas y un lector de pantalla, sin auditor externo

Resumen

Los contratistas tenían que enviar datos cartográficos al programa de datos cartográficos de una agencia federal sin ningún error. El único programa que podía revisarlos estaba escrito en Visual Basic, y Microsoft dejaba de dar soporte a la versión de Windows que necesitaba, así que los contratistas ni siquiera podían instalarlo.

Lo sustituimos por una app web dentro de un instalador de escritorio, para que funcione, a propósito, en laptops que nunca se conectan a una red. Una revisión consta de cuatro pasos guiados, sin línea de comandos: soltar la carpeta, confirmar que está completa, ejecutar las revisiones detalladas y descargar el informe. Dirigí la UX, construí pantallas como uno de los ingenieros de front end y establecí el hábito semanal que llevaba lo que oíamos de los usuarios directamente al trabajo en curso.

Quiénes participaron

  • Contratistas Tenían que demostrar que sus datos cartográficos no tenían errores antes de enviarlos a la agencia; usaban la herramienta en laptops seguras sobre el terreno.
  • Cartógrafos Respondían ante su propia dirección; nadie de los que llevaban el proyecto los veía como el cliente.
  • Personal de TI en redes cerradas Instalaban las actualizaciones desde unidades extraíbles, firmadas digitalmente para saber que eran auténticas.
  • El equipo de diseño Dos investigadores, un product owner técnico y yo como diseñador principal.
  • Ingenieros de front end y de Python El equipo de ingeniería de World Wide Technology; yo era uno de los ingenieros de front end y construía las pantallas en React.
  • Responsables del programa Un product owner, un analista de negocio y un responsable de entrega.
  • El propio equipo de la agencia Los ingenieros y el product owner de la agencia trabajaban con nosotros, para un patrocinador dentro de la agencia.
La pantalla de resultados. Un titular dice “44 things to look at” con una etiqueta de 2 condiciones bloqueantes y la procedencia de la ejecución: el estándar de datos, la celda, terminado a las 14:22. Abajo a la izquierda, un mapa de la cuadrícula lleva marcadores rojos grandes para los hallazgos bloqueantes y otros azules más pequeños para los avisos, dentro del límite discontinuo de la celda. Abajo a la derecha, las seis condiciones aparecen ordenadas con las bloqueantes primero y sus recuentos.
Los problemas sobre un mapa. El mapa muestra dónde está cada problema, y la lista pone arriba los que hay que corregir sí o sí.
Leer el expediente 6 secciones, unos 2 min

Contexto

El verificador antiguo estaba escrito en Visual Basic, un antiguo lenguaje de programación de Microsoft, y Microsoft había anunciado que dejaría de dar soporte a la versión de Windows que necesitaba. Los contratistas ni siquiera podían instalarlo, lo que ponía en riesgo todo el requisito. Usarlo significaba pasar por una ventana emergente tras otra siguiendo una lista de comprobación de un archivador de seis pulgadas de grosor. Cada entrega llevaba días.

Las normas federales exigían además que la nueva herramienta siguiera el U.S. Web Design System (USWDS), el sistema de diseño del gobierno. En 2018 era poco más que una guía de estilo y un archivo de plantilla, pensado para páginas web, no para un programa de trabajo.

Investigación

Un diagrama de cómo llegaba el verificador a sus usuarios. Fuera, una versión firmada se copia a una unidad extraíble. La unidad se lleva a mano a través del control de acceso del sitio. Dentro, en una red cerrada sin internet, el personal de TI comprueba la firma antes de instalarla en laptops sin conexión, donde los contratistas revisan sus datos cartográficos. Una línea discontinua marca las visitas del equipo de investigación para observar el trabajo.
Cruzar el aislamiento de la red. Las versiones llegaban a laptops sin conexión en unidades extraíbles firmadas, y nosotros íbamos al sitio a observar el trabajo.
Un diagrama de cómo se conectaban las entrevistas a distancia. La laptop del equipo de investigación lleva una tarjeta inteligente del gobierno en un lector, y el certificado y el PIN de la tarjeta acreditan quién se conecta. La conexión va por un túnel cifrado a través de una red compartida, donde una pasarela comprueba el certificado antes de dejarla pasar. Dentro del sitio seguro, las personas que hacen el trabajo se unen a una videollamada. Las laptops sin conexión del verificador aparecen marcadas como nunca conectados a esta línea.
Entrevistas por una línea con tarjeta inteligente. Entre visitas entrevistábamos a la gente por video, por una conexión cifrada que desbloqueaba el certificado de la tarjeta.

La investigación fue de campo. Fuimos a los sitios seguros donde se hace el trabajo para observarlo, y entrevistamos por video a las personas que nos indicó nuestro contacto en el cliente: las que ya hacían este trabajo por las malas, porque son las que mejor saben qué tiene que hacer de verdad la herramienta.

Después investigamos cada dos semanas. Cada demostración semanal mostraba tres cosas en una sola sesión: lo que habíamos aprendido de los usuarios, los prototipos que estábamos diseñando y las funciones que habíamos terminado. Cada prototipo tenía que responder a algo que habíamos oído de los usuarios, y cada función terminada tenía que coincidir con el prototipo acordado.

Diseño

El nuevo programa es una app web dentro de un instalador de escritorio, así que se instala como cualquier app de escritorio y funciona en computadoras sin ninguna conexión de red. Una revisión consta de cuatro pasos guiados, sin línea de comandos: soltar la carpeta, confirmar que está completa, ejecutar las revisiones detalladas y descargar el informe. Las actualizaciones llegaban en unidades extraíbles, firmadas digitalmente para que el personal de TI de esas redes cerradas supiera que eran auténticas.

El sistema de diseño del gobierno no tenía nada para un programa de trabajo, como ventanas emergentes, asistentes paso a paso o tablas de datos, así que construimos nosotros mismos más de 40 de esas piezas en su estilo, en React. Escribimos instrucciones y pruebas automáticas para cada una, e incluimos la accesibilidad en la lista de tareas de cada función desde el principio en lugar de revisarla al final.

La portada. Una franja fina en la parte superior dice “An application for data producers.” Un titular que dice “Check your data before it ships” está encima de Start a check y See a sample report, junto a una tarjeta de informe de ejemplo con un mapa de marcadores rojos y azules y una lista de condiciones: point not inside area 6, area feature not transferred 12, complete duplicates 4. Debajo, tres tarjetas numeradas explican cómo funciona una revisión: elegir un esquema y subir, revisar el paquete y después las reglas detalladas, y recibir un mapa de lo que hay que corregir.
La portada. La portada explica los pasos de una revisión antes de subir nada y permite abrir primero un informe de ejemplo.
La revisión del paquete falló. Una línea roja corona la tarjeta, que dice “Three things are wrong with the folder” y explica que las revisiones de reglas detalladas no pueden ejecutarse hasta que el paquete sea correcto. Se enumeran tres fallos: falta una capa de carreteras, hay una proyección EPSG:3857 inesperada donde el protocolo espera EPSG:4326, y dos archivos no forman parte del protocolo. Las únicas acciones son Fix and upload again y Download the payload log.
Un alto en seco. Si falta una capa, la proyección es incorrecta o hay archivos sueltos en la carpeta, la herramienta se detiene aquí y enumera exactamente qué está mal. No hay, a propósito, ningún botón para saltar a las revisiones detalladas.
Una condición bloqueante abierta: Point not inside area, 6 elementos afectados. Primero va el lenguaje claro: una boca de pozo registrada fuera del límite de su instalación, así que cualquier cosa que agrupe puntos por el área que los contiene los pasará por alto, seguido de “How to fix it”, que dirige la corrección a la base de datos de producción. Un mapa muestra dónde ocurre, y una tabla enumera los elementos afectados por capa y posición, mostrando 3 de los 6.
Un problema que hay que corregir. Cada problema se explica en lenguaje claro, con cómo corregirlo; el número de la regla es una etiqueta, no el titular.

Más pantallas

La revisión del paquete se superó. La tarjeta dice “The folder has everything it should” y resume 14 capas, 61,208 elementos, EPSG:4326. Una tabla enumera cada capa con su número de elementos y el estado Complete, encima del botón que ejecuta las revisiones de reglas detalladas.
Un aprobado que muestra su trabajo. Cuando la carpeta se aprueba, enumera las capas que encontró con su número de elementos, para distinguir un aprobado real de una revisión que nunca se ejecutó.
Las revisiones de reglas detalladas en curso sobre 61,208 elementos y 96 restricciones. La nota de progreso nombra la regla que se está evaluando, una regla de contención, y una línea debajo indica que los resultados quedarán en Running checks.
Las revisiones detalladas en curso. El paso lento nombra la regla que está revisando en ese momento, no solo un porcentaje.
El paso de descarga de una cuadrícula, 44 elementos, frente al estándar de datos. Las opciones de formato ofrecen solo .shp, solo .csv, o .csv y .shp, cada una con una nota sobre para qué sirve; el alcance ofrece los 44 elementos o solo los bloqueantes. El botón de descarga nombra el formato elegido, y una nota repite lo que producirá la selección actual.
Elegir qué va en el informe. Se elige el tipo de archivo y qué incluir, y el botón de descarga repite la elección en lugar de esconderla entre las opciones.
La lista Running checks. Se muestran cuatro trabajos con su celda, protocolo y hora de inicio, cada uno con un estado en texto claro y una acción acorde con ese estado: View progress para una ejecución al 62%, View para una en cola, Open report para una ejecución terminada con 27 elementos y See why para una cuya revisión del paquete falló. Una nota indica que las revisiones siguen ejecutándose aunque se cierre la pestaña y que los informes terminados se conservan 30 días.
Revisiones que siguen en marcha. Las revisiones siguen en marcha aunque se cierre la pestaña, y cada una tiene un botón acorde con su estado: ver el progreso, abrir el informe o ver por qué falló.

Resultados

Los contratistas nos contaron que revisar un lote de datos cartográficos pasó de llevar días a llevar horas, así que hacían llegar sus datos a la agencia antes. Nadie midió los tiempos de antes y después, así que es su testimonio, no una medición. La herramienta revisó más de 2,000 archivos cartográficos en su primer mes, según los propios recuentos de uso del equipo de entrega. Cumplía el estándar federal de accesibilidad (WCAG 2.1 AA); lo comprobamos nosotros mismos con herramientas automáticas y un lector de pantalla, y ningún auditor externo lo revisó.

La lección que me quedó no fue técnica. Lo que convenció a la dirección fue presentar la biblioteca de componentes, nuestros scripts automáticos y nuestra forma de publicar actualizaciones como maneras de evitar que el proyecto se torciera, no como extras de UX. Eso también protegió el plan cuando llegaron requisitos nuevos a última hora.

  • 40+

    Las piezas que le faltaban al sistema de diseño, construidas en React con instrucciones y pruebas automáticas.

  • Cada semana

    Demostraciones de lo aprendido de los usuarios y de las funciones terminadas, con investigación cada dos semanas.

Lo que dijo mi responsable de entrega

  • En todo esto, Bobby fue indispensable. No solo tenía la habilidad para meterse de lleno en la apariencia y la ejecución del proyecto, sino que dominaba el diseño centrado en las personas y ayudó a formar en esa práctica a muchos de nuestros compañeros consultores. Tenía unas ganas enormes de aprender de todos en el equipo y de compartir lo que sabía. En general, ¡fue un gran activo! Fue un gran compañero de equipo y me encantaría volver a trabajar con él en el futuro.

    Matt Todd Responsable de entrega

¿Tiene preguntas sobre este proyecto?