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

UX Designer, design systems specialist

Senior UX Designer, Strategic Partner

UX Designer, design systems specialist

Timeline

2022-2025

2025 - Now

2022-2025

Scop

One federal app, 15+ product teams

5 product teams | 3 efforts

One federal app, 15+ product teams

Platform

Internal enterprise casework application

Internal Enterprise Platform

Internal enterprise casework application

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.

03

Friction

A system grown one request at a time.

The old design system had no shared rules left.

03

Friction

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.

Migration bet 01

Chosen

Show up, be useful, repeat.

Gained

Feedback sooner, less disruption, and room to adjust.

Accepted

Temporary inconsistency while old and new patterns overlapped.

Migration bet 01

Chosen

Show up, be useful, repeat.

Gained

Feedback sooner, less disruption, and room to adjust.

Accepted

Temporary inconsistency while old and new patterns overlapped.

Migration bet 02

Chosen

Build the application kit from the shared system.

Gained

Product speed without cutting the application loose from the base.

Accepted

More coordination across design, engineering, and product.

Migration bet 02

Chosen

Build the application kit from the shared system.

Gained

Product speed without cutting the application loose from the base.

Accepted

More coordination across design, engineering, and product.

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

Action

Case 018

In review

View

Case 024

Needs info

View

โ†’

After

Case

โ†’

Status

Action

Case 018

In review

View

Case 024

Needs info

View

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.

Deep dive

How the tokens connect

+

Deep dive

How the tokens connect

+

01

Primitive

Raw shared values

02

Semantic

Purpose and meaning

03

Component

Local application

Illustrative, generalized

orange.600 โ†’ action.accent

action.accent โ†’ button.active

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

A single dollar figure for this work.

A single dollar figure for this work.

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.