Design systems

Overview

Across my years at Slideworx and mTab I built, grew and eventually consolidated the platform's design systems. It started with designers working on features in isolation, became component libraries for separate applications, then one unified system, and finally the decision to drop all of it and move to Microsoft Fluent. As Head of Design I set the design system strategy and was involved at every stage of it.

Challenge

When I took over the team there were no design principles to speak of. Everything got designed against whatever the current requirement was, with no shared standards to fall back on. Engineering was deeply siloed as well, so the same problem often got solved two or three different ways, sometimes inside the same module. What users got was a patchwork of inconsistent patterns, behaviours and visual treatments.

Discover and Analyze (now Reports) were treated as separate applications by both Engineering and the business, and their needs really were different. Discover had to be clean and easy on the eye for browsing. Analyze had to be dense and tool-heavy, with nested menus and popups to support serious analytical work. On top of that, a growing library of advanced data visualisations began introducing its own solutions, tailor-made for each new case. My job was to bring consistency across every module while letting each one keep enough character to stand on its own.

My role

I built each system for its own context. Discover leaned loosely on Google's flat design principles, favouring clarity and visual appeal for a broad, non-technical audience. 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 aligned with Engineering's goal of unifying the technology used across the mTab platform.

Then company restructuring, plus the plain reality of maintaining a custom system, forced a rethink. After researching it jointly with Engineering we dropped our own system entirely and moved to Microsoft Fluent. That gave us a mature, well-documented base with a huge component library, and freed both teams to build product instead of maintaining design infrastructure.

Outcome

Moving to Fluent sped up design and development noticeably. Every new feature and module is built on it now, with mTab-specific tweaks layered on top. Bits of the older systems are still in the product, but they get retired as modules are updated. Going from no shared principles, through three competing systems, to one adopted standard finally gave the team a common language. Letting go of work we had put years into, because something better already existed, is still one of the best calls we made.