A map-data checker that works fully offline

Replacing a dying Windows program that checked contractors' map data for a federal agency's map-data program, with a React app built on the government's own design system

My role

Lead product designer

Employer
World Wide Technology
Client
A federal agency's map-data program
Years
2018 to 2020
Team
Lead designer on a design team of four, alongside front-end and Python engineers
  1. Led the UX of the program that checks map data before it goes to the agency, and built its screens in React.
  2. Set up the weekly rhythm: one demo showing what we learned from users, the prototypes and the finished features, with research every two weeks.
  3. Led the design of, and helped build, more than 40 pieces the government design system was missing, each with instructions and automatic tests.
  • Days→hours to check a batch of map data, as contractors told us; nobody timed it
  • 2,000+ map files checked in the first month, by the delivery team's own counts
  • 40+ screen parts the government design system lacked, built in React with tests
  • WCAG 2.1 AA accessibility standard met, checked by us with tools and a screen reader, no outside auditor

Summary

Contractors had to send map data to a federal agency's map-data program with no errors in it. The only program that could check it was written in Visual Basic, and Microsoft was ending support for the Windows it needed, so contractors couldn't install it at all.

We replaced it with a web app wrapped in a desktop installer, so it runs on laptops that never connect to a network, on purpose. A check takes four guided steps, with no command line: drop the folder in, confirm it's complete, run the detailed checks, and download the report. I led the UX, built screens as one of the front-end engineers, and set the weekly habit that put what we heard from users straight into the work underway.

Who was involved

  • Contractors Had to prove their map data was free of mistakes before sending it to the agency; they ran the tool on secure laptops in the field.
  • Mapmakers Answered to their own leadership; nobody running the project thought of them as the customer.
  • IT staff in closed networks Installed updates from removable drives, digitally signed so they knew the updates were genuine.
  • The design team Two researchers, a technical product owner and me as lead designer.
  • Front-end and Python engineers World Wide Technology's engineering team; I was one of the front-end engineers, building the screens in React.
  • Program leads A product owner, a business analyst and a delivery lead.
  • The agency's own team The agency's engineers and product owner worked alongside us, for a sponsor inside the agency.
The results screen. A headline reads '44 things to look at' with a chip for 2 blocking conditions and the run's provenance: the data standard, the cell, finished 14:22. Below left, a map of the tile carries large red markers for blocking findings and smaller blue ones for advisory, inside a dashed cell boundary. Below right, the six conditions are listed blocking-first with their counts.
Problems on a map. The map shows where each problem is, and the list puts the must-fix ones at the top.

Context

The old checker was written in Visual Basic, an old Microsoft programming language, and Microsoft had announced it would stop supporting the version of Windows it needed. Contractors couldn't install it at all, which put the whole requirement at risk. Using it meant clicking through one pop-up form after another while following a checklist from a binder six inches thick. Every submission took days.

Federal rules also said the new tool had to follow the U.S. Web Design System (USWDS), the government's design system. In 2018 that was little more than a style guide and a template file, meant for web pages, not for a working program.

Research

A plan diagram of how the checker reached its users. Outside, a signed release is copied to a removable drive. The drive is carried by hand through the site's checkpoint. Inside, on a closed network with no internet, IT staff check the signature before installing it on offline laptops, where contractors check their map data. A dashed path marks the research team visiting on site to watch the work.
Crossing the air gap. Releases reached offline laptops on signed removable drives, and we went on site to watch the work.
A plan diagram of how the remote interviews connected. The research team's laptop takes a government smart card in a card reader, and the card's certificate and PIN prove who is connecting. The connection runs as an encrypted tunnel across a shared network, where a gateway checks the certificate before it passes. Inside the secure site, the people doing the work join a video session. The checker's offline laptops are marked as never on this connection.
Interviews over a smart-card line. Between visits we interviewed people by video, over an encrypted connection the card's certificate unlocked.

The research was field research. We went to the secure sites where the work happens to watch it, and interviewed by video the people our client contact pointed us to: the ones already doing this job the hard way, because they know best what the tool really has to do.

After that we did research every two weeks. Each weekly demo showed three things in one sitting: what we had learned from users, the prototypes we were designing, and the features we had finished. Every prototype had to answer something we had heard from users, and every finished feature had to match the prototype we agreed on.

Design

