Design systems

From fragmentation to a unified design language

Overview

Over my tenure at Slideworx/mTab, I led the creation, evolution, and eventual consolidation of the platform's design systems. What started as independent designers working on features transformed into component libraries for distinct applications and evolved into a unified system — and ultimately led to a strategic decision to adopt Microsoft Fluent as our foundation.

As Head of Design, I drove the design system strategy and oversaw every stage of this journey.

Challenge

When I started leading the team, there were no established design principles. Everything was designed based on current requirements, with no shared standards to fall back on. This was compounded by deep silos within engineering — the same solutions were often implemented differently, sometimes even within the same module. The result was a patchwork experience where users encountered inconsistent patterns, behaviours, and visual treatments across the platform.

The platform's modules Discover and Analyze were treated as distinct applications, both engineering and business and side. Each had fundamentally different UX requirements — Discover needed a clean, visually appealing interface for browsing, while Analyze required a dense, tool-heavy environment with multi-level context menus and popups to support complex analytical workflows.

On top of that, a growing library of advanced data visualisations started introducing it’s own set of solutions tailor made for every new case.

My role was to introduce consistency and unify the designs across every module of the application — while keeping each module distinctive enough to function as its own product.

Approach

I built each system to serve its specific context. The Discover design system was based loosely on Google's flat design principles — prioritising clarity and visual appeal for a broad, non-technical user base.

The Analyze design system was more condensed and interaction-heavy, designed for power users who needed quick access to deep functionality.

The data visualisation component library sat alongside both, introducing consistency in how charts, graphs, and interactive visual elements were rendered across all mTab products.

As the platform matured, I led the effort to merge all three into a single unified mTab design system. The goal was to reduce duplication, create shared patterns where possible, and give designers and developers one source of truth.

This was aligning with engineering goals to unify technology used across mTab platform.

However, company-wide restructuring and the realities of maintaining a custom system forced a pragmatic reassessment. After combined research with the engineering team, we made the decision to abandon our custom system entirely and adopt Microsoft Fluent. This gave us a mature, well-documented foundation with an extensive component library — freeing both teams to focus on building product features rather than maintaining design infrastructure.

Outcome

The move to Fluent accelerated design and development significantly. All new features and modules are now built on Fluent with mTab-specific modifications layered on top. Some legacy elements from the older systems still exist in the product, but these are being phased out progressively as modules are updated. The journey from no shared principles, through three fragmented systems, to one adopted standard gave the team a clear, shared language — and the pragmatic decision to let go of our custom work in favour of a better solution remains one of the most impactful calls we made.

Szpakowskidesign

Design systems

From fragmentation to a unified design language

Overview

Over my tenure at Slideworx/mTab, I led the creation, evolution, and eventual consolidation of the platform's design systems. What started as independent designers working on features transformed into component libraries for distinct applications and evolved into a unified system — and ultimately led to a strategic decision to adopt Microsoft Fluent as our foundation.

As Head of Design, I drove the design system strategy and oversaw every stage of this journey.

Challenge

When I started leading the team, there were no established design principles. Everything was designed based on current requirements, with no shared standards to fall back on. This was compounded by deep silos within engineering — the same solutions were often implemented differently, sometimes even within the same module. The result was a patchwork experience where users encountered inconsistent patterns, behaviours, and visual treatments across the platform.

The platform's modules Discover and Analyze were treated as distinct applications, both engineering and business and side. Each had fundamentally different UX requirements — Discover needed a clean, visually appealing interface for browsing, while Analyze required a dense, tool-heavy environment with multi-level context menus and popups to support complex analytical workflows.

On top of that, a growing library of advanced data visualisations started introducing it’s own set of solutions tailor made for every new case.

My role was to introduce consistency and unify the designs across every module of the application — while keeping each module distinctive enough to function as its own product.

Approach

