Challenge
The IT-governance process is the entry point for launching, recompeting, or decommissioning systems at the Centers for Medicare & Medicaid Services (CMS). Teams often struggled to understand when and how to initiate this process, leading to confusion, inconsistent documentation, and—in some cases—systems operating without oversight ("shadow IT"). Without a streamlined way to request governance or track project status, teams risked falling out of compliance or duplicating work. We set out to design a tool that gives both requesters and CMS complete visibility into funding and governance from day one.
What we heard
"I submitted a request months ago and have no idea where it stands or what happens next"
"We have no way of knowing how many systems are actually running out there — some have never been through governance"
"Half the submissions we get are incomplete. We spend more time chasing documentation than actually reviewing requests"
Business risk
- Federal compliance exposure from systems operating without oversight
- Duplicated IT investments due to lack of visibility into existing systems
- Manual, email-driven process creating bottlenecks and delays across every governance request
Solution
The solution we focused on was a digital platform that streamlined complex government processes by moving paper-based forms online and making them far more intuitive. To ensure accessibility and consistency, I built the experience using the U.S. Web Design System (USWDS) and contributed new form components back to the system. This not only improved the immediate CMS workflows but also strengthened the broader design system for future government projects.
Design constraint: all UI was required to use the U.S. Web Design System (USWDS), a federal standard for government digital services. View design system
Gated Task List with Clear Statuses
Research revealed that Business Owners weren't confused about whether to engage with IT governance — they were confused about why it existed and what was actually expected of them at each step. A dashboard would have shown status, but it wouldn't have answered "what do I do next?" A gated task list did both: it gave users a high-level view of the entire journey while surfacing only the actions relevant to their current step. Gating was a deliberate choice — preventing users from jumping ahead reduced incomplete submissions and the back-and-forth that followed.
Gated task list: Progress tracking interface
A Back Office Tool for IT Governance
The gated task list created a dependency: someone had to manually advance requests through each step. Without a purpose-built tool, that coordination would have defaulted back to email — exactly the problem we were solving. The back office tool was designed as a true companion, mirroring the Business Owner's view while giving admins the additional controls they needed: status updates, internal notes, documentation tracking, and team assignment. Keeping both experiences in sync was a core design principle — any action taken on one side needed to be immediately reflected on the other.
Back office tool: Request management interface
Digitizing the Intake Form & Business Case
The Word document forms weren't just a UX problem — they were an information quality problem. Because the questions lacked context, Business Owners routinely submitted incomplete or misinterpreted answers, triggering clarification cycles that delayed every request. Digitizing the forms let us embed guidance inline, at exactly the point where confusion happened. We also restructured the question flow based on how Business Owners actually thought about their systems, rather than how the governance team had historically organized the paperwork. The result was fewer errors at submission and less manual triage on the back office side.
Digital forms: Intake form and business case interface
Impact
Measurements were collected over the course of a quarter, and we found that EASi was performing well for both Business Owners and back office staff. A 25% reduction in shadow IT reflected greater organizational visibility into systems that had previously gone untracked. An 18% decrease in form submission errors showed that Business Owners were completing documentation more confidently and correctly the first time — reducing the back-and-forth that had long slowed the governance team down. The engagement earned year-over-year contract extensions, a signal that the work was delivering lasting value.
0%
Reduction in shadow IT
0%
Decrease in form submission errors
The back office tool provided the most impact
Discovery
I led an eight-week discovery phase alongside my product and engineering teammates. We traveled to Baltimore to meet with CMS staff directly, combining stakeholder interviews, user interviews, and contextual inquiry to uncover their core needs. This mix of on-site engagement and structured research gave us a grounded understanding of the challenges CMS faced and shaped the foundation for our design approach.
Stakeholder interviews
I conducted a dozen interviews with key stakeholders. One of the most pressing concerns came from Rajiv, the CIO; his biggest pain point was the prevalence of "shadow IT" — systems being developed or operated without going through the formal governance process. This lack of visibility not only undermined CMS's ability to track and manage its technology ecosystem but also posed serious legal and compliance risks. Without knowing what systems are live, who owns them, or whether they meet federal standards, CMS risked falling out of compliance and potentially facing legal consequences.
Stakeholder interviews: Key insights from CIO and leadership
User interviews
We conducted over 30 interviews with potential users, including Business Owners who regularly interact with the IT governance process. Many shared that they had little understanding of why IT governance exists and how it benefits their work. What they needed was a clearer, more transparent process—one that not only shows where they are in the compliance journey but also outlines exactly what steps are required to move forward and complete it.
User interviews: Business Owner pain points and needs
Service blueprint
Our initial research centered on Business Owners and leadership — the shadow IT problem felt most urgent, and our Product Owner had directed us toward the front-end experience. We engaged the back office team later, which turned out to be a mistake we'd have to correct mid-project. What we found when we did engage them was meaningful: request details buried in email threads, incomplete submissions that required constant follow-up, and difficulty determining whether a request needed full governance or simply an LCID reissuance. These weren't edge cases — they were the friction points that quietly slowed every single request down. Understanding them later than we should have shaped how the rest of the project unfolded.
Service blueprint: Front and back office workflow and pain points
Reflections
The most lasting lesson from this project came from a hard conversation about halfway through, when it became clear we had deprioritized the wrong people.
Our Product Owner's early guidance was to focus on Business Owners, the primary requesters using the new system. That made sense given the scope of generative research ahead. But as we got deeper into delivery, the back office team — the people who would actually advance users through the governance process — had needs we hadn't fully surfaced. They were being handed a system they were required to use but hadn't been genuinely heard. Fixing that required descoping parts of the front-end experience to make room for their needs, and those were difficult conversations to have.
That experience crystallized something I've carried into every project since: real service design starts from the inside out. The people running the system behind the scenes are just as much your users as the ones on the front end. When their needs are addressed first, the whole experience becomes more coherent and sustainable for everyone.
Contributing new form components back to the U.S. Web Design System was also an unexpected highlight. It's rare that work on a single engagement can benefit the broader ecosystem of government digital services and that kind of reach felt meaningful in a way that's hard to replicate in a typical product role.