Design System Operations at USCIS

This case study documents a multi-year effort to reconcile three independently evolving appointment-scheduling systems at USCIS. The work is presented using a slide-based synthesis paired with written commentary.

At the outset, this was not framed as a “design system project” in the abstract. It was a practical attempt to reconcile three appointment-scheduling products that had evolved independently, organizationally, technically, and politically.

Each system had its own contract, stakeholders, and operating assumptions. None had benefited from sustained design involvement, and over time each accumulated UI and workflow decisions that were locally rational responses to immediate needs.

The result was not just surface-level inconsistency for users, but a deeper fragmentation in how teams understood the scope and structure of their products. Decisions made sense within individual contexts, yet there was no shared framework for reasoning across them.

This context mattered because consolidation could not be approached as a single unifying act. Progress depended on methods that allowed alignment to emerge incrementally, respected existing responsibilities, and created neutral ground for shared understanding. The solution space was therefore as much organizational as it was visual.

Impact

• Increased stakeholder buy-in and collaboration
• Reduced page number by 64%
• Reduced average user task completion time by ~20%
• Established first-ever:
  • cross-product design system governance process
  • cross-contract research repo
• Reduced onboarding complexity for designers and developers.
• Achieved 79% adoption of design system components across 3 applications

These outcomes reflected the cumulative effect of many small, deliberate decisions rather than a single moment of redesign. Reductions in page count, improvements in task completion time, and increased adoption emerged from sustained alignment across teams, particularly around shared abstractions, consistent patterns, and clearer decision-making processes. Equally important were qualitative shifts: faster onboarding, clearer communication, and a common framework for evaluating future change.

The issues outlined here, inconsistent UI, ad-hoc hierarchy, and competing stakeholder priorities, were tightly coupled.

The absence of a design strategy didn’t just produce messy interfaces, it created an environment where new functionality could only be expressed by adding pages, duplicating views, or creating bespoke exceptions. Over time, this led to deep navigation trees and redundant surfaces that obscured how the system actually worked.

Importantly, these problems were not caused by negligence or bad intent. They were an emergent result of product owners operating under pressure, without shared abstractions or a neutral framework for reasoning about change. Any durable solution had to address that root condition.

The most durable outcome of this work was not a cleaner interface, but a more resilient way of building software inside a complex institution.

By treating abstraction, iteration, and governance as design problems rather than administrative overhead, teams were able to coordinate without sacrificing autonomy. Alignment emerged gradually, disagreements became easier to resolve, and the system could evolve without repeatedly revisiting foundational decisions.

In that sense, the design system was not the product of the work, it was the condition that allowed the work to continue.

Starting Small

Rather than attempting a sweeping redesign across all products, I deliberately started small.

InfoPass was the least complex of the three systems and had a product owner who was open to experimentation. This made it an ideal environment to test an approach that emphasized research, abstraction, and incremental convergence, without placing other teams at risk.

This was a recurring pattern throughout the project: reduce stakes where possible, demonstrate value locally, and let adoption grow through credibility rather than mandate.

Step 1: Gumshoe Research

The first step was what I call “gumshoe research”, because the goal was not only to identify usability issues, but to understand how the system functioned as a whole.

This meant learning:

• How work moved between departments
• Why certain forms or fields existed
• Where handoffs broke down
• Which constraints were technical versus institutional

Because UX research was still relatively new in this context, much of the value came simply from making the system legible, to myself, to stakeholders, and eventually to other teams. Making this research visible and reusable across contracts helped establish trust and reduced duplication of effort.

Step 2: Nouns and Verbs Inventory

The second phase was what I call the Nouns and Verbs inventory exercise.

By describing the product in terms of entities (nouns) and operations (verbs), we were able to reason about functionality without prematurely arguing about screens or layouts. This abstraction made overlaps obvious and disagreements less personal, because conversations shifted from “my page” to “this operation on this kind of object.”

In practice, this documentation acted as a shared reference point across design, development, and product. It also created a bridge between research findings and UI decisions, ensuring that consolidation was grounded in real workflows rather than aesthetic preference.

The Solution: Converging on Patterns

