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 shared components needed to carry the service rules too: which claim types someone could assign, when a rule could be compared with an approved version, and which accounts should show paperless enrollment. I made those rules visible in the interface and kept the decisions with the work through review and handoff.

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.

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

Both parties had to be eligible before a claim type could be assigned. I designed the Submitter Journey permissions dialog to explain that rule, disable ineligible claim types, and keep partial selection visible at the parent level before saving.

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

An enterprise setting could change what portal users needed to do next. The admin design connected a successful save to a prompt to create a portal alert. The alert editor provided a title, message, and start and end times.

These frames show how configuration and communication could fit into the same task. The example password-reset periods differ between the screens, so they document the proposed interaction rather than one consistent 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.

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.