iyzico Design System – Scaling Consistency Across B2B Products

Project Context

iyzico operates multiple B2B products across web and mobile platforms, each serving merchants with different needs, roles, and usage patterns.

As the product ecosystem grew, UI inconsistencies, duplicated components, and implementation gaps began to slow down both design and development processes.

This project focused on evolving iyzico's design system into a scalable, single source of truth that could support multiple products while maintaining speed, consistency, and quality.

Problem

Before the redesign, the design system faced several challenges:

Inconsistent UI patterns across products

Duplicated or slightly altered components solving the same problems

Gaps between design decisions and frontend implementation

Difficulty scaling new features without creating UI debt

As a result:

Designers spent time reinventing patterns

Developers implemented similar components differently

Product teams struggled to maintain consistency at scale

Goals

The primary goals of the design system initiative were to:

Establish a clear and scalable system architecture

Reduce UI inconsistencies across products

Improve collaboration between design and frontend teams

Enable faster product development without sacrificing quality

Create a system that supports both current needs and future growth

Design System Strategy

Instead of building a single, monolithic library, the system was intentionally structured into two layers:

**Core System**

Foundations (colors, typography, spacing, grid, tokens)

Shared atomic components

Global interaction and accessibility rules

**Product Libraries**

Product-specific components and patterns

Variations driven by real product needs

Extensions built on top of the Core system

**Why this approach?** A single library cannot scale across different products without becoming bloated. Separating Core and Product-specific libraries keeps the system flexible, maintainable, and future-proof.

Research & Insights

**Inputs**

Audit of existing UI components across products

Analysis of frontend implementation differences

Feedback from designers and developers

Review of real product constraints and edge cases

**Key insights**

Most inconsistencies came from unclear ownership rather than bad intent

Components often existed without defined usage rules

Small visual differences caused large perception problems in B2B trust-based products

Key Design Decisions

**1. Token-Driven Foundations**

Colors, spacing, typography, and radius values were redefined as design tokens.

**Why?** Tokens create a shared language between design and code, reducing interpretation errors and enabling scalable theming.

**2. Clear Component Ownership**

Each component was defined with:

Purpose

Usage rules

Do / Don't guidelines

**Why?** Components without context are reused incorrectly and lose their value as system building blocks.

**3. Product-Driven Extensions**

When product-specific needs emerged, they were handled through product libraries, not Core overrides.

**Why?** This prevents Core pollution and keeps the system adaptable to future products.

Workflow & Collaboration

The design system was built as a living system, not a static UI kit.

Designers and developers collaborated closely on component definitions

Design decisions were validated against real product scenarios

Frontend feedback directly shaped component behavior and structure

This approach reduced handoff friction and increased trust between teams.

Outcomes & Impact

As the design system matured:

UI consistency across products significantly improved

Design and development speed increased

Component reuse became intentional rather than accidental

Product teams gained confidence to scale without visual fragmentation

The system evolved into a strategic product enabler, not just a visual guideline.

Learnings & Next Steps

**Learnings**

A design system is an organizational product, not a design artifact

Clear structure matters more than component count

Scalability comes from constraints, not flexibility alone

**Next Steps**

Expanding token usage across platforms

Strengthening documentation around component decision logic

Continuous audits to prevent UI drift as products evolve

My Role

In this initiative, I was responsible for:

Auditing and restructuring the design system architecture

Defining Core vs Product library strategy

Designing and documenting reusable components

Collaborating closely with frontend and product teams

Final Note

This case reflects my belief that design systems are not about consistency for its own sake, but about enabling teams to build better products—faster, together, and with confidence.

🔒 **Confidentiality Note**

UI components and system details are intentionally not displayed due to internal product constraints.