Convergence here was not about enforcing consistency for its own sake. It was a way of making shared intent visible across teams that had been solving similar problems in isolation. By identifying where products already overlapped, in data structures, operations, and workflows, it became possible to align incrementally, without requiring full agreement up front. Over time, this approach created enough shared structure for coordination to emerge alongside ongoing product work.

Level 1 Convergence: Elemental

There are many levels of convergence. At the lowest level we have things like these two tables here. One filters by last name and first name, the other by “full name”. this is small and could be justified but it also increases cognitive load if there isn’t a good reason for the divergence.

Simplifying by standardizing display patterns reduces confusion, and reduces dev effort and streamlines maintenance.

Level 2 Convergence: Page

A level up we can see another form of convergence at the page level.

We have a “Manage Users” page and “List of Employees” page. Both pages list all Users of the app, so why two pages?

In several cases, separate pages existed primarily because different stakeholders had requested slightly different views of the same underlying data. Without a design framework to unify these requests, the only available solution had been duplication.

By reframing these views as role-based variations on a single pattern, we were able to consolidate functionality without removing capability, preserving flexibility while dramatically simplifying the information architecture.

Level 3 Convergence: Structural

At the highest level of abstraction, most of these interfaces were doing the same thing: querying records, displaying results, and enabling operations on those records. Here we can see two pages, “Manage Appointments” and “Manage Sites” with very different internal page hierarchies, and filtering and record operation patterns.

Once this was acknowledged explicitly, it became possible to design a consistent grammar for how records are browsed, filtered, and acted upon, regardless of domain. This insight laid the groundwork for scalable patterns that could extend beyond the initial products.

The resulting solution replaced deep, nested navigation with a single, flexible record-management pattern.

By separating concerns, page-level actions, bulk actions, and record-level actions, and giving users control over filters and visible columns, the interface became both simpler and more powerful. Importantly, this approach reduced the need for future bespoke pages, allowing new use cases to be expressed through configuration rather than new development.

Applying these patterns to Adjudications highlights just how much complexity had accumulated over time. Examine this old Adjudications page which has 5 layers of page hierarchy.

Similar to InfoPass a lot of this page hierarchy was because of unstrategic page expansions to suit use cases as they cropped up. One page would have specific fields or filters, and other pages would have different fields or filters. Getting rid of these would be bad! Users depended on these specific workflows. So how could we accommodate existing User behavior while also making the workflows still workable?

In this context, the challenge was not eliminating functionality, but making it transparent. The introduction of quick filter presets allowed existing workflows to remain intact while clearly communicating how different views related to one another. Users could now see, and control, the differences between pages that had previously felt opaque.

We see here a neutral view.

And here with the quick filter selected, we get the same functionality as the old pages but transparently see its relationship to the filter controls on the side:

This change had three important effects.

• First, it made the system’s behavior visible, reducing confusion about why different views existed.
• Second, it established an extensible pattern for future needs, lowering the cost of change.
• Third, it shifted control toward users, allowing them to adapt the interface to temporary or evolving workflows without requiring new development.

Taken together, this reduced both user frustration and long-term maintenance burden.

The Big Idea (why all this works)

Design systems are often thought of as UI kits or component libraries, but more fundamentally they function as social contracts between and within product teams about how work gets done. The goal here wasn’t to deliver a set of assets, but to facilitate decision-making in a way that was agile, flexible, strategic, and resilient over time.

What this work ultimately enabled was a shared language for people to interface. Once interactions were described in terms of records, actions, states, and roles, design discussions shifted away from preference and toward intent. That shared language made coordination possible, and it required a governance model that could support incremental alignment rather than enforce uniformity.

Rather than enforcing standards top-down, the system was designed to be opt-in and incremental. Products didn’t need to align all at once. The goal was not uniformity, but coordination: creating enough shared structure that teams could act independently without pulling the system apart over time.

Crucially, standards emerged from product work and were then socialized outward, not imposed top-down.

Convergence was not treated as a single moment of standardization, but as an ongoing process of identifying common ground across products and expressing it at increasing levels of abstraction.

With this structure in place, the question shifted from whether alignment was possible to how it would emerge in practice.