Building client confidence with HCD

New Projects, New Opportunities

I joined the Transformed Medicaid Statistical Information Systems (T-MSIS) team as a contractor for the Centers for Medicare & Medicaid Services (CMS) just as they were completing a massive system upgrade. As we moved past that milestone, I knew it would create real opportunities to elevate the Human Centered Design practice because there would be more capacity and flexibility to explore user needs and address usability issues. The question was: could I lead the HCD team to take advantage of this opportunity?

Many of our stakeholders had deep content knowledge about healthcare data, but less experience with product development and design. So the path to success required more than identifying the right problems or solutions, we had to make these ideas compelling and bring our stakeholders along for the journey. 

This would be a new approach for the HCD team. Historically, the team had been expected to function more reactively. Designers would be handed a general idea and apply their various skills to refine the basic concept, then build out assets to support development. Shifting into a more proactive role, where researchers and designers also helped prioritize pain points worth solving or introduce novel solutions would require earning the trust of CMS stakeholders, Product Owners and engineers. 

As the HCD team lead, it was my job to work with the whole HCD team, coaching them to  operate in peak form. Fortunately, I knew an HCD team consisting of UX designers, UX researchers, service designers and content strategists, already had the skills required to identify opportunities and deliver results. We just needed to apply them to a new subject: ourselves. 

Applying our skills

I knew there was a much better chance of building lasting changes if the team members were personally invested, so decided to introduce this topic through a workshop framed like a collaborative design session. I started by flipping the opportunity on its head so it read more like a traditional design “problem”: if the HCD team can’t demonstrate its value to CMS stakeholders, then we’ll never get the chance to have more ownership over our workstreams or reach our full potential. Not only did this create a “problem” the team could “solve”, it provided real incentive for them to do so. I knew team members were already eager for more ownership and opportunities to flex their skillsets, so this was their chance.

Naming and prioritizing the stakeholders
we wanted to engage focused the rest of the conversation

Next, we set out to define our “users”, the stakeholders at CMS we needed to engage and inspire. Fortunately, the team was already familiar with who these stakeholders were and their function within T-MSIS operations. While no one had extensive experience working with every stakeholder, their combined experience gave us solid coverage. To develop a sense of shared understanding, I gave the team time to list out what drove these stakeholders (ie what they cared about) on sticky notes. Then, we grouped the notes to remove duplicates and identify themes of interest we could leverage to showcase the value of our work:

• Progress - evidence our work was moving T-MSIS towards stated goals like OKRs

• Efficiency - increasing the speed and volume of T-MSIS outputs

• Risk reduction - identifying and eliminating risks before they could negatively impact the program or its operations

• Organization reputation - positioning T-MSIS as leaders within larger CMS department

• Personal sentiment - feeling their input was heard and appreciated by the rest of the team

Messy Figjam, clean ideas

Acting on Opportunities

Although it was essential to understand the framing that would resonate with our stakeholders, we couldn’t leverage that understanding without concrete opportunities to present our work and ideas. In our second session, we focused on identifying existing opportunities and creating new ones. For example, demos at T-MSIS were typically only used for showing off code, but why couldn’t they be used for sharing a prototype, a usability test, or a new service artifact? 

We also discussed how work could be shared more effectively outside of live calls and meetings. Topics included:

• What was the best medium for sharing?

• When was the right time to share?

• How should that work be positioned at various stages? 

• How should we want to prompt people to engage?

Mitigating Risks

In our third session, we focused on risks — what could go wrong if we tried to engage stakeholders in these new and different ways? How could we mitigate those risks? The most pressing concern from team members was the amount of effort it would take to put these strategies into action. They acknowledged that preparing demos, recording videos and writing compelling content all took time. And time was something that was already at a premium. 

Together, we identified two primary mitigation strategies. First, I would work with Product Owners to allocate more time to these activities. Second, they would work with counterparts in product and engineering to more explicitly recognize their contributions. For example, rather than using a demo strictly to focus on code output, UX designers could pair with developers to present collaboratively or provide lightweight assets for developers to present on their behalf. This would reduce the burden of effectively socializing design work, without undercutting the impact.

Beyond the Workshop

The workshop helped the team identify opportunities and strategies for building the trust and investment that would allow them to play a more proactive role in the program, but we still had to actually put them to use. To extend the collaborative approach that had been so successful at laying this foundation, I made follow up conversations a regular part of our HCD team meetings. After each cycle of agile work planning, we would map out the opportunities to showcase our efforts and contributions. This allowed practitioners to learn from one another and spread our presence over the cycle. While other teams often had to compete for attention at the end of a sprint or quarter, we would be sure to have a continuous presence to reinforce our value at every stage of the product development process. 

Mapping our strategies for when and how the team will showcase the value of our work

Changing the Game

This workshop and the corresponding conversations initiated a major shift in the HCD team’s role at T-MSIS. Practitioners moved beyond simply posting design artifacts to sharing more nuanced aspects of their craft. They focused on sharing the “why” behind their design decisions and the outcomes they drove in a way that was explicitly tied to stakeholder priorities. 

They also started sharing their work more frequently, and this did more than just speak to stakeholder interests, it helped deliver on them. When designers started sharing work earlier, it helped identify issues, misunderstandings, and misalignments. This allowed the program to refine ideas and iterate before development began, rather than the costly rebuilds that were required when issues weren't surfaced until code demos.

All together, these changes steadily built stakeholder confidence and allowed the team to contribute in new and exciting ways. Content strategists were able to streamline their review processes. UX designers were able to embrace a dynamic where stakeholders focused on sharing needs or concerns and trusted the design team to validate those ideas and propose effective solutions. To sum it up, it became a lot more common to hear CMS stakeholders respond to questions with “Well, what does the HCD team think?” and the HCD team was ready to answer.