The new program is a web app wrapped in a desktop installer, so it installs like any desktop app and runs on computers with no network connection at all. A check takes four guided steps, with no command line: drop the folder in, confirm it's complete, run the detailed checks, and download the report. Updates came on removable drives, digitally signed so the IT staff inside those closed networks knew they were genuine.

The government's design system had nothing for a working program, like pop-up windows, step-by-step wizards or data tables, so we built more than 40 of those pieces ourselves in its style, in React. We wrote instructions and automatic tests for each one, and wrote accessibility into every feature's to-do list from the start instead of checking at the end.

The front door. A thin banner across the top reads 'An application for data producers.' A hero reading 'Check your data before it ships' sits above Start a check and See a sample report, beside a sample-report card showing a map with red and blue markers and a condition list: point not inside area 6, area feature not transferred 12, complete duplicates 4. Below, three numbered cards explain how a check works: pick a schema and upload, we check the payload then the detailed rules, you get a map of what to fix.
The front page. The front page explains the steps of a check before you upload anything, and lets you open a sample report first.
The payload check failed. A red rule tops the card, which reads 'Three things are wrong with the folder' and explains that the detailed rule checks cannot run until the payload is correct. Three faults are listed: a missing roads layer, an unexpected EPSG:3857 projection where the protocol expects EPSG:4326, and two files not part of the protocol. The only actions are Fix and upload again, and Download the payload log.
A hard stop. If a layer is missing, the projection is wrong or stray files are in the folder, the tool stops here and lists exactly what's wrong. There's deliberately no button to skip ahead to the detailed checks.
A blocking condition opened: Point not inside area, 6 features affected. Plain language leads: a well head recorded outside its facility boundary, so anything grouping points by containing area will miss them, followed by 'How to fix it', which directs the edit to the production database. A map shows where it happens, and a table lists affected features by layer and position, showing 3 of the 6.
One must-fix problem. Each problem is explained in plain English, with how to fix it; the rule number is a label, not the headline.

More screens

The payload check passed. The card reads 'The folder has everything it should' and summarizes 14 layers, 61,208 features, EPSG:4326. A table lists each layer with its feature count and a Complete status, above the button that runs the detailed rule checks.
A pass that shows its work. When the folder passes, it lists the layers it found with their feature counts, so you can tell a real pass from a check that never ran.
The detailed rule checks running against 61,208 features and 96 restrictions. The progress note names the rule being evaluated, a containment rule, and a line below states the results will be held under Running checks.
Running the detailed checks. The slow step names the rule it's checking right now, not just a percentage.
The download step for one tile, 44 features, against the data standard. Format options offer .shp only, .csv only, or .csv and .shp, each with a note on what it is for; scope offers all 44 features or blocking only. The download button names the chosen format, and a note restates what the current selection will produce.
Choosing what goes in the report. You pick the file type and what to include, and the download button repeats your choice instead of hiding it in the options.
The Running checks list. Four jobs are shown with cell, protocol and start time, each with a plain-text status and an action matched to its state: View progress for a run at 62%, View for one queued, Open report for a finished run with 27 features, and See why for one whose payload check failed. A note states that checks keep running if the tab is closed and finished reports stay for 30 days.
Checks that keep running. Checks keep running if you close the tab, and each one has a button that fits where it's at: view progress, open the report, or see why it failed.

Outcomes

Contractors told us checking a batch of map data went from taking days to taking hours, so they got their data to the agency sooner. Nobody kept a before-and-after timing, so that is their account, not a measurement. The tool checked more than 2,000 map files in its first month, by the delivery team's own usage counts. It met the federal accessibility standard (WCAG 2.1 AA); we checked that ourselves with automatic tools and a screen reader, and no outside auditor reviewed it.

The lesson that stuck with me wasn't technical. What got leadership on board was pitching the component library, our automatic scripts and our way of shipping updates as ways to keep the project from going wrong, not as UX extras. That also protected the plan when new requirements showed up late.

  • 40+

    Missing design system pieces, built in React with instructions and automatic tests.

  • Weekly

    Demos of what we learned from users and the finished features, with research every two weeks.

What my delivery lead said

  • In all this, Bobby was indispensable. Not only was he skilled enough to jump into the look-n-feel and execution of the project, but he was extremely well-versed in human-centric design and helped mentor many of our consulting teammates in the practice as well. He had a strong urge to learn what he could from everyone on the team and to share what he knew. Overall, he was a great asset! He was a great teammate and I would love to work with him again in the future.

    Matt Todd Delivery Lead

Questions about this project?
enesru