Establishing common ground across one of the U.S. government’s largest modernization efforts
NBIS (National Background Investigation Services) is the U.S. government’s next-generation personnel security platform, supporting 3.4M+ users across more than 400 federal agencies. As a Senior UX Designer, I led adjudication and continuous-vetting designs across nine scrum teams during a multi-year modernization effort.
The biggest challenge was finding common ground across hundreds of agencies, nine scrum teams, and highly nuanced workflows. Stakeholders needed a common language to discuss the work, and delivery teams needed a common reference for implementation.
3.4M+platform users
400+federal agencies
70+director and SME sessions
9delivery scrum teams
Because clearance constraints limited access to production data, I was not able to evaluate post-launch outcomes.
A Common Language
One vocabulary helped the organization collaborate. A different one helped me evaluate the product.
The setup
NBIS supported more than 400 federal agencies. They all followed the same personnel-security process, but each agency had its own terminology. Labels, statuses, actions, abbreviations, and process names varied by organization, and those differences appeared throughout the product.
To establish a shared vocabulary, I facilitated a dot-voting workshop where directors and subject-matter experts compared competing terms and agreed on shared terminology.
Moving forward, the shared terminology would be used to standardize the NBIS platform.
The tension
When it came time for usability testing, my participants weren’t the same people who had agreed on that terminology. They were investigators and adjudicators who used the system every day, but they weren’t familiar with the newly standardized terms yet.
At first, I thought I could test the new terminology while I ran usability tests.
Instead, every few screens someone would stop and ask,
“What does this mean? We don’t call it that. We call it this. Is it the same thing?”
Even when labels weren’t the problem, the questions themselves became one. An adjudicator might read, “Has the subject ever been charged with drug use?” and immediately begin reasoning through legitimate edge cases. What if it happened years ago? What if it was a misdemeanor? Does this qualify?
Those conversations detracted from the goal of the sessions, and I wasn’t getting the feedback I needed.
I realized the new terminology was getting in the way, and I needed a different approach.
Usability tests were derailed and often left uncompleted until I removed the thing dominating every session.
Dot voting with agency SMEs and directorsCross-agency terminology workshop: comparing candidate terms and voting on shared definitions.
The decision
So I separated them.
I replaced agency-specific terminology with familiar, easy-to-understand questions that didn’t require any domain knowledge. The workflow, layout, hierarchy, and interactions all stayed the same. Only the language changed.
That let participants move through the interface without stopping to interpret labels or reason through policy. I could finally observe how they navigated the product instead of how they interpreted its terminology.
The trade-off
The trade-off was giving up terminology validation in those sessions. That would need to happen through rollout, documentation, and agency training instead.
In return, the usability tests could focus on the question they were designed to answer: whether investigators and adjudicators could complete the workflow. After a brief explanation of the simplified content, participants adapted quickly and stayed focused on the tasks.
Both versions use the same interface structure. The production version uses illustrative criminal-conduct language, while the research prototype replaces it with familiar civic questions so the workflow can be evaluated without agency-specific knowledge.
‹ ›
The same UI stripped of domain expertiseIllustrative reconstruction based on publicly available adjudicative guidance. Not actual NBIS interface copy.
A Common Reference
Turning design knowledge that lived in conversation into a reference every team could use.
The setup
Nine scrum teams were building different parts of NBIS at the same time. The design team couldn’t produce detailed handoffs for every feature, so engineers regularly came to design office hours with questions about component behavior, interaction patterns, and implementation decisions.
The same questions kept coming up. Button placement. Component selection. Interaction behaviors. A component library existed that showed what each element looked like, but much of the reasoning behind it lived in the heads of the designers.
The tension
At first, office hours seemed like the right place to answer those questions. But over time, inconsistencies began to creep in.
Every answer depended on talking to the right designer at the right time.
Implementation knowledge wasn’t universal or shared. It was distributed across the design team. Two engineers could ask the same question on different days and receive slightly different answers simply based on which designers were available to attend office hours at that time.
As the platform grew, that approach wasn’t going to scale.
The decision
I partnered with engineering to create a mapping guide between reusable Figma components and their coded equivalents. It documented interaction states, CSS values, implementation notes, and, more importantly, the reasoning behind when each pattern should or shouldn’t be used.
One example was primary actions. Every view received a single primary action positioned on the far right to represent forward progression. Secondary actions remained subordinate, while tertiary actions supported backward navigation. Instead of becoming another design preference discussed in office hours, the rule became a shared reference every team could apply consistently.
The trade-off
The guide became another artifact that required maintenance and couldn’t account for every edge case. However, it was worth it because it gave every team access to the same implementation knowledge instead of relying on whoever happened to be available to answer the question.
Implementation GuideComponent usage guidance, interaction states, code, and placement rules.
Reflection
Consistency is a decision about what should remain shared.
NBIS taught me that enterprise inconsistency rarely begins in the interface. It begins when stakeholders use different language or teams carry implementation knowledge through conversation.
The answer was not to make everything uniform. I established shared terminology where disagreement blocked collaboration, suspended that terminology where it would distort research, and documented repeatable implementation decisions where oral guidance could not scale. The recurring judgment was deciding what needed to remain stable and what needed room to vary.
