Skip to content
California CWS-CARES

Transforming a statewide product and the design organization behind it.

I joined a high-pressure modernization where design was struggling to reconcile worker needs, state policy, stakeholder expectations and technical constraints. I rebuilt how the team worked while reshaping the product foundation for scale.

My roleProduct Design Lead
Design organization10 designers
Program scale3 workstreams
Reach58 counties
~65%
improvement in design delivery
~45%
improvement in development efficiency
The transformation combined operating-model change, information architecture, design systems and stronger design-engineering collaboration.
Salesforce OmniStudio · Hundreds of screens · Statewide platform

CWS-CARES was operating under critical timelines, but the design organization was caught between competing realities. Workers needed an experience that reflected how they actually managed complex cases. State policy defined what the system had to support. Stakeholders brought another layer of priorities and expectations. Engineering had technical constraints that were not consistently understood by design.

The result was significant rework. Approved designs did not always translate into what was ultimately built. The product lacked a coherent information architecture, reusable patterns and a scalable component foundation. Workers were becoming frustrated, stakeholders were losing confidence and the existing approach could not scale across a statewide platform.

Artifact 01 · The alignment problem
Worker needsReal casework + trust
State policyRequirements + constraints
Stakeholder prioritiesDecisions + expectations
Technical realityFeasibility + delivery
PRODUCT EXPERIENCEWhere every tension had to be resolved
Misalignment created rework, quality issues, lost trust and a product that could not scale.

I met separately with designers, engineers, developers, leadership, workers and stakeholders to understand how each group experienced the problem. The failures were not isolated. Team structure, product structure, delivery and decision-making were reinforcing one another.

Team structureResponsibilities were not consistently aligned to capability and experience.
Product structureThe application lacked an IA strong enough to organize the experience and data around the worker mental model.
Delivery structureDesign and engineering were not creating decisions together early enough.
Decision structureWorker needs, policy, stakeholder expectations and feasibility were being reconciled too late.
The answer was not another design review. The operating model needed to change.
Leadership in practice
Reorganized around strengthsReassigned responsibilities based on capability and experience so designers could operate with clearer ownership.
Rebuilt trustCreated space for workers to be heard while translating policy and technical realities into a path forward.
Connected the teamsEstablished regular design-engineering working sessions so questions and constraints surfaced earlier.
Stayed close to craftLed workshops, discovery, IA, flows, design reviews, design-system work and developer handoff alongside the team.
Pressure point · Two root causes, two different interventions
01 · The team lacked Salesforce design fluency Designers were hesitant to make decisions without engineering. Agreements made with users during design sessions could later be reversed during build, creating bottlenecks and stakeholder frustration.
What I changed I worked with each designer to identify the root cause, then partnered with leadership to create an incentive program for Salesforce courses and certifications. The team gained the platform knowledge to make more informed design decisions and collaborate with engineering with greater confidence.
02 · The product architecture did not match the work The system was being built around a flat information model, but child welfare cases quickly become nested and connected. Preserving that architecture would make it harder for workers to understand the full family picture and move efficiently through active work.
The decision I led design, engineering and leadership workshops to make the case for accepting some rework now rather than scaling the wrong mental model. We moved toward a multi-level structure that grouped connected cases, preserved working context and supported multiple open workstreams.
The tradeoff was clear: accept some rework now, or scale an experience that did not reflect how child welfare work actually happens.

I reorganized design responsibilities around capabilities and experience. I established regular working cadences between design and engineering so technical constraints, customization possibilities and out-of-scope requests were understood before solutions reached approval.

I also led workshops with workers to understand their needs and frustration while helping them understand policy and technology constraints. The goal was not to let one group win. It was to create a product direction everyone could understand and execute.

Artifact 02 · Operating model before and after

Before · sequential handoffs

Workers
Design
Stakeholders
Engineering
Development
→

After · shared decisions

Workers + policy + stakeholders
Product + design + engineering
Shared product decisions
Reusable system
Delivery

The lack of IA was not simply a navigation problem. It affected how workers understood cases, how information was collected, how data moved through the application and how future capabilities could scale.

I worked directly on the IA and discovery alongside the team. The new structure allowed the experience to move away from fragmented information toward a more complete case context. Workers could connect related cases, keep relevant information open, navigate nested information more logically and access a broader global view of a case.

Artifact 03 · Reconstructed global-case IA
GLOBAL CASE CONTEXT
Related cases
People + relationships
Intake information
Services + actions
Documents + history
Persistent context, connected information and nested structure helped workers move through the case without losing the larger picture.

I introduced the design system as a solution to a scalability problem. Instead of design producing a library and handing it to development, designers and engineers built the component foundation collaboratively. That gave engineering a voice in technical behavior while giving design a reusable system for maintaining experience consistency.

Artifact 04 · Design system architecture
Experience principles
→
Design patterns
→
Reusable components
→
Flexible layouts
→
Product workstreams
Design and engineering co-created the component foundation, making adoption easier and reducing one-off implementations.
~65%improvement in design delivery after rebuilding team structure, governance and cross-functional ways of working.
~45%improvement in development efficiency through reusable components and closer design-engineering collaboration.

Beyond the metrics, the program had a stronger design-engineering partnership, more consistent product decisions, a reusable product foundation and a better ability to scale across workstreams.

The outcome was not simply a redesigned application. The work left behind a stronger design organization, operating model, information architecture, cross-functional cadence and reusable product system.

The work scaled because better product decisions no longer depended on one person making every call.

Visuals are reconstructed and anonymized to protect client confidentiality.

Next case

Designing responsible AI for high-stakes child welfare decisions.

Pennsylvania DHS · Responsible AI · Human-in-the-loop · Statewide modernization

Back To Top