California Department of Corrections and Rehabilitation

Creating a multi-platform design system, launching multiple products, plus human-centered design training.

Table of Contents

Overview & Problem #

California Department of Corrections and Rehabilitation (CDCR) needed a better way to build and manage digital tools used by parole agents, staff, and formerly incarcerated people across a portfolio of products.

Their software process was outdated and not serving them. Some issues they had were:

  • Releasing new software took years
  • There wasn’t consistency across products
  • Their apps didn’t work offline and needed alternative distribution outside app stores
  • Caused harm to incarcerated people due to no human-centered design processes
  • Caused duplicated effort from offline reporting

This case study contains information about two products:

Role #

During my time there, I built and evolved a design system and touched multiple products. I led and coached a cross‑functional design team alongside PMs, engineers, and new designers.

I also embedded human‑centered design practices across CDCR’s culture and built a multi-platform design system.

CDCR’s Design System #

A multi-platform design system.

Sample documentation from the design system, complete with buliding blocks and instructions.
Sample documentation from the design system, complete with buliding blocks and instructions.

I worked with the engineering team to understand both what and how they were building so I could better support them. They were locked into two frameworks, Vuetify and PrimeVue. So the design system needed to serve both those frameworks. They’d merge eventually, but that wasn’t on the roadmap.

First, I needed to audit the existing six applications the team maintained to find out what’s working, what isn’t, and unnecessarily duplicated efforts.

What I found:

  • UI was inconsistently styled, which created long-term issues.
  • Teams built multiple versions of the same component, slowing work.
  • Work spanned two frameworks and two versions of each, which added complexity.

I knew after learning this that I’d need to lay some scalable foundations. I needed to build as I went, so that started with sending them some snippets that defined the variables they’d be using.

This immediately boosted consistency, but more work was needed. Next, I consolidated duplicates and overlapping components into a design language engineering could build.

Structure & Governance #

The design system needed structure if it was to grow, so I built it with these principles, which would inform every aspect of what we built, from components to tone of voice:

  1. Clarity: What we make should be focused. We can’t use a system that bloats.
  2. Flexibility: Anything we made needed to be adaptable and the system should be open to bi-directional feedback.
  3. Openness: Bring PM, Eng, and others along. Make sure we build with accessibility.

Here’s how we’d decide what features to build.
Here’s how we’d decide what features to build.

Part of getting started was establishing where we created and made updates to the design system.

To that end, I needed to be selective about what entered the system while still allowing for bi-directional flow. Anyone could propose changes, as a good system evolves with its team.

I also needed to ensure we could have this support multiple frameworks, so this governance and structure allowed that flexibility. While each framework could have its unique aspects (e.g. micro-interactions) the overall feel felt in the same family because I’d implemented consistent icons, colors, typography, and components (tables, charts, page templates, etc.)

I also implemented variables and tokens, which allowed other teams to theme projects in ways they wanted (and enabled dark mode!) without breaking the design system.

Top: A unified component I created. Bottom: the multiple map components I used.
Top: A unified component I created. Bottom: the multiple map components I used.

The Outcome #

  • Reduced product delivery timelines: We dropped release time to weeks with the design system in place, plus some other operational improvements like adding backlogs, and scheduling feature releases.
  • Increased engineering efficiency with standardized components: Engineers didn’t have to guess at what component we needed to use, everything was clearly labeled and had consistent atomic building blocks with plenty of examples to follow.
  • Gained organization-wide adoption: The design system is still in use today and has now spread to 10 projects.

VIMO #

A Progressive Web App for parole agents to manage visits with parolees. It used the design system I created.

The caseload for a parole agent.
The caseload for a parole agent.

Problem #

After meeting with stakeholders and interviewing parole agents as well as their supervisors, I learned just how difficult parole management was for everyone involved.

My key findings:

  • Workload: Agents managed too many cases, which led to errors.
  • Documentation: About 60% of work happened offline while a digitization mandate required duplicate entry.
  • Complexity: Agents navigated legal, labor, ethical, and practical constraints that slowed innovation.
  • Safety: Field visits could be dangerous without clear check-in protocols.
  • Visits: Many visits lacked documented accommodations for cognitive, speech, or vision needs, which reduced effectiveness.

My Approach #

I used (and evolved) the design system as the project progressed. I prototyped, tested, and validated every significant flow before handoff, which cut months of rework and kept engineering focused on delivery instead of unnecessary back-and-forth.

A mobile view of a profile with obligatory reference to The Office.
A mobile view of a profile with obligatory reference to The Office.
Complex tables on mobile.
Complex tables on mobile.

To address workload, I designed a supervisor dashboard that made caseload balance visible and actionable. Agents could see recent check-ins and who was out of compliance at a glance. Coverage during vacations or leave became easier because supervisors had a clear picture of who needed attention.

For documentation, I audited end-to-end tasks and moved them into a single digital flow on state-issued phones, laptops, or tablets. VIMO integrated cleanly with the central system through formats aligned with institutional rules. I coordinated with adjacent teams to remove duplicate entry and reduce manual cleanup.

For safety, I created a visit check-in feature that notified supervisors of planned visits. Missed check-ins after a set time triggered follow-up so teams could act quickly.

The Outcome #

VIMO’s update was a success. After launching, it:

  • Reduced parole agent workload by 50%.
  • Reduced opportunities for bias in reporting.
  • Improved safety and accountability in high-risk parole scenarios.

Other Efforts #

Some of the materials covered in the course.
Some of the materials covered in the course.
In parallel with building the design system and other products, I created comprehensive training programs covering human-centered design methodologies, user interviews, prototyping, and testing.

This training empowered CDCR teams to conduct independent user research, quickly validate hypotheses, and iterate effectively. The programs offered both self-guided and instructor-led formats, each personally developed by me, featuring tailored coaching and live collaborative sessions.