One design system across four DHCS workstreams

Moving a file did not move the decision

All four workstreams were active while the design team moved from Adobe XD to Figma. Importing a file solved the smallest part of the problem. The teams still needed one set of patterns, one place to review them, and a reliable way to carry decisions into delivery.

I treated the transition as a change to the working method. I recreated the existing Bootstrap patterns in Figma rather than inventing a second interface system. The shared files kept the component, its current screen, review status, and delivery notes together.

What the workstreams shared

The tool transition in progress

Review the pattern where people use it

A reusable component only mattered if it held up across real work. The provider-publication overview combines community navigation, search, news, bulletins, and manuals. The manual detail keeps the same navigation and publication structure while adding revision dates and pagination.

I reviewed the pattern as part of those screens, not as a finished component in isolation. When it changed, I kept its usage note and related user story beside the screen so another workstream could recover the decision in the ServiceNow handoff.

One publication structure in two views

Permissions had to expose the service rule

I designed the Submitter Journey permissions screens, including this transaction-and-claim-type dialog. The dialog explains that both parties must be eligible, disables ineligible claim types, and keeps partial selection visible at the parent level.

The artifact establishes only the interface states and hierarchy, not authorization enforcement in a live service, release, or conformance.

See the full dialog and selection detail

Removing an affiliation in the reviewed frames

Rules moved through added, updated, and deleted

OPUS staff maintained data-transformation rules that moved through three states: added, updated, and deleted. Someone reviewing a rule needed to see which items had changed, open the item behind a change, compare it with the approved version, and find a specific record without reading the whole list.

I wrote the requirements for the rule editor as thirteen Gherkin scenarios across three areas: rule navigation, rule details, and search. Each scenario named the window, the trigger, and the expected state, so a developer or tester could check the behavior without interpreting a wireframe.

The editor in three sections

The scenarios settled the small decisions

The editor opened in three sections. View options at the top left filtered the data table to all, added, updated, or deleted items with one radio choice. Action buttons at the top right stayed visible while the table scrolled. The table itself carried the action code, description, and comment for each item.

Two rules did most of the work. View Approved stayed disabled until the selected item was updated or deleted, because an added item had no earlier approved version to show. Search opened the item editor with every field editable, highlighted the first match, and enabled Find Next. When the list ran out, the editor asked whether to search again from the beginning instead of stopping without a message.

Visual consistency was not the test

Figma could show a consistent component. It could not tell me what assistive technology would announce. I checked patterns with JAWS, NVDA, and VoiceOver. For each finding I documented, I named the affected component and changed its guidance rather than treating accessibility as a final visual review.

That made the finding useful beyond the screen where I found it. A later designer or engineer could see which pattern needed attention and why. These checks informed component guidance, but they were not a program-wide accessibility certification.

The component did not decide where it belonged

Go Green showed why the review notes belonged with the interface. The pattern could not appear on every account page simply because the component existed. Submitters did not receive correspondence, so I annotated the screen to remove the Go Green link from submitter pages.

I designed the enrollment and confirmation screens and wrote the review annotation. The enrollment copy contains an unresolved distinction. It calls correspondence enrollment permanent, then says a separate paperless 1099 enrollment can be reversed. I kept that wording visible rather than smoothing it into a cleaner story.

Weekly reviews gave designers, engineers, and state stakeholders a place to test decisions like this across the workstreams. I linked the service rule to the relevant pattern and handoff notes so the next person did not have to reconstruct it from memory.

The service rule in the review note

The proposed enrollment flow