I built each system to serve its specific context. The Discover design system was based loosely on Google's flat design principles — prioritising clarity and visual appeal for a broad, non-technical user base.

The Analyze design system was more condensed and interaction-heavy, designed for power users who needed quick access to deep functionality.

The data visualisation component library sat alongside both, introducing consistency in how charts, graphs, and interactive visual elements were rendered across all mTab products.

As the platform matured, I led the effort to merge all three into a single unified mTab design system. The goal was to reduce duplication, create shared patterns where possible, and give designers and developers one source of truth.

This was aligning with engineering goals to unify technology used across mTab platform.

However, company-wide restructuring and the realities of maintaining a custom system forced a pragmatic reassessment. After combined research with the engineering team, we made the decision to abandon our custom system entirely and adopt Microsoft Fluent. This gave us a mature, well-documented foundation with an extensive component library — freeing both teams to focus on building product features rather than maintaining design infrastructure.

Outcome

The move to Fluent accelerated design and development significantly. All new features and modules are now built on Fluent with mTab-specific modifications layered on top. Some legacy elements from the older systems still exist in the product, but these are being phased out progressively as modules are updated. The journey from no shared principles, through three fragmented systems, to one adopted standard gave the team a clear, shared language — and the pragmatic decision to let go of our custom work in favour of a better solution remains one of the most impactful calls we made.

Szpakowskidesign

Design systems

From fragmentation to a unified design language

Overview

Over my tenure at Slideworx/mTab, I led the creation, evolution, and eventual consolidation of the platform's design systems. What started as independent designers working on features transformed into component libraries for distinct applications and evolved into a unified system — and ultimately led to a strategic decision to adopt Microsoft Fluent as our foundation.

As Head of Design, I drove the design system strategy and oversaw every stage of this journey.

Challenge

When I started leading the team, there were no established design principles. Everything was designed based on current requirements, with no shared standards to fall back on. This was compounded by deep silos within engineering — the same solutions were often implemented differently, sometimes even within the same module. The result was a patchwork experience where users encountered inconsistent patterns, behaviours, and visual treatments across the platform.

The platform's modules Discover and Analyze were treated as distinct applications, both engineering and business and side. Each had fundamentally different UX requirements — Discover needed a clean, visually appealing interface for browsing, while Analyze required a dense, tool-heavy environment with multi-level context menus and popups to support complex analytical workflows.

On top of that, a growing library of advanced data visualisations started introducing it’s own set of solutions tailor made for every new case.

My role was to introduce consistency and unify the designs across every module of the application — while keeping each module distinctive enough to function as its own product.

Approach

I built each system to serve its specific context. The Discover design system was based loosely on Google's flat design principles — prioritising clarity and visual appeal for a broad, non-technical user base.

The Analyze design system was more condensed and interaction-heavy, designed for power users who needed quick access to deep functionality.

The data visualisation component library sat alongside both, introducing consistency in how charts, graphs, and interactive visual elements were rendered across all mTab products.

As the platform matured, I led the effort to merge all three into a single unified mTab design system. The goal was to reduce duplication, create shared patterns where possible, and give designers and developers one source of truth.

This was aligning with engineering goals to unify technology used across mTab platform.

However, company-wide restructuring and the realities of maintaining a custom system forced a pragmatic reassessment. After combined research with the engineering team, we made the decision to abandon our custom system entirely and adopt Microsoft Fluent. This gave us a mature, well-documented foundation with an extensive component library — freeing both teams to focus on building product features rather than maintaining design infrastructure.

Outcome

The move to Fluent accelerated design and development significantly. All new features and modules are now built on Fluent with mTab-specific modifications layered on top. Some legacy elements from the older systems still exist in the product, but these are being phased out progressively as modules are updated. The journey from no shared principles, through three fragmented systems, to one adopted standard gave the team a clear, shared language — and the pragmatic decision to let go of our custom work in favour of a better solution remains one of the most impactful calls we made.