ADG/REI Systems
2022 - 2025
Shipped & ongoing
Earning the seat, then moving a federal platform off AngularJS
I led the design side of a move from AngularJS to React on one internal federal application. The code was not the hard part. Trust was.
Role
Timeline
Scop
Platform
Overview
I could not migrate a platform until people trusted design enough to invite us in.
Federal staff used one internal application to document cases and move them through a long, form heavy process. People at the end were waiting on a decision about their lives. Where the system failed, work went back to paper.
The app ran on AngularJS, which was no longer supported, with an old design system that had grown one request at a time.
I led the design side of the move to React. The hard part was never the code. Trust had been spent before I arrived, and product owners and technical leads were wary of anyone who said โdesign.โ
Three questions guide this work
01
Can staff get through a case without going back to paper?
02
Can teams build from one trusted set of parts?
03
Can the system keep going without me?
What has changed so far
50+
Reusable components, 47 at WCAG AA
Counted
โ40%
Shorter engineering implementation cycles
Benchmark
โ50%
Fewer visual regressions across 15+ teams
Benchmark
Stakes
The people on the other side of the screen were doing important work with broken tools.
01
Friction
Paper kept winning.
When the system failed, people worked around it.
02
Friction
An unsupported framework.
AngularJS was no longer supported, and every fix added weight.
A system grown one request at a time.
The old design system had no shared rules left.
Confidentiality Note
Not every part of this is mine to share, so I kept the agency and the case details general on purpose.
Before state ยท where the digital flow broke
01
Start case
โ
02
Gather details
โณ Back to paper
โ
03
Review
โ
04
Resolve gaps
โณ Back to paper
โ
05
Decision
Evidence
I went to where the work happens.
I traveled to multiple sites around the country, interviewed the people who use the application every day, and mapped their full workflow from start to finish.
01
Visit the sites
->
02
Interview users
->
03
Map the workflow
01
Can staff get through a case without going back to paper?
02
Can teams build from one trusted set of parts?
03
Can the system keep going without me?
How solid is this?
The conversations
Observed
Direct conversations at multiple sites, not a formal study.
The workflow maps
Observed
Drawn by me and checked with the people who do the work.
The impact
Estimated
Rounded from internal analytics.
Generalized end to end workflow
Staff
Open case
Collect
Review
Decide
System
Create
Validate
Route
Close
Paper
Pain point 1
Pain point 2
I turned evidence into a migration sequence.
The work stayed traceable from field signal to product decision to system effect.
Signal from the work
Design move
What it changed upstream
01
Paper appeared when the digital flow broke.
โ
Map the whole case, not one screen.
โ
Sequence the migration around workflow breaks.
02
Teams rebuilt similar patterns in different ways.
โ
Turn repeated work into shared components.
โ
Give the application kit one trusted base.
03
Partners were wary of another design-led promise.
โ
Join the work and close useful gaps.
โ
Make shared governance feel ordinary.
Decision
Nobody gave us a seat, so we kept showing up until it became ordinary.
01
Wait to be invited.
Safe, and nothing changes while we wait.
02
Ask leadership for a mandate.
Fast on paper. People follow a mandate carefully and own it never.
03
Chosen
Show up, be useful, repeat.
Slow, and it works.
The tradeoff was on purpose
This looks less like a plan at first. There is no launch and no big reveal. But every win came from showing up and being useful before anyone asked.
How it compounded
Small, practical help became trust. Trust became access. Access became a better platform.
01
Make the case
Our design lead held countless one on ones to include us.
02
Show up
We joined meetings that were not ours, sometimes just to listen.
03
Close a gap
A missing spec, a mapping nobody owned, so we took every chance.
04
Become the habit
Product owners started bringing us in early without being asked.
What changed
The lead product owner began treating me as a strategic partner on how to move forward with the migration.
Solution
One application, and a design lifecycle that never stopped.
We did not design the future in one go. We took snapshots of the current state, picked the low hanging fruit, shipped it, and took another. A cross functional tiger team of leads set priorities, and there was politics to navigate along the way.
A loop, not a launch
1
Snapshot
โ
2
Prioritize
โ
3
Ship
Then look again
One table, five perspectives
Priorities for the app and the design system
Design
Engineering
Product
QA
Accessibility
The principal-level move
A component swap would have been easier to explain. It would not have fixed the system.
Not enough
Repaint the old screen
The same workflow problems survive under cleaner components.
โ
What changed
Start with the work
Use workflow breaks to decide what earns a place in the migration.
โ
How it scales
Codify the answer
Turn a solved product problem into a reusable pattern and shared rule.
Generalized Visuals
What changed at component level
These are redrawn examples, not real federal screens. They show the design logic without exposing the agency, product, or case data.
Generalized component example
Actions gained a clear hierarchy.
Problem:
Every action competed at the same volume, so the next step was hard to scan.
Design response:
Give primary, secondary, and quiet actions distinct jobs, then make focus visible.
Before
Continue
Save
Cancel
โ
After
Continue
Save
Cancel
One obvious next step
Visible keyboard focus
Destructive actions stay distinct
Generalized component example
Dense tables became easier to read.
Problem:
Heavy grids made every cell feel equally important and status was buried in text.
Design response:
Reduce visual noise, open the spacing, and let labeled status markers carry meaning.
Before
Case
Status
Case 018
In review
Case 024
Needs info
โ
After
Case
โ
Status
Case 018
In review
Case 024
Needs info
Faster visual scanning
Status uses text and shape
Rows have a clear action
Generalized component example
Forms started helping before people got stuck.
Problem:
Labels, focus, and errors did not explain what happened or how to recover.
Design response:
Pair persistent labels with contextual help, visible focus, and errors that say what to do.
Before
Case category
Select a category
What happened?
Add a short description
โ
After
Case category
Select a category
What happened?
Add a short description
This helps the next reviewer understand the case.
Errors explain recovery
Labels stay attached
Focus follows reading order
Three states, built for the whole journey
Rebuilt
A clearer default
The focus order follows the reading order.
error
Tell us what happened before continuing.
An error that helps
The error is announced to a screen reader.
empty
No case notes yet
Add the first note when you are ready.
An empty state with a next step
Text and controls meet 4.5:1 contrast.
System
Two levels of governance, so teams moved fast without drifting.
Level 1
Design system Storybook
Generic building blocks every product can use.
->
Level 2
Application Storybook kit
Components, patterns and layouts ready for this applicationโs real work.
->
Level 3
15+ product teams
Build from the kit while change flows one way from the base.
Built for real use
Production, not a picture of production.
50+ reusable components mapped to production code. 47 at WCAG AA, tested with keyboard and screen reader.
Handoff, replaced
We wrote the contract together.
Component specs were written with engineers. My design systems partner led the token work, and we supported each other on nearly everything.
Results
Here is what I can count, and what I can estimate.
Fewer visual regressions across 15+ teams
โ50%
Estimated
Shorter engineering implementation cycles
โ40%
Estimated
Less rework
โ25%
Estimated
Better task completion
โ15%
Estimated
50+
Counted
Reusable components
47 at WCAG AA
Internal analytics, rounded. Exact figures withheld because this is federal work.
What I canโt claim
Reflection
A migration is a trust project with a code project inside it.
01
What Iโd do differently.
Trust came from being in the room, in meetings that were not ours and in countless one on ones led by our design lead. Next time I would start that work on day one and plan it like a real workstream, not something that happens on the side.
02
What surprised me.
How little of this was technical. I expected the hard part to be the code. The hard part was earning trust from people who had been burned by a design agency before us. Sometimes sitting quietly in a meeting and just listening was the work.
03
What I do in week two now.
I find out who got burned before me, and I go to their meetings. Then I look for one small gap nobody owns and close it. It is a small act, and it is how the invitation starts.
