Fixing how UX work happens across teams and systems

What was breaking down

This project began with what seemed like a design system problem, but quickly revealed something deeper.

The system in place was tied closely to an Engineering implementation of Telerik components. It provided a starting point, but it didn’t function as a shared model that UX, Product, and Engineering could rely on.

More importantly, the way work moved through the system was inconsistent. Product and UX were refining workflows with stakeholders while Engineering was building ahead—often without clear direction and seeking validation afterward.

Feedback loops were unstructured. Weekly reviews intended to validate feasibility frequently shifted into subjective critique and didn’t align with the actual delivery process.

There was no shared understanding of:

• What constituted a complete design
• When work was ready for implementation
• How UX and Engineering should stay aligned

On the surface, it looked like communication issues. But in practice, the issue was structural.

The system didn’t hold together.

What made this complex

The complexity wasn’t just in the product—it was how multiple systems, tools, and teams interacted without a shared structure.

UX, Engineering, and tooling operated as partially connected systems, creating constraints that limited flexibility and fragmented implementation.

The design system was tightly coupled to Telerik components and token constraints. Tokens could not be repurposed without breaking alignment with Engineering, making even small refinements difficult.

At the same time, the visual foundation introduced usability issues. Color themes aligned with marketing created brand consistency, but were not validated for accessibility or interaction clarity. In practice, this led to:

• Insufficient contrast between states
• Minimal distinction between hover and pressed states
• Unclear visual feedback

The system was technically consistent, but not always usable.

UX and Engineering tooling were also misaligned. Some Figma components did not map cleanly to Blazor equivalents, and Engineering occasionally implemented custom components independently, further fragmenting the system.

Review processes added additional friction. Feedback sessions lacked structure and did not consistently focus on implementation feasibility.

The system was optimized for implementation consistency, but not for usability, accessibility, or cross-functional alignment.

There was no shared model for how UX work should move from design to implementation in a predictable way.

My role in this

My role was to understand why the existing ways of working kept creating the same problems, then help the team introduce more structure where it would matter most.

That meant:

• Understanding how workflows were being designed and built in parallel
• Identifying where alignment was breaking down
• Clarifying what needed to be defined for UX and Engineering to work from the same model

I worked closely with Product and Engineering to surface gaps—not just in the UI, but in how work was structured. From there, the focus shifted to introducing consistency in how work was reviewed, handed off, and implemented.

How we approached it

Stabilizing how work moves through the system

The first step was not to redesign components, but to address how work was progressing. Engineering was often building ahead of validated designs, while feedback came too late to be actionable. To address this, I introduced a structured UX sprint review at the end of each sprint. These reviews aligned UX, Engineering, and Product around UI-related work before it was finalized, allowing teams to:

• Validate work earlier
• Refine implementation within the same sprint
• Reduce carryover and rework

A critical part of this shift was refining how work was handed off. Handoff had been inconsistent and relied heavily on interpretation. We clarified what “Done” meant—what needed to be present for Engineering to move forward confidently—reducing ambiguity and improving alignment.

Creating more intentional feedback loops

I shifted away from ad hoc check-ins toward more structured collaboration. Reviews were reframed to focus on:

• Alignment with design intent
• Implementation feasibility
• Gaps between design and execution

To further reduce ambiguity, I introduced a prototype-driven approach to design communication. Rather than relying on static screens, prototypes were used to make behavior and workflows more explicit—helping stakeholders understand intent and giving Engineering clearer guidance for implementation. This shifted conversations from interpretation to shared understanding.

Working within constraints

At the same time, I developed a deep understanding of the existing system, including:

• Telerik tokens and component constraints
• Figma-to-implementation mappings
• Where customization was possible and where it was not

This allowed me to work within realistic constraints while identifying where those constraints limited usability and clarity.

Recognizing the underlying problem

Through this work, it became clear that the issue was not component-level. It was structural. The existing system supported reuse within a single product, but did not define how UX should operate across workflows, teams, or products. Without that structure, inconsistency was inevitable.

What changed

Creating alignment across UX and Engineering

Introducing a structured review model improved how teams worked together. Introducing a structured UX review loop replaced an informal, reactive process with a more predictable model for alignment across Design, Engineering, and QA.

Instead of reacting after build, teams could:

• Review implementation against design intent
• Resolve issues earlier
• Maintain momentum within sprint cycles

This reduced friction and made delivery more predictable.

Bringing consistency to how work is defined

As alignment improved, it became easier to define what “Done” meant. Instead of relying on interpretation, the team established:

• Clearer expectations for design readiness
• More consistent handoff practices
• Shared understanding of workflow behavior

This created a foundation for more reliable implementation.

Shifting from a UI kit to a system mindset

At a broader level, the focus shifted from working within a UI kit to thinking about UX as a system. Instead of asking how to improve individual components, the conversation became:

• How to create consistency across workflows and products
• What “look and feel like Evolent” actually means
• How to support multiple systems with a shared approach

Where it’s going

The larger opportunity is to turn what we learned at the product level into a model that can support the broader product ecosystem. That means defining where consistency matters, where flexibility is necessary, and how a shared UX approach can work across different technical environments.

Current focus areas include:

• Mapping the full product ecosystem
• Understanding the role of different product categories
• Identifying technical constraints
• Validating assumptions
• Defining a system flexible enough to support multiple codebases

The goal is to establish a model that enables consistency at scale.

What this reinforced

The operating model was part of the design

The challenge wasn’t improving individual interfaces—it was defining how the system operates.

Good work still needs the right conditions to succeed

Even strong designs fail without shared understanding across teams.

Constraints reveal where structure is missing

Token limitations and tooling gaps exposed deeper systemic issues.

Process changes can create product leverage

Defining how work is reviewed, completed, and applied consistently had greater impact than any single design decision.