All work

CDC Data Exchange · Professional experience

Make a platform
work as a service.

Connecting public health data capabilities with the onboarding, operating models and shared decisions needed to support them.

Role

Service Designer II

Through Fearless Tech LLC · 2024–2025

Context

CDC Enterprise Data Exchange (DEX), with later service-design framework work across the Office of the Chief Information Officer.

How do separate capabilities
become a coherent service?

DEX already had a product vision and emerging capabilities for data submission, processing visibility, routing, metadata and self-service. Programs, data partners and internal teams still needed a shared understanding of how those capabilities worked together, and what adoption would require.

In the early work, discovery prototypes were being treated as a source of truth for execution. Important functional decisions and technical requirements remained unsettled. I worked across product, research, engineering and operations to make those gaps visible and connect design intent with the work needed to deliver and support it.

Connect the model
to the work.

01

Give teams a shared view

I brought product visions, stakeholders, data flows and operational responsibilities into ecosystem and service models. Routing and metadata became relationships people could discuss together: organizations, programs, users, permissions, data streams and destinations. These models helped bridge technical configuration and the experience of the people adopting or supporting the service.

02

Design the way in

I worked with onboarding, research, engineering and program stakeholders to blueprint how programs and data senders entered DEX. The models connected customer steps with backstage work, readiness, ownership and support dependencies. I also contributed metadata-administration design: a tool for onboarding teams to enter program information that configured how the program and associated actors used the exchange.

03

Create a working connection

I pushed for functional and technical requirements that could support iterative releases, rather than let a prototype stand in for every decision. The DEX Design Hub brought research, service models, roadmaps, delivery planning and readiness into a shared environment. A Community of Practice created a recurring place for teams to bring findings, changes and operational questions together.

A prototype needed a delivery agreement.

THE GAP

Discovery treated as execution

A visual concept was carrying decisions it had not yet resolved.

THE INTERVENTION

Define what each release needs

Connect design intent with functional and technical requirements.

THE WORKING MODEL

Coordinate the whole service

Carry onboarding, configuration and support dependencies into planning.

Explanatory reconstruction of the design reasoning, not an original project artifact.

Adoption needs more than a working capability.

Make the approach
repeatable.

The platform direction and team structure changed during the engagement, shifting the emphasis from the original in-house portal toward support, integration and ecosystem understanding. The service models remained useful because they described people, responsibilities and relationships beyond a particular interface.

Working within an existing service-design initiative, I helped develop shared language, a charter and a repeatable framework for OCIO, alongside a federal sponsor and UX research lead. The approach began with an ecosystem view across Explore, Initiate, Implement and Operate, then deepened into customer profiles, journeys and workflows. Later work applied it to cloud-service discovery and action planning.

A service teams
could reason about together.

The contribution produced ecosystem and metadata models, onboarding and service blueprints, administration design, a connected planning hub, shared learning forums and a broader service-design framework. Together, they made operational dependencies and unanswered decisions visible alongside product delivery.

The work also made room for different ways to participate: technically capable teams could use individual components, while others could use a fuller guided experience. As platform decisions changed, the emphasis stayed on what programs and supporting teams needed to understand, adopt and operate the service.

The work around a product
helps it succeed.

DEX expanded my practice from understanding experiences to designing how a service is adopted, supported, governed and improved. The useful artifact was rarely the endpoint. Its value was in the decisions, responsibilities and conversations it made possible.

What are you
working on?

Start from what you know. We can begin there.

Start a conversation