USCIS Global
Cutting a legal document's drafting time from 45 minutes to 7, by rebuilding a government workflow around the people who actually use it
I led the redesign of Notice to Appear (NTA) generation for USCIS, replacing a manual, multi-system process with one guided draft-and-review flow inside the interface officers already used. The new design reduced the average time to generate documents start to finish from 45 minutes to 7 minutes (84% reduction), and now saves over 5,700 hours a month agency-wide, up from 4,300 at launch.
Date: Fall 2025 - Present
About this case study. To protect government data and system details, no production UI can be shown here. So I rebuilt the key screens as a standalone coded prototype using made-up data. What you see below is the research, architecture, tradeoffs, and measured outcomes, not the live system.
Officers used to move between disconnected screens with no sense of progress. The redesign puts drafting and review in one guided flow, so it is always clear what is done, what is next, and what each step requires.
The problem
Notices to Appear (NTAs) are among the core documents in the asylum process, and USCIS generated them with custom software that had taken on years of patchwork fixes.
The thing that stuck with me early on was watching how the work actually happened. Generating one NTA meant moving between systems and re-entering data that already existed elsewhere. It also meant trusting that the officer picked the right template every time, and never missed overwriting or deleting a placeholder in the document.
The current state
We found it took an average of 45 minutes, across three different roles, to draft a single NTA. The process was slow, and because so much of it was manual, it was error-prone. These are legal documents with real consequences for the people named in them. A version that drifted out of sync, or a field quietly left as a placeholder, could confuse the person receiving the notice and expose the agency to legal challenge.
"I mean it's tedious because you have to read through everything to make sure it's in the proper place. Kinda makes me feel like [the drafting tool's] a little untrustworthy sometimes."
— Officer feedback, discovery research
"You literally have to know what all these codes mean so that you're generating the right letter."
— Officer feedback, on finding the right template
Before and after overview of the document generation process.
My role
I was the lead designer on a cross-functional Agile team of engineers, product owners, and USCIS stakeholders up to the branch-chief level. I owned the end-to-end UX: I ran the requirements and research, mapped the current state, framed an automation-first direction, designed and iterated the high-fidelity flows, and documented the component patterns the build relied on.
Problem
Analysis revealed that the existing document generation process failed both the asylum applicants and the government users in several ways:
-
Labor-intensive workarounds: Staff must manually update templates and stitch together data from disparate systems
-
Inconsistent output: Version control errors and exceptions led to legal documentation mistakes
-
Missed automation opportunities: Repetitive tasks that should be automated consumed significant staff capacity
-
Poor feedback loops: Users lacked in-context validation or error-handling guidance
These friction points created compounding inefficiencies, regulatory anxiety, and user frustration.
Research phase
We started by mapping the whole NTA issuance journey end to end, working with subject-matter experts, engineers, and other designers to document how the current process actually ran. From there I framed the direction: remove manual work where we could, pre-fill from data we already had, and instrument the flow so we could measure outcomes from the start.
The research phase also comprised:
-
Three rounds of research totaling about 8 hours of interviews, three role types, and five field offices
-
Stakeholder workshops and co-design sessions to solicit ideas from our stakeholders and subject-matter experts on the client team
A couple of takeaways surprised me. The main one was how much officers wanted to customize the text in the templates. The process couldn't be plug-and-go. But at the same time, we saw certain manual text overrides being used over and over, which told us where automation could safely do the work instead.
A summary of our current state analysis and the improvements of our solution.
Building and testing
With a workflow map in hand, we moved into building and testing an automation-first drafting experience. The goal was to eliminate manual data entry wherever possible by reusing common templates and pre-filling from data already in the system. Early on, officers could generate a draft in seconds and then move through a structured review wizard that kept progress visible, reduced backtracking, and made clear what each step required.
Before:
"It takes a lot of trial and error going back and forth to review the letter to make sure it came out the way you wanted, which is kind of inefficient."
— Officer feedback, discovery research
Just as important as speed was control. We centralized drafting and review into one tool to resolve the version-control problems and the "multiple sources of truth" that had built up over years of workarounds. Instead of copying content between screens or keeping parallel edits, officers could create, review, and revise in one guided flow, with clearer guardrails and fewer chances for template drift.
To make sure it held up in real conditions, we ran small pilot groups and rapid feedback cycles: share a prototype, test an assumption, fold what we learned into the next build. That cadence helped us tune the wizard's pacing, clarify review checkpoints, and surface edge cases early. Within two months the pilot expanded several times as office leaders asked to add their own testers, and it rolled out across the full field office network.
One example of an update we made after pilot testing was adding a manual override to the job title that appears automatically next to a supervisor’s signature. This was because we learned that some supervisors are in an “acting” role and we had to account for that potential title mismatch when we auto-populated a person’s title. An incorrect title was a legal risk that would lead to downstream issues, so we were very careful to always give an option to customize the title to ensure all documents were signed properly.
I also kept accessibility in view throughout. The wizard used existing components from our product's design system alongside the US Web Design System (USWDS), so it met federal accessibility requirements rather than bolting them on at the end.
Drafting used to start from a blank template stitched together by hand. Here the draft generates from existing case data in seconds, so the officer's first job is to review, not retype.
Constraints and tradeoffs
We made deliberate trade-offs to deliver value quickly while leaving room to iterate. Tight timelines meant the MVP focused on the essentials: a reliable end-to-end flow, strong template reuse, and the most common scenarios needed to issue NTAs with confidence. We deferred lower-frequency edge cases and nice-to-haves on purpose, to stabilize the core before adding complexity, and to let real usage tell us what to build next.
Templates were the clearest example. USCIS maintains around 20 NTA templates, but we found that 4 covered about 95% of cases, so that's where we started. After the pilot we added three more based on what officers asked for, including one entirely new template that had never existed before.
The biggest constraint was procedural, not technical. Unlocking the next level of efficiency required changing the workflow itself, which meant advocating with leadership and aligning across roles. By reordering two steps, we cut development time by an estimated 2 to 3 months and enabled more automation earlier in the process. The change also reduced the number of people involved in producing a document from three to two, which lowered handoffs and delays and closed off a set of errors.
Each step asks only for what it needs and shows where the officer is in the process, cutting the backtracking and guesswork of the old flow.
38 min
Time savings (84% reduction) to generate documents for users
25.8k hrs
Time savings in last 6 months across 34.6k documents generated
200
Average number of officers per week using our generation tool
Results
The revamped document-generation workflow provided immediate and measurable efficiency improvements for USCIS staff, enhancing consistency and confidence in a crucial process. By replacing disjointed, manual drafting tools with an integrated experience within the officers' existing interface, the team minimized repetitive data entry, eliminated frequent copy-and-paste errors, and significantly streamlined the drafting and review process, making it easier to learn. This led to a more seamless end-to-end experience, reducing operational friction and establishing a reliable foundation for producing legally sensitive documents at scale.
The impact was significant: our core user group saved about 38 minutes per document, equating to an 84% reduction. In the six months following the release, the enhanced workflow saved an estimated 25,800 staff hours across over 30,000 generated documents, averaging about 4,300 hours saved each month.
Adoption rates continued to grow, with the system supporting 23,000 documents and saving around 5,700 hours per month during the most recent three-month period, indicating increased usage and sustained performance. Currently, approximately 200 officers use the tool weekly, indicating that the new workflow not only improved metrics but also earned trust as part of their daily operations.
What’s next? This tool is still in its early stages, with our research revealing more opportunities to expand its capabilities. Things on the roadmap are expanding the case types available for this tool, specifically cases with multiple dependents that need to be dealt with all together. I am also looking to add more powerful attachment preview capabilities after learning that supervisors wanted to view the actual attachments that their officers were preparing. Their attention to detail was such that we couldn’t just show them a file name, we had to let them open a preview.