Overview
UX Lead and one of three front-end engineers on the Quality Assurance Capability, a React application that lets cartographers and NATO-member contractors validate geospatial vector data before submitting it to the National Geospatial-Intelligence Agency. Packaged in Electron so it runs on air-gapped networks.
The Challenge
NGA required contractors from NATO member nations to submit valid vector data, and the existing validator was a Visual Basic application. Microsoft had announced end-of-life for the operating system it depended on. Contractors could not install it at all, which put compliance itself at risk. The legacy tool forced users through stacked modal forms and a six-inch binder checklist, turning every submission into a multi-day slog. Bringing the tool into compliance with modern federal standards meant adopting the U.S. Web Design System. In 2018, that was little more than a style guide and a Sketch template built for websites rather than applications.
Approach
The real work was the cadence. We shipped and demoed every week, and I built an R&D rhythm around the delivery team rather than beside it. Research fed the sprint that was already running, instead of a discovery phase handed over once and forgotten. I led the team in establishing that cadence and set the bar for design practice on it.
Every week the team demoed three things in one sitting: research insights and interview readouts, design prototypes, and working demos of the features actually delivered. Putting all three in the same room is what kept them honest about each other. A prototype had to answer something a readout raised, and a shipped feature had to be the prototype that had been agreed.
The research was field research. We went to military installations to watch the work where it happens, and ran remote interviews with lead users our product owner identified: the people already solving the problem the hardest way, which is where the requirements that matter come from.
01 Introducing USWDS to ReactJS
USWDS in 2018 was a style guide, not a design system. What the programme shipped was a Sketch file and a set of web page patterns: no component library, no application patterns, and no way for an engineer to consume any of it. Its type scale was specified in pixels carried to decimal places, which is a number you can measure off a comp but cannot build to. An application needs modals, wizards, data tables and job states, and none of those existed. Everything below is what we had to make so that a federal standard could be met by a React application at all.
The programme gave us a Sketch file. These are the pieces that had to exist before a cleared, air-gapped React application could claim to meet the standard.
- USWDS React components library
More than 40 components abstracted from the USWDS visual language and rebuilt as React, covering the application patterns the standard never defined: modals, a step wizard, data tables, and job states.
- Storybook documentation
Every component rendered in isolation with its states, so an engineer could take a dependency on it instead of copying a pattern out of a page.
- Jest unit tests tests
Attached per component, which is the difference between a library and a folder of examples.
- Accessibility in the definition of done practice
WCAG 2.1 AA criteria written into user stories and acceptance criteria, with automated linters in CI and manual screen-reader passes, rather than an audit at the end.
The check, explained before it starts
The two-stage check is stated before any upload, and a finished report is reachable without one.
- Design input
- A contractor arriving cold must be able to tell what QAC will check, and roughly how long it takes, before uploading anything
- Action
- DO-01 Front door states the two-stage check as three numbered cards — pick a protocol; payload check; KER checks — and puts a worked sample report one click away behind no upload and no sign-in
- Verification
- Design review against the KER catalogue and the 2020 QAC task flow
- Outcome
- H-01Inconclusiveprototype only, never put in front of a contractor QAC.dc.html, screen 'landing'
Choosing the protocol
The protocol and the reason it was chosen both sit above the upload control.
- Design input
- The protocol a folder is checked against is the single most consequential choice in the flow, and it varies by nation — MGCP 4V4.5, 4V4.4 and 3V4.0 are all live
- Action
- DO-02 Protocol select defaults from the contractor's nation and states its own default in prose underneath; the production ticket is named as the authority when the two disagree
- Verification
- Checked against the nation/schema table in the prototype (10 NATO nations, 3 protocol versions)
- Outcome
- H-02Inconclusivethe default is asserted from the nation table, not from delivery records QAC.dc.html, NATIONS table
Progress that names its substep
Progress names the substep, and says where the job lives if you leave.
- Design input
- A check that takes minutes must not hold the contractor at the screen
- Action
- DO-03 Progress screen names the substep it is on rather than only a percentage; body copy states the tab can be closed and the job picked up under Running checks
- Verification
- Design review; substep labels traced to the payload-check stages
- Outcome
- H-03Inconclusiveno measurement of whether contractors actually leave the page QAC.dc.html, screen 'payload-running'
Failing the payload check
A hard stop: there is no control here that starts KER checks.
- Design input
- KER results computed over an incomplete folder are worse than no results, because they look authoritative
- Action
- DO-04 Payload failure is a hard stop on its own screen: it names each fault; says what the protocol expected instead; and offers only 'fix and upload again'
- Verification
- Walked every control on the failure screen against the state machine
- Outcome
- H-04Passthe failure screen offers no route to KER checks QAC.dc.html, screen 'payload-fail'; state machine has no transition from payload-fail to ker-running
A pass that shows its manifest
A pass shows its manifest, so a real pass is distinguishable from a skipped check.
- Design input
- A passing payload check must show its work, or the contractor cannot tell a real pass from a check that silently skipped layers
- Action
- DO-05 Pass screen prints the layer manifest — 14 layers with feature counts and projection — as a table before offering the KER run
- Verification
- Design review against the MGCP layer list
- Outcome
- H-05Inconclusivenot put in front of a contractor QAC.dc.html, screen 'payload-pass'
Running the restrictions
The long-running stage names the restriction it is on rather than only a percentage.
- Design input
- KER checks run long enough that a bare spinner reads as a hang
- Action
- DO-06 KER progress names the restriction class being evaluated as it moves through them; results are held under Running checks
- Verification
- Design review
- Outcome
- H-06Inconclusiveprototype only QAC.dc.html, screen 'ker-running'
Forty-four findings, placed on the cell
The map is the index into the backlog; the list is sorted so blocking work surfaces first.
- Design input
- Forty-four findings in a list is a backlog; the contractor needs to know where in the cell the work is before deciding what to fix first
- Action
- DO-07 Results pair a real basemap of the coverage cell — markers scaled and coloured by blocking versus advisory — with a condition list sorted blocking-first
- Verification
- Design review; marker styling checked against the blocking flag in the condition data
- Outcome
- H-07Partialthe distinction is carried by colour and radius together, but red/blue was not checked for contrast or for colour-vision deficiency QAC.dc.html, screen 'results'; qac-map.js marker styling
One blocking condition
Plain language and the fix come before the KER identifier, not after it.
- Design input
- A KER identifier tells a cartographer nothing about what to actually change in the production database
- Action
- DO-08 Condition detail leads with plain language; then 'how to fix it' aimed at the production database; then affected features with coordinates; and only then the formal KER definition
- Verification
- Read all six seeded conditions for the plain/fix pair
- Outcome
- H-08Passall six conditions carry both a plain-language statement and a fix; none leads with the identifier QAC.dc.html, CONDITIONS array — six entries, each with plain and fix text
An advisory condition
Advisory findings keep the same layout but say in their own copy that they may be legitimate.
- Design input
- Advisory findings are not defects, and a tool that presents them identically to blocking ones trains contractors to ignore both
- Action
- DO-09 Advisory conditions keep the detail layout but hedge in their own copy where a finding can be legitimate; the advisory chip and marker colour carry throughout
- Verification
- Read the four advisory conditions' plain text
- Outcome
- H-09Passadvisory copy hedges explicitly where the finding can be legitimate QAC.dc.html, CONDITIONS — 'Coincidence is allowed in some cases'
Scoping the report
Format and scope are explicit, and the button restates the choice rather than hiding it in the options.
- Design input
- The report leaves QAC and is worked elsewhere, so its shape has to match the tool the contractor will open it in
- Action
- DO-10 Export makes format and scope explicit choices — .shp for the editor; .csv for the coordinates; both zipped with the summary — and restates the selection in prose
- Verification
- Design review against the format and scope options
- Outcome
- H-10Inconclusiveno contractor has round-tripped an export into an editor QAC.dc.html, screen 'export'
Checks that outlive the tab
One place that survives closing the tab, with a verb per job state.
- Design input
- A contractor runs several cells at once and needs one place that survives closing the tab
- Action
- DO-11 Running checks lists every job with cell; protocol; start time and live progress, giving each a verb matched to its state
- Verification
- Read all four seeded jobs and their actions
- Outcome
- H-11Passthe four job states carry four distinct actions QAC.dc.html, jobs array — View progress / View / Open report / See why
Nothing running yet
The empty state carries the persistence promise, so an empty table does not read as a broken one.
- Design input
- The first thing a new contractor sees on the jobs screen is nothing, and an empty table reads as a broken table
- Action
- DO-12 Empty state explains what will appear and restates the persistence promise; then offers the one action that fills it
- Verification
- Design review
- Outcome
- H-12Inconclusiveprototype only QAC.dc.html, screen 'jobs-empty'
Outcome
We replaced the Visual Basic application with a ReactJS application packaged in Electron, so we could deploy it on physically isolated networks with no connection to public or corporate infrastructure. Contractors installed it on secure laptops without internet access and ran quality checks in the field. Signed installers on removable media let administrators deliver incremental updates inside closed networks. The workflow collapsed to a single screen with drag-and-drop upload, one-click validation, and instant downloadable reports. Because USWDS could not support application patterns, we abstracted more than 40 USWDS-based React components, documented them in Storybook, and attached Jest unit tests, treating the design system as a product rather than a library.
QA cycles went from days to hours, letting contractors deliver packages to NGA sooner and with fewer errors. The tool processed more than 2,000 shapefiles in its first month with consistent results. The application reached WCAG 2.1 AA, verified through automated accessibility linters, manual screen-reader testing, and accessibility criteria written into user stories and acceptance criteria instead of checked at the end. The durable lesson was organizational. In this top-down environment, every end user answered to command, not to a product owner, and no PO treated cartographers as stakeholders. Framing the design system, automation scripts, and deployment pipeline as risk mitigation rather than as UX nice-to-haves secured leadership buy-in and protected scope when late requirements arrived. USWDS has since officially adopted React and Storybook.
Measurement note
The cycle-time claim is qualitative and comes from the project record: contractors reported multi-day validation rounds under the Visual Basic tool and same-day rounds under the replacement. No instrumented before-and-after timing was retained, so the "days to hours" figure is a reported change, not a measured one, and an earlier "roughly 8x" multiplier has been withdrawn for want of a baseline.
The throughput figure (more than 2,000 shapefiles in the first month) is from the delivery team's own usage reporting. WCAG 2.1 AA was verified by automated linters and manual screen-reader testing against acceptance criteria, not by third-party audit.
Traceability
Twelve design inputs from the consumer-redesign concept, each tied to the screen that answers it. The verification column says what was actually checked, mostly the prototype against its own data and state machine, and the gaps column says what was not.
| ID | Hypothesis | Design Output | Acceptance Criteria | Verification Method | Outcome |
|---|---|---|---|---|---|
| H-01 | A contractor arriving cold must be able to tell what QAC will check, and roughly how long it takes, before uploading anything Assumed | A first-time contractor can name both check stages and open a finished report without uploading a folder | Design review against the KER catalogue and the 2020 QAC task flow | Inconclusive | |
| H-02 | The protocol a folder is checked against is the single most consequential choice in the flow, and it varies by nation — MGCP 4V4.5, 4V4.4 and 3V4.0 are all live Evidenced | The selected protocol and the reason it was selected are both on screen before the upload control is reachable | Checked against the nation/schema table in the prototype (10 NATO nations, 3 protocol versions) | Inconclusive | |
| H-03 | A check that takes minutes must not hold the contractor at the screen Assumed | Progress copy names both the current substep and where to find the job after leaving | Design review; substep labels traced to the payload-check stages | Inconclusive | |
| H-04 | KER results computed over an incomplete folder are worse than no results, because they look authoritative Evidenced | A failed payload check exposes no control that starts KER checks | Walked every control on the failure screen against the state machine | Pass | |
| H-05 | A passing payload check must show its work, or the contractor cannot tell a real pass from a check that silently skipped layers Assumed | The pass state names the projection and a per-layer feature count rather than only a pass verdict | Design review against the MGCP layer list | Inconclusive | |
| H-06 | KER checks run long enough that a bare spinner reads as a hang Assumed | Progress copy names a specific KER while running | Design review | Inconclusive | |
| H-07 | Forty-four findings in a list is a backlog; the contractor needs to know where in the cell the work is before deciding what to fix first Assumed | Blocking conditions are distinguishable from advisory ones on the map and in the list without reading a legend | Design review; marker styling checked against the blocking flag in the condition data | Partial | |
| H-08 | A KER identifier tells a cartographer nothing about what to actually change in the production database Assumed | Every condition states a fix in production-database terms before naming its KER identifier | Read all six seeded conditions for the plain/fix pair | Pass | |
| H-09 | Advisory findings are not defects, and a tool that presents them identically to blocking ones trains contractors to ignore both Evidenced | An advisory condition's copy states that it may be legitimate | Read the four advisory conditions' plain text | Pass | |
| H-10 | The report leaves QAC and is worked elsewhere, so its shape has to match the tool the contractor will open it in Assumed | The download control names the chosen format and scope in its own label and note, not only in the option list | Design review against the format and scope options | Inconclusive | |
| H-11 | A contractor runs several cells at once and needs one place that survives closing the tab Evidenced | Each job's action names what will happen for that job's state rather than a generic open | Read all four seeded jobs and their actions | Pass | |
| H-12 | The first thing a new contractor sees on the jobs screen is nothing, and an empty table reads as a broken table Assumed | The empty state names the persistence behaviour rather than only saying the list is empty | Design review | Inconclusive |