# Design System Usage Telemetry for Enterprise Platforms: How to Spot Unsafe Forks and Expensive Exceptions Early

Feb 8, 2024

By Oleksiy Kalinichenko

Design systems become harder to govern when teams cannot see where components are used, wrapped, forked, or overridden across products and brands.

This article explains how **design system usage telemetry** turns a component library into an observable platform capability. It shows which signals help teams identify unsafe forks, unmanaged variants, outdated packages, and exception-heavy surfaces before they turn into migration delays, accessibility drift, and long-term frontend debt.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240208-design-system-usage-telemetry-for-enterprise-platforms "Summarize this page with ChatGPT")[](https://claude.ai/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240208-design-system-usage-telemetry-for-enterprise-platforms "Summarize this page with Claude")[](https://www.google.com/search?udm=50&q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240208-design-system-usage-telemetry-for-enterprise-platforms "Summarize this page with Gemini")[](https://x.com/i/grok?text=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240208-design-system-usage-telemetry-for-enterprise-platforms "Summarize this page with Grok")[](https://www.perplexity.ai/search/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240208-design-system-usage-telemetry-for-enterprise-platforms "Summarize this page with Perplexity")

![Blog: Design System Usage Telemetry for Enterprise Platforms: How to Spot Unsafe Forks and Expensive Exceptions Early](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20240208-design-system-usage-telemetry-for-enterprise-platforms--cover)

A design system can look healthy from inside its own repository while quietly fragmenting everywhere else.

That is a common enterprise problem. The core team sees polished Storybook documentation, versioned packages, and a roadmap for new components. Product teams, meanwhile, are wrapping primitives, copying code into local packages, adding one-off variants for a single market, and delaying upgrades because the real cost of migration is unclear. By the time anyone notices, the system is no longer a shared foundation. It is a brand name attached to many partially compatible implementations.

This is where **design system usage telemetry** matters.

Used well, telemetry does not monitor people. It monitors the _system_: which packages are installed, which components are imported, where wrappers are proliferating, which variants are overused, which overrides appear repeatedly, and where outdated versions are concentrated. That visibility makes governance more practical because teams can act on evidence instead of assumptions.

For enterprise software organizations operating across multiple products, brands, or monorepos, usage telemetry can become a core operating capability. It helps design system leads make deprecation plans with confidence, helps frontend architects identify risk before major migrations, and helps UX platform teams focus on the exceptions that are creating the most cost.

### Why component libraries fail when teams cannot see real usage

Most design systems do not fail because their components are poorly designed. They struggle because the organization cannot see how the components behave once they leave the central library.

A [component library](/services/component-libraries) catalog answers only a limited set of questions:

*   What components exist?
*   What props do they support?
*   What usage patterns are recommended?
*   Which version is current?

Governance requires a different set of questions:

*   Which teams are still on old package versions?
*   Which components are heavily adopted versus nominally available?
*   Where are local wrappers replacing direct consumption?
*   Which products rely on unsafe style overrides?
*   Which one-off variants are spreading beyond their original use case?
*   Which surfaces are likely to have accessibility drift because they have diverged from the source component?

Without that visibility, enterprise teams usually fall into a few predictable traps.

First, they overestimate adoption. A package may be installed broadly while only a small subset of components are actually used. Or usage may be shallow, with teams consuming tokens and primitives but bypassing higher-level patterns.

Second, they underestimate fragmentation. A local `Button` wrapper may look harmless until every product has built its own version, each with different analytics hooks, loading states, and accessibility handling.

Third, they plan migrations blind. Deprecating a prop, renaming a component, or changing a token contract sounds manageable in the library repository. It becomes expensive when dozens of downstream overrides and wrappers are discovered late.

The issue is not a lack of standards. It is a lack of observability.

### The telemetry model: package versions, component imports, variants, wrappers, and overrides

For design systems, telemetry works best when it captures several layers of signal rather than a single adoption number.

A practical model usually starts with five categories.

#### 1\. Package version telemetry

This is the baseline.

You need to know which applications, packages, and workspaces depend on which design system versions. In a monorepo, this can often be collected from lockfiles, workspace manifests, or dependency graphs in CI. In federated repositories, package registry data and scheduled scans may be more realistic.

Version telemetry helps answer:

*   Which teams are current?
*   Which teams are one or more major versions behind?
*   Which deprecated packages are still installed?
*   Which upgrades are blocked by specific product areas?

This is often the fastest way to identify upgrade risk before a platform-wide migration.

#### 2\. Component import telemetry

Version data is necessary but incomplete. A product can declare a dependency on the library and barely use it.

Import-level telemetry tracks which components are referenced in source code. In React codebases, that can come from static analysis of imports such as:

*   direct imports from the main design system package
*   imports from package subpaths
*   imports from deprecated compatibility packages
*   imports from locally re-exported component wrappers

Import telemetry reveals real adoption depth. It also shows whether teams are using the supported API surface or routing usage through local abstraction layers that can complicate change.

#### 3\. Variant and prop telemetry

The next level is understanding _how_ components are used.

For example:

*   Which `Button` variants are dominant across products?
*   Are teams relying heavily on a soon-to-be-deprecated `kind="tertiary"` prop?
*   Is a layout component frequently used with escape-hatch props that bypass intended composition?
*   Are teams passing custom render functions that make upgrades brittle?

This data can come from source analysis, codemods run in reporting mode, or controlled runtime instrumentation for anonymous aggregate counts. The goal is not to inspect user data. It is to understand API usage patterns that affect governance.

#### 4\. Wrapper detection

Many design system risks hide in wrappers.

A wrapper is not automatically a problem. Some are legitimate and strategic, such as a product-level `AppButton` that injects analytics, brand-specific defaults, or app-specific permissions behavior. The governance issue begins when wrapper usage becomes opaque.

You want to know:

*   Which local components wrap core design system primitives?
*   How many layers exist between product code and the source component?
*   Are wrappers thin adapters or behavioral forks?
*   Do multiple teams solve the same problem differently?

In a monorepo, AST analysis and dependency graph inspection can identify components that import a design system component and then re-export their own API. In federated repos, repository scanners and naming conventions can still provide partial visibility.

#### 5\. Override and escape-hatch telemetry

Overrides are where design intent often erodes fastest.

Common signals include:

*   custom CSS targeting design system internals
*   prop combinations that disable default behaviors
*   token substitutions outside supported theming mechanisms
*   slot replacements or custom render hooks used to circumvent standard patterns
*   accessibility-related props overridden at the product layer

These do not always indicate misuse. But concentrated override patterns usually point to one of two issues: the design system does not support a real product need, or teams are bypassing the system because governance is weak. Both cases matter.

### How unsafe forks and local exceptions appear in multi-team platforms

Enterprise platforms rarely fragment through one dramatic decision. They fragment through accumulated exceptions.

A team under delivery pressure copies a component into the app because the release window is tight. Another wraps the upstream component because one brand needs a slightly different visual treatment. Another keeps an old version because a deprecated prop still powers a large customer workflow. None of these choices feels catastrophic in isolation.

Across a multi-brand platform, though, the pattern becomes visible.

Unsafe forks and expensive exceptions often show up as:

*   multiple local components with nearly identical names and behavior
*   product-level wrappers that expose props not available in the upstream component
*   repeated CSS overrides against generated class names or internal DOM structure
*   inconsistent token mappings by brand or market
*   applications locked to stale versions because they rely on removed APIs
*   accessibility fixes applied locally rather than contributed upstream

Telemetry helps distinguish between healthy extension and unhealthy divergence.

A healthy extension pattern usually has these characteristics:

*   the wrapper is documented
*   the reason for the extension is clear
*   the abstraction is reusable across multiple products
*   the wrapper stays close to the underlying API
*   ownership is known
*   there is a path for upstream contribution if the need becomes common

An unhealthy divergence pattern usually looks different:

*   the wrapper exists only to preserve legacy behavior
*   local props mask unsupported states
*   styling depends on implementation details
*   one-off variants spread informally across teams
*   no one can estimate migration cost without manual investigation

This is especially important in multi-brand delivery, where brand-specific requirements can either be absorbed into a scalable theming and composition model or explode into parallel component systems. Telemetry shows which direction the platform is moving.

### Metrics that actually help: adoption depth, stale versions, override hotspots, accessibility risk surfaces

Many design system dashboards fail because they track vanity numbers. Total npm downloads, Storybook views, or package installation counts can be useful context, but they do not tell a governance team where risk is accumulating.

The most useful metrics are decision-oriented.

#### Adoption depth

Adoption depth is more useful than broad adoption.

Instead of asking whether an application uses the design system, ask:

*   how many core components it uses directly
*   which component categories it relies on, such as forms, navigation, tables, overlays, or content presentation
*   whether usage is concentrated in low-level primitives or in approved higher-level patterns
*   whether products use the shared theming model rather than local styling workarounds

This helps distinguish real platform alignment from superficial dependency presence.

#### Stale version distribution

A simple but powerful dashboard shows version spread across products and packages.

Useful slices include:

*   current major version adoption
*   products one major version behind
*   products on deprecated packages
*   average time since last upgrade by application area
*   components with the highest usage on stale versions

This creates a concrete basis for migration planning. It can also identify where to invest in compatibility tooling, codemods, or upgrade guides.

#### Override hotspots

Not all overrides matter equally. Teams should identify where overrides cluster.

Examples of meaningful hotspot views:

*   components with the highest number of custom CSS overrides
*   components most often wrapped locally
*   products with the highest concentration of escape-hatch props
*   brands relying most heavily on token substitutions outside the supported theme layer

These hotspots often reveal either missing capabilities in the system or areas where governance standards are unclear.

#### Accessibility risk surfaces

Telemetry cannot replace accessibility testing, but it can highlight where accessibility risk is more likely to exist.

For example, risk often increases when:

*   a component has many local forks
*   teams override semantics or focus behavior
*   products remain on versions older than important accessibility fixes
*   wrappers intercept keyboard or click behavior
*   deprecated props affect labeling, status messaging, or interaction states

A dashboard that combines stale version data, wrapper prevalence, and override counts can help prioritize accessibility review where it will matter most.

#### Exception aging

An exception is much easier to justify in the week it is created than a year later.

Track exceptions as operational objects:

*   what the exception is
*   where it exists
*   why it was approved
*   who owns it
*   whether it has an expiry or review date
*   whether it has propagated to additional products

This turns exceptions from hidden debt into managed inventory.

### Instrumentation options in Storybook, CI, repositories, and runtime analytics

The best telemetry model is usually layered. No single collection method captures the full picture.

#### Storybook as the source of intended usage

Storybook is useful, but mostly as a baseline for what _should_ happen.

It can provide:

*   canonical component and variant inventories
*   metadata about supported props and deprecations
*   documentation coverage signals
*   reference examples for pattern comparison

If your Storybook stories are structured well, you can also export metadata that helps downstream tooling compare actual usage against supported variants.

Storybook alone is not telemetry. It is the contract side of the equation.

#### CI-based static analysis for code usage

CI is usually the most practical place to collect usage signals at scale.

In React and monorepo environments, teams can run static analysis to capture:

*   imports by component and package
*   deprecated API usage
*   wrapper patterns
*   style override markers
*   token usage outside approved theming entry points

This can be implemented with AST tooling, ESLint custom rules, codemods in reporting mode, or repository graph analysis. The output can be stored as aggregate JSON reports per repo, package, or application and then rolled into dashboards.

The advantage of CI instrumentation is that it is repeatable, privacy-safe, and directly tied to code that will ship.

#### Repository and registry scanning for cross-repo visibility

In enterprises with multiple repositories, not everything can be captured from one monorepo pipeline.

Repository scanners and package registry data can complement CI by showing:

*   which repos depend on which packages
*   where deprecated packages still appear
*   which applications have stopped upgrading entirely
*   which internal packages may be shadow design systems or local forks

This is especially useful for organizations with a mix of modern platform teams and older business-unit-owned applications.

#### Runtime analytics for aggregate behavioral patterns

Runtime analytics should be used carefully and sparingly.

For governance, the safest use is anonymous aggregate telemetry such as:

*   counts of rendered component families by application area
*   counts of deprecated variants still appearing in production bundles
*   coarse-grained theme or brand usage patterns
*   detection of unsupported runtime configuration states

Runtime data can help validate whether code-level usage reflects real product exposure. But it should not be used to infer individual developer performance or team productivity. That crosses into the wrong problem and usually creates mistrust.

### Governance workflows for deprecation, migration planning, and contribution review

Telemetry only becomes valuable when it changes decisions.

A mature [design system architecture](/services/design-system-architecture) team uses telemetry inside recurring workflows.

#### Deprecation planning

Before deprecating a component, prop, or variant, review:

*   where it is used
*   how deeply it is embedded in critical product flows
*   whether wrappers amplify its usage footprint
*   whether accessible replacements are already available
*   whether migration can be automated with codemods

This changes deprecation from an announcement into an executable plan.

#### Migration sequencing

Not every migration should start with the loudest request or the newest component release.

Telemetry helps sequence migration work by showing:

*   the highest-risk stale versions
*   products with the fewest blockers and fastest upgrade path
*   components whose changes unlock multiple downstream packages
*   exception hotspots that should be resolved before a major version release

This is particularly useful in enterprise programs where platform changes must align with quarterly product planning.

#### Contribution review

Telemetry can also improve design system intake.

When a team proposes a new variant or component, reviewers can ask:

*   is this pattern already being implemented locally in multiple places?
*   are there override hotspots indicating a genuine unmet need?
*   does this request solve a recurring cross-brand issue or a narrow one-off case?
*   will upstream support reduce risk more than leaving the behavior in local wrappers?

This creates a stronger basis for deciding what belongs in the core system versus what should remain product-specific.

#### Exception governance

Every enterprise design system has exceptions. The goal is not zero exceptions. The goal is visible, reviewable, expiring exceptions.

A lightweight governance loop often includes:

*   exception registration
*   owner assignment
*   review cadence
*   migration target or upstream resolution path
*   dashboard visibility for aging and spread

That prevents exceptions from silently turning into parallel standards.

### What telemetry should not be used for

There is an important boundary here.

Design system telemetry should not be framed as employee surveillance, a measure of individual productivity, or a tool for ranking teams. That approach damages trust and usually leads to distorted behavior, such as teams optimizing for metrics instead of platform health.

It also should not become an excuse for central teams to reject all local variation. Some wrappers and exceptions are valid. Some product constraints are real. Some brand-specific needs should remain outside the core library.

The purpose of telemetry is narrower and more useful:

*   reduce hidden delivery risk
*   identify migration cost earlier
*   find component sprawl before it hardens
*   surface accessibility drift sooner
*   make governance decisions based on actual usage patterns

When teams understand that the system is being observed rather than the people, telemetry becomes much easier to adopt.

### From static library to observable platform capability

A design system becomes operationally stronger when it can answer not only _what it offers_ but _how it is actually used_.

For enterprise platforms, that is the difference between a library that looks consistent in Storybook and a platform capability that can be governed across products, brands, and delivery teams.

If you can see package versions, imports, wrappers, variants, overrides, and exception spread, you can usually act before fragmentation becomes expensive. You can plan deprecations with less guesswork. You can target migrations where they will have the most effect. You can spot accessibility risk surfaces earlier. And you can separate legitimate extension from unsafe forks.

That is the real value of **design system usage telemetry**. It does not make governance heavier. It makes governance more precise.

In large frontend organizations, precision is often what keeps a shared system scalable, especially in multi-brand environments like [Arvesta](/projects/arvesta), where Storybook-driven component governance helped keep shared UI patterns aligned across repositories.

Tags: Design Systems, design system usage telemetry, component usage analytics, frontend governance, design system observability, Enterprise software

## Explore Design System Governance and Drift

These articles extend the same enterprise design system problem from different angles: versioning, testing, accessibility, and governance. Together they show how teams can detect drift earlier, manage change more safely, and keep shared UI foundations aligned across products and brands.

[

![Component API Versioning for Enterprise Design Systems: How to Evolve UI Contracts Without Breaking Product Teams](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260505-component-api-versioning-for-enterprise-design-systems--cover?_a=BAVMn6ID0)

### Component API Versioning for Enterprise Design Systems: How to Evolve UI Contracts Without Breaking Product Teams

May 5, 2026

](/blog/20260505-component-api-versioning-for-enterprise-design-systems)

[

![Design System Accessibility Drift in Multi-Brand Platforms: How Variant Growth Quietly Breaks Compliance](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260521-design-system-accessibility-drift-in-multi-brand-platforms--cover?_a=BAVMn6ID0)

### Design System Accessibility Drift in Multi-Brand Platforms: How Variant Growth Quietly Breaks Compliance

May 21, 2026

](/blog/20260521-design-system-accessibility-drift-in-multi-brand-platforms)

[

![Storybook Contract Testing for Enterprise Component Libraries: How to Catch UI Breakage Before Product Teams Do](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260511-storybook-contract-testing-for-enterprise-component-libraries--cover?_a=BAVMn6ID0)

### Storybook Contract Testing for Enterprise Component Libraries: How to Catch UI Breakage Before Product Teams Do

May 11, 2026

](/blog/20260511-storybook-contract-testing-for-enterprise-component-libraries)

[

![Why Design Systems Fail Without Governance](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260401-why-design-systems-fail-without-governance--cover?_a=BAVMn6ID0)

### Why Design Systems Fail Without Governance

Apr 2, 2026

](/blog/20260401-why-design-systems-fail-without-governance)

[

![How to Govern Component Sprawl Before It Breaks Your Design System](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20240611-how-to-govern-component-sprawl-before-it-breaks-your-design-system--cover?_a=BAVMn6ID0)

### How to Govern Component Sprawl Before It Breaks Your Design System

Jun 11, 2024

](/blog/20240611-how-to-govern-component-sprawl-before-it-breaks-your-design-system)

[

![Design Token Governance for Multi-Brand Platforms: How to Scale Consistency Without Freezing Teams](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20240220-design-token-governance-for-multi-brand-platforms--cover?_a=BAVMn6ID0)

### Design Token Governance for Multi-Brand Platforms: How to Scale Consistency Without Freezing Teams

Feb 20, 2024

](/blog/20240220-design-token-governance-for-multi-brand-platforms)

## Explore Design System Governance and Frontend Architecture

This article is about making design systems observable so teams can spot forks, overrides, and exception-heavy usage before they create long-term debt. The most relevant next step is support for governing the component system itself and the frontend architecture that consumes it. These services help teams define reusable UI patterns, align implementation across products, and turn telemetry into concrete modernization work.

[

### Design System Architecture

Structured foundations for scalable UI design system architecture

Learn More

](/services/design-system-architecture)[

### Component Libraries

Frontend component library development for scalable UI platforms

Learn More

](/services/component-libraries)[

### Frontend Engineering

Next.js frontend architecture for scalable digital platforms

Learn More

](/services/frontend)[

### Storybook Development

Build scalable component libraries and design systems

Learn More

](/services/storybook)[

### React Frontend Architecture

Scalable React frontend architecture for enterprise teams

Learn More

](/services/react-frontend-architecture)[

### WordPress Platform Strategy

WordPress platform strategy consulting: architecture principles, governance, and roadmap definition

Learn More

](/services/wordpress-platform-strategy)

## Explore Design System Governance in Practice

These case studies show how design systems hold up once they are used across real platforms, teams, and release cycles. They are especially relevant for understanding component reuse, variant control, and the governance needed to spot drift before it becomes expensive frontend debt.

\[01\]

### [ArvestaHeadless Corporate Marketing Platform (Gatsby + Contentful) with Storybook Components](/projects/arvesta "Arvesta")

[![Project: Arvesta](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-arvesta--challenge--01)](/projects/arvesta "Arvesta")

[Learn More](/projects/arvesta "Learn More: Arvesta")

Industry: Agriculture / Food / Corporate & Marketing

Business Need:

Arvesta required a modern, scalable headless CMS for enterprise corporate marketing—supporting rapid updates, structured content operations, and consistent UI delivery across multiple teams and repositories.

Challenges & Solution:

*   Implemented a component-driven delivery workflow using Storybook variants as the single source of UI truth. - Defined scalable content models and editorial patterns in Contentful for marketing and corporate teams. - Delivered rapid front-end engineering support to reduce load on the in-house team and accelerate releases. - Integrated ElasticSearch Cloud for fast, dynamic content discovery and filtering. - Improved reuse and consistency through a shared UI library aligned with the System UI theme specification.

Outcome:

The platform enabled faster delivery of marketing updates, improved UI consistency across pages, and strengthened editorial operations through structured content models and reusable components.

\[02\]

### [Bayer Radiología LATAMSecure Healthcare Drupal Collaboration Platform](/projects/bayer-radiologia-latam "Bayer Radiología LATAM")

[![Project: Bayer Radiología LATAM](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-bayer--challenge--01)](/projects/bayer-radiologia-latam "Bayer Radiología LATAM")

[Learn More](/projects/bayer-radiologia-latam "Learn More: Bayer Radiología LATAM")

Industry: Healthcare / Medical Imaging

Business Need:

An advanced healthcare digital platform for LATAM was required to facilitate collaboration among radiology HCPs, distribute company knowledge, refine treatment methods, and streamline workflows. The solution needed secure medical website role-based access restrictions based on user role (HCP / non-HCP) and geographic region.

Challenges & Solution:

*   Multi-level filtering for precise content discovery. - Role-based access control to support different professional needs. - Personalized HCP offices for tailored user experiences. - A structured approach to managing diverse stakeholder expectations.

Outcome:

The platform enhanced collaboration, streamlined workflows, and empowered radiology professionals with advanced tools to gain insights and optimize patient care.

“Oleksiy (PathToProject) and I worked together on a Digital Transformation project for Bayer LATAM Radiología. Oly was the Drupal developer, and I was the business lead. His professionalism, technical expertise, and ability to deliver functional improvements were some of the key attributes he brought to the project. I also want to highlight his collaboration and flexibility—throughout the entire journey, Oleksiy exceeded my expectations. It’s great when you can partner with vendors you trust, and who go the extra mile. ”

Axel Gleizerman CopelloBuilding in the MedTech Space | Antler

“Oleksiy (PathToProject) is a great professional with solid experience in Drupal. He is reliable, hard-working, and responsive. He dealt with high organizational complexity seamlessly. He was also very positive and made teamwork easy. It was a pleasure working with him. ”

Oriol BesAI & Innovation (Discovery, Strategy, Deployment, Scouting) for Business Leaders

\[03\]

### [United Nations Convention to Combat Desertification (UNCCD)United Nations website migration to a unified Drupal DXP](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[![Project: United Nations Convention to Combat Desertification (UNCCD)](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-unccd--challenge--01)](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[Learn More](/projects/unccd-united-nations-convention-to-combat-desertification "Learn More: United Nations Convention to Combat Desertification (UNCCD)")

Industry: International Organization / Environmental Policy

Business Need:

UNCCD operated four separate websites (two WordPress, two Drupal), leading to inconsistencies in design, content management, and user experience. A unified, scalable solution was needed to support a large-scale CMS migration project and improve efficiency and usability.

Challenges & Solution:

*   Migrating all sites into a single, structured Drupal-based platform (government website Drupal DXP approach). - Implementing Storybook for a design system and consistency, reducing content development costs by 30–40%. - Managing input from 27 stakeholders while maintaining backend stability. - Integrating behavioral tracking, A/B testing, and optimizing performance for strong Google Lighthouse scores. - Converting Adobe InDesign assets into a fully functional web experience.

Outcome:

The modernization effort resulted in a cohesive, user-friendly, and scalable website, improving content management efficiency and long-term digital sustainability.

“It was my pleasure working with Oleksiy (PathToProject) on a new Drupal website. He is a true full-stack developer—the ideal mix of DevOps expertise, deep front-end knowledge, and the structured thinking of a senior back-end developer. He is well-organized and never lets anything slip. Oleksiy understands what needs to be done before being asked and can manage a project independently with minimal involvement from clients, product managers, or business analysts. One of the best consultants I’ve worked with so far. ”

Andrei MelisTechnical Lead at Eau de Web

\[04\]

### [JYSKGlobal Retail DXP & CDP Transformation](/projects/jysk-global-retail-dxp-cdp-transformation "JYSK")

[![Project: JYSK](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-jysk--challenge--01)](/projects/jysk-global-retail-dxp-cdp-transformation "JYSK")

[Learn More](/projects/jysk-global-retail-dxp-cdp-transformation "Learn More: JYSK")

Industry: Retail / E-Commerce

Business Need:

JYSK required a robust retail Digital Experience Platform (DXP) integrated with a Customer Data Platform (CDP) to enable data-driven design decisions, enhance user engagement, and streamline content updates across more than 25 local markets.

Challenges & Solution:

*   Streamlined workflows for faster creative updates. - CDP integration for a retail platform to enable deeper customer insights. - Data-driven design optimizations to boost engagement and conversions. - Consistent UI across Drupal and React micro apps to support fast delivery at scale.

Outcome:

The modernized platform empowered JYSK’s marketing and content teams with real-time insights and modern workflows, leading to stronger engagement, higher conversions, and a scalable global platform.

“Oleksiy (PathToProject) worked with me on a specific project over a period of three months. He took full ownership of the project and successfully led it to completion with minimal initial information. His technical skills are unquestionably top-tier, and working with him was a pleasure. I would gladly collaborate with Oleksiy again at any opportunity. ”

Nikolaj Stockholm NielsenStrategic Hands-On CTO | E-Commerce Growth

![Oleksiy (Oly) Kalinichenko](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_200,h_200,g_center,f_avif,q_auto:good/v1/contant--oly)

### Oleksiy (Oly) Kalinichenko

#### CTO at PathToProject

[](https://www.linkedin.com/in/oleksiy-kalinichenko/ "LinkedIn: Oleksiy (Oly) Kalinichenko")

### Do you want to start a project?

Send