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.
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.
Service blueprint
Our discovery work with the back office team (admin leads) began a bit later in the process, as they didn’t initially surface any major pain points. Early research focused more heavily on Rajiv (CIO) and Business Owners, based on direction from our Product Owner and the broader impact of the shadow IT problem.
That said, the back office team relied on SharePoint, which supported much of their workflow effectively. As we continued our research, some key friction points did emerge: difficulty locating request details buried in email threads, incomplete documentation submitted by requesters, and challenges in determining whether a request required full governance or simply an LCID reissuance.
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.
Gated Task List with Clear Statuses
The IT governance process spans several weeks and includes multiple steps, reviews, and handoffs. A task list provided a high-level overview of all steps in the governance journey while focusing the user's attention on their current step. It offered just-in-time clarity and helped reduce confusion, delays, and the back-and-forth that often occurred due to missing information or incomplete documentation.
A Back Office Tool for IT Governance
Because the gated task list required someone to advance Business Owners through each step, we designed a companion tool for the IT Governance team. This internal tool gave the back office a centralized way to manage all incoming requests. It allowed them to update task statuses, assign team members, track associated documentation, add internal notes, and send communications—all from one place.
Digitizing the Intake Form & Business Case
Two key documents in the governance process—the Intake Form and the Business Case—were originally completed in static Word documents. Business Owners often found the questions unclear, which led to frequent back-and-forth with the IT Governance team for clarification. To reduce friction and improve the quality of submissions, we digitized both forms. This included refining and simplifying the form fields, embedding contextual help and guidance, and adding error prevention features.
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. The result was a more intuitive experience that empowered Business Owners to complete documentation confidently and correctly the first time—saving time for both them and the back office. For the back office, replacing manual emails and scattered SharePoint files, the tool improved efficiency, reduced errors, and ensured smoother handoffs throughout the governance process.
Learnings
At the start of the project, our Product Owner advised us to focus primarily on the customer experience, noting that "the back office works for CMS and doesn’t need all the bells and whistles." Given the scope of generative research ahead, I aligned with that direction.
However, a few months in, it became clear that while the back office team would be required to use the new system, they had significant needs of their own—needs that weren’t captured in our initial discovery. As a result, conversations with them became difficult and frustrating; we had unintentionally deprioritized a critical part of the service ecosystem.
This experience taught me a lasting lesson: start with the back office. Understand their workflows, pain points, and priorities first. When their needs are addressed, the broader service experience becomes exponentially stronger. In this case, it took several hard conversations and a conscious decision to descope parts of the customer-facing experience to ensure a seamless transition for the internal team.
In the end, we successfully replaced their tooling without disruption—but we learned the hard way that real service design starts from the inside out.
.png)
