Enterprise · Design System
A comprehensive design system for a global commodities trading company running its internal product portfolio on Mendix, a low-code enterprise platform. The system covers foundations, base components and application-level patterns — built to work consistently across five breakpoints and in both light and dark themes.
Role
UX/UI Designer
Timeline
1 yr. 6 mos.
Outcome
Adopted in 6 products · design time per project roughly halved
Industry
Enterprise / B2B / Low-code
Year
2024–2025
View
Design System →Figma →
Problem
Every new Mendix product was built from scratch, with its own buttons, type and colours. Internal tools looked like a dozen companies had made them.
What I did
Designed and built Meridian, the company's first design system, largely on my own: tokens, base components and 20+ enterprise patterns.
Result
In production across 4 Mendix products plus 2 other projects. Design time per project down from ~2 months to 3–4 weeks.
Key tradeoff
Extended Mendix's visual language instead of replacing it: less freedom to redesign, much faster adoption by developers.
Leftward pointing arrow icon.
Back to all case studies
Jump to key decisions
Meridian enterprise design system cover showing the system identity and v1.0 documentation.
Project overview
As the company's design team scaled and more products came onto Mendix, each designer was building components from scratch. Every project had its own buttons, its own typography, its own colour choices. From the outside, it looked like a dozen different companies had built the tools.

I led the design and construction of the company's first proper Mendix design system, working on it alone through most of 2025. The scope spans foundations (a three-layer token architecture, responsive grids across five breakpoints, light and dark themes), base components (inputs, buttons, tables, dropdowns) and 20+ application-level patterns that enterprise products need but rarely get designed properly.
Challenge
Questions to the design team were often "why does this look different from the other tool?" rather than "does this solve my problem?". The cost was compounding — every new project inherited the fragmentation of the previous ones.

The situation before the system existed was expensive in three ways: for clients and internal departments, inconsistency across products created constant friction — users moved between tools daily and had to relearn the same patterns every time. For designers, every project started at zero, adding weeks to every new project. For developers, translating inconsistent designs meant more back-and-forth, more edge cases, more tickets.
Overview of the Meridian design system showing foundations, tokens, components and documentation in Figma.
Solution
The system extends the Mendix visual language rather than replacing it — keeping adoption fast for developers already familiar with the platform, while giving every new product a consistent visual and interaction baseline. Responsive behaviour is defined through five breakpoints, from small mobile to wide desktop, with grids adapting from 4 to 12 columns and a controlled maximum content width on larger screens.

A layered system built foundations-first: tokens are organised into Reference, Semantic and Dimension layers, covering colour, typography, spacing, radius, elevation, motion, density, status, priority and data visualisation. These foundations feed base components such as inputs, buttons, tables and dropdowns, which in turn support application-level patterns including command palette, user profile card, app switcher, status transitions and approval history.
Meridian colour system showing reference and semantic colour tokens with Light and Dark modes.
Design tokens are structured across Reference, Semantic and Dimension layers, creating a clear separation between raw values, contextual meaning and reusable dimensions. The system covers colour, typography, spacing, radius, elevation, motion, density and application states, with Light and Dark modes built into the colour architecture.
Meridian typography system using Manrope for headings and Inter for body text across a shared 20-style scale.
Typography uses a single shared scale of 20 styles rather than separate device-specific scales. Manrope is used for headings and Inter for body content, creating a consistent hierarchy that works across responsive layouts without multiplying styles by breakpoint.
Application-level components from the Meridian design system, including reusable patterns for enterprise products.
20+ application-level patterns pre-built for enterprise contexts: command palette, user profile card, app switcher, approval history, recent items menu, status transitions. The pieces enterprise products need but rarely get designed properly.
Key Features
Foundations first
A single source of truth for downstream decisions — from typography and colour semantics to spacing, radius, elevation and responsive grid behaviour.
Built to grow
The system is built to scale with the platform — new patterns get added through structured discussion, keeping quality high as coverage grows.
Documentation built-in
Every component ships with a Getting Started reference so designers and developers can adopt the system without needing me in the loop. The system scales because it explains itself.
Frictionless adoption
New team members can find what they need, when they need it — reducing time-to-first-contribution and preventing the design system from becoming a bottleneck.
Getting Started documentation explaining how designers and developers can adopt and use the Meridian design system.
Key Decisions
Extending Mendix rather than replacing it
The system refines the existing Mendix visual language instead of overwriting it. Developers already familiar with the platform adopt the new components without friction, and teams mid-project can adopt incrementally rather than migrating everything at once.
Responsive foundations from day one
Enterprise products are primarily desktop-driven, but the system also needed to support smaller screens without creating separate component libraries. I defined five responsive breakpoints with grid behaviour adapted to each context: 4 columns for small mobile and mobile, 8 for tablet, and 12 for laptop and desktop, with a constrained content width on wide screens. Keeping responsive behaviour at the layout level avoids duplicating foundational tokens for every device.
Shared vs. project-specific components
Not every component created for a product belongs in the shared library. When a new pattern appears, I evaluate whether it solves a recurring need across products or only a project-specific requirement. This keeps Meridian useful without turning the library into a collection of one-off components and gives the system a clearer path for long-term governance.
Naming and versioning the system
The design system is called Meridian and follows semantic versioning. Naming created a shared vocabulary — teams can refer to “Meridian” rather than “the Figma library” — while versioning makes it clear that the system is a maintained product rather than a one-off deliverable. Meridian has now reached v1.0 and is documented as a stable foundation for ongoing product development.
Outcome
The system is currently in production across four internal Mendix products, plus two additional projects outside Mendix (including OpenText integration and the company's internal learning platform). Impact reported by my manager after several months of adoption: design time per project dropped from ~2 months to 3–4 weeks (excluding client-driven changes and post-testing iterations); development time dropped from 3–4 months to 1–2 months per project. Three products have shipped since the start of 2025, with continuous improvements based on client feedback and new requirements. What travels forward: the biggest lesson from building this alone is that a design system's real value isn't in its component library — it's in the conversations it removes. When every designer starts from the same foundations, arguments about "should this be blue or teal" stop happening, and everyone gets more time on the actual problems.

By treating consistency as a shared decision instead of a policing exercise, the system became something teams pull from because it helps them ship — not because they're required to.
Enterprise product interface using Meridian design system foundations and reusable components.Data-heavy enterprise application built with Meridian components, typography and layout patterns.Enterprise interface showing consistent use of Meridian components and interaction patterns.Enterprise product interface showing Meridian design system components, layout and visual patterns applied in a real product.
⚠
DISCLAIMER

This case study is shared for portfolio purposes under confidentiality. The company name, product names, team member names and internal department references have been changed to protect client identity. Screenshots and materials are illustrative of the design work performed; underlying business data has been replaced with placeholder content. Happy to discuss the full project scope in interviews.