One design system across four DHCS workstreams

Moving a file did not move the decision

Four DHCS workstreams were moving in parallel while the design team shifted from Adobe XD to Figma. I rebuilt the existing Bootstrap patterns in Figma and kept their screens, review status, and delivery notes together.

The patterns also had to explain service rules. Which claim types could someone assign? When could they compare a rule with its approved version? Which accounts qualified for paperless enrollment? I made those rules visible and kept the decisions beside the screens through review and handoff.

Review the pattern where people use it

I reviewed shared patterns in the screens that used them. The provider library combines navigation, search, news, bulletins, and manuals. Manual details use the same structure, with revision dates and pagination.

When a pattern changed, I kept its usage note and user story beside the screen. Another workstream could then follow the decision through the ServiceNow handoff.

The table needed rules for different values

The Submitter Journey review distinguished a single transaction value from several values in one cell. The annotations kept that difference beside the table, making a small but reusable presentation rule visible during review.

Provider access came before transaction permissions

Assigning a National Provider Identifier, or NPI, allowed the submitter to submit on that provider’s behalf. Transaction and claim-type permissions then controlled the kinds of submissions available for that identifier.

The review added an explanation beside the assignment controls: unassigning an NPI also removed its associated transactions. That consequence needed to be visible before someone changed access.

Permissions had to expose the service rule

Eligibility and assignment were different states. Both parties had to be eligible before a claim type could be assigned, but eligibility did not mean every claim type was selected. I designed the Submitter Journey dialog to keep that distinction beside the action: unavailable choices stayed disabled, selected claim types stayed visible, and a mixed parent checkbox showed a partial assignment before Save.

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

Make the consequences of removal explicit

The removal sequence made the action and its consequences explicit. The confirmation required the submitter name and showed an inline error for a mismatch. The next frame marked the affiliation inactive, while the notification explained that portal access would be deactivated after 45 days without another affiliation.

The review cover below separates readiness for review from readiness for development. It marks the screens ready for review, with development readiness still pending. The sequence records the proposed interaction, error state, and notification, not a released flow.

The administrator needed the relationship history

The DHCS admin view showed the same relationship from another role. A submitter record brought approved transaction types, contact information, and provider affiliations together. Active and inactive affiliations remained visible with their dates and agreements.

That view complements the provider-side permissions flow: it gives an administrator relationship context without repeating the assignment dialog.

Saving the setting was only part of the task

A settings change could create a new task for portal users. The admin design followed a successful save with a prompt to create an alert. Its editor included a title, message, and start and end times.

The proposed flow connected a settings change to the message users would receive. The password-reset periods differ between the screens, so this is a design sequence rather than proof of a saved configuration.

Define the reporting path before filling the table

The reporting work explored how administrators would choose a metric, set a date range, inspect results, and export the data. The flow diagram connected those steps before the screen had to carry every reporting category.

A separate working map grouped reporting needs around the portal, users, organizations, correspondence, and transactions. Its organization branch distinguished providers from submitters and separated registration, testing, and affiliation questions.

The results screen was still being worked out

The results exploration brought metric selection, a date range, counts, and JSON or CSV export into one view. It also retained unresolved layout problems: in the complete frame, table rows extend over the footer. The artifact makes the intended reporting task inspectable while showing where the design remained unfinished.

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 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.

In weekly reviews, designers, engineers, and state stakeholders worked through these decisions across the workstreams. I kept the service rule with its pattern and handoff notes so the next person could follow the reasoning.