CAP Design System
0 → 1 design system built alongside new enterprise products — establishing token architecture, stable APIs, and governance while shipping at speed.
Summary
What This Became
The CAP Design System began as a single-team initiative and evolved into shared infrastructure across Conduent’s automation platform.
What started as a component library became a structural layer that defined how UI decisions were made, versioned, and migrated.
It enabled:
- Multi-brand theming without fragmenting components
- Predictable component APIs across live enterprise products
- Controlled evolution through explicit deprecation and migration paths
- Adoption driven by enablement and tooling rather than mandate
Design intent became durable when it was encoded as tokens and APIs — not screens.
At a Glance
- 0 → 1 system introduced inside active production
- Semantic token architecture separating brand from implementation
- Stable component APIs with explicit versioning discipline
- Kendo Grid wrapped inside CAP abstraction layer to preserve enterprise power
- Governance model centered on cross-team review and migration strategy
- Adoption scaled from one team to three without enforcement
Context
Conduent's Automation Platform and Customer Portal were newly architected products supporting enterprise workflows across multiple surfaces.
Although greenfield, they were being built by parallel teams — and divergence appeared quickly.
- Inconsistent component implementations across products
- Incremental UI decisions creating drift
- No shared governance model to guide expansion
Teams were shipping fast.
Without structure, fragmentation would scale just as quickly.
The challenge was not retrofitting legacy UI — it was preventing new systems from fragmenting before they stabilized.
Core Constraints
CAP and the Customer Portal were newly architected products — but the design system was built alongside them, not after.
We were creating structure in parallel with product delivery, inside a large enterprise organization with legacy org gravity and limited cross-team collaboration.
Key Constraints
- Greenfield products, parallel system build
- Workflows were blank canvases, but the system had to mature inside a 2-week sprint cadence.
- Pre-decided foundations
- Angular and Bootstrap were already in use; Kendo was introduced mid-stream by another team and later incorporated strategically.
- Shared foundation, distinct surfaces
- Automation Platform and Customer Portal required different visual expressions while relying on the same system core.
- Speed first
- Components were often "good enough" at launch, accruing design and technical debt that required deliberate reconciliation.
- Small team, high alignment cost
- With 4-5 designers moving quickly, maintaining consistency required continuous updates across Figma and code.
This was not a centralized rollout with long planning cycles.
It was a fast-moving effort to create durable agreements while products were still taking shape.
Architecture Decisions
We structured CAP as layered infrastructure — design decisions flowing through semantic tokens into components, patterns, and product applications. This hierarchy separated intent from implementation.
Tokens
A semantic token architecture encoded
brand-aware color roles, spacing, typography, and elevation values.
Brand variation occurred at the token layer — not inside components —
allowing visual differentiation while preserving structural
consistency.
APIs
Feature velocity often erodes systems
through incremental, undocumented changes. CAP components were
designed with stable APIs, explicit deprecation paths, and
architectural review for expansion. We optimized for long-term
stability over short-term convenience.
Enterprise Leverage
For complex components like
data grids, we wrapped Kendo UI's Angular Grid inside a CAP
abstraction layer. This preserved enterprise-grade functionality while
applying tokenized styling and standardized interaction patterns. We
didn't reinvent infrastructure — we controlled it.
Governance & Adoption
Adoption was not mandated. It was enabled through direct support:
- Embedded help during early migrations
- Tooling (linting, migration scripts) to reduce friction
- Shared ownership across design and engineering
Within six months, adoption expanded from one team to three. The system scaled because it reduced friction — not because it was required.
Representative Decision: Table Component Evolution
The table component surfaced many of the system's trade-offs.
It was one of the most complex UI elements in the platform — and the clearest example of how small inconsistencies compound at scale.
Rather than rebuild everything from scratch, we reframed the problem:
- Custom-built implementation with limited scalability
- Introduced a Kendo-backed grid wrapped inside a CAP abstraction layer
- Inconsistent styling across products
- Applied tokenized styling to enforce shared spacing, color, and state patterns
- Divergent interaction behaviors (sorting, filtering, state handling)
- Standardized interaction patterns across all product surfaces
- Unbounded configuration growth
- Designed a constrained but predictable component API with explicit versioning discipline
This approach balanced pragmatism and control.
Enterprise functionality was preserved, but governed — turning the table into infrastructure instead of a recurring redesign exercise.
Results
Formal metrics weren't tracked at launch, but the impact was visible:
- Reduced UI regressions through token enforcement
- Faster onboarding for new product teams
- Greater predictability and consistency in UI delivery
Design and engineering began discussing tokens and APIs — not pixels. The system moved from a shared library to shared infrastructure.
What This Reinforced
Design systems are infrastructure — not component libraries, not Figma files, not documentation sites. They are structured agreements about how products scale.
The technical architecture mattered. But governance, trust, and migration strategy determined whether the system survived contact with real teams. Stability had to be chosen over velocity at the foundation layer, so that velocity could be preserved everywhere else.
Opinionated foundations. Flexible implementation. That balance is the work.