Scaling Netcore's Design System

Building a shared design language across complex B2B products.

7 min read
Company
Netcore Cloud
Scope
Design system and product design
Role
Product Designer, system lead
Products
CEE, CPaaS and PX

Overview

Netcore Cloud served more than 6,500 brands across 40 countries through three major product suites. Each suite had evolved independently, so familiar actions, components, and visual cues often behaved differently from one product to another.

I helped lead Infinity Design System 2.0, creating a shared language that improved consistency while giving designers more time to solve the product problem in front of them.

The challenge

One company, several product languages

Product designers worked closely with their own product managers and engineering teams. That helped individual teams move quickly, but the earlier component library was incomplete and inconsistent. Designers often created local components inside project files to unblock delivery.

Over time, those local decisions became a fragmented experience for customers and a slower workflow for the design team. We needed a system that could unify the products without limiting the teams building them.

What success looked like

Three goals guided the work

  1. 01
    Establish a shared language

    Create consistent patterns across CEE, CPaaS, and PX.

  2. 02
    Reduce repetitive work

    Give designers reliable components they could use without rebuilding the basics.

  3. 03
    Improve collaboration

    Help design, product, and engineering discuss decisions using the same vocabulary.

01 · Understand

Start with how the team actually worked

I began by speaking with designers and developers about the points where the existing system slowed them down. The recurring issue was not a lack of components. It was a lack of dependable components that reflected real product scenarios.

Reviews also included product managers, Customer Success Managers, and Pre-Sales Specialists. Their proximity to customers helped us identify where visually acceptable patterns were still difficult to recognize or use.

02 · Define

Build foundations before components

The blueprint started with typography, color, spacing, and interaction states. These foundations created the constraints needed for hundreds of later component decisions to feel related rather than merely similar.

Typography, color, and spacing foundations.

03 · Refine

Design for recognition, not decoration

Text fields were a small but revealing example. The old line treatment made interactive boundaries and states harder to recognize. Boxed fields gave each input a clear hit area and made active, hover, disabled, and error states easier to understand.

How the text field evolved from a line treatment to a clearer boxed pattern.

04 · Scale

Turn the library into a living system

Infinity DS 2.0 grew into more than 200 components, with guidelines and states documented for the teams using them. Component properties allowed designers to move between common states directly in Figma instead of detaching or recreating elements.

A selection from more than 200 components in the system.
Buttons, fields, cards, navigation, uploads, tooltips, and more.
Component properties made common states available from one control.

Outcome

A faster, more consistent design workflow

The system was adopted across projects and gave teams a dependable starting point. Work that previously took hours could often be completed in minutes, leaving designers more time for exploration and product-specific decisions.

200+documented components
3product suites aligned
Hours to minutesfor common design tasks

Reflection

A system earns its value through use

The strongest learning was that a design system cannot be created in isolation. Adoption depends on understanding the real constraints of the designers, developers, and product teams expected to use it.

A useful system does not define every solution. It gives teams the shared foundations needed to create better solutions together.