Omni VisualHub — Design System Portal

How I built a centralised hub for all Omni design systems — with research-driven information architecture used by product teams across all markets.

// problem statement

As the Omni ecosystem grew to include multiple design systems — Omni.web, Omni.gskpro, Omni.med, Omni.email, Omni.data, and Omni.foundations — teams struggled to find the right components, guidelines, and documentation. Each system had its own scattered documentation, and new team members had no clear entry point to understand what was available, how to use it, or who to ask for help.

// objectives

• Create a single portal that brings all Omni design systems together in one place
• Define a consistent page structure so every design system homepage answers the same core questions
• Validate the information architecture through research — not assumptions

// system architecture

Before designing the portal, I mapped how the design systems relate to each other. GSK Brand feeds into Omni, which sits on top of the Mendix/Continuum platform. Omni.foundations serves as the shared base layer, distributing primitives — colour, typography, spacing, elevation — to all domain-specific systems: Omni.web, Omni.gskpro, Omni.med, Omni.email, and Omni.data. This architecture ensured the portal reflected the real dependency chain rather than an arbitrary grouping.

// research — card sorting and tree testing

To get the information architecture right, I ran two rounds of structured research with designers, developers, and product managers across markets:

• Card sorting — participants grouped documentation topics into categories that made sense to them. This revealed how teams naturally thought about content and surfaced groupings that our initial structure had missed.
• Tree testing — participants were given tasks ("find the colour tokens for medical websites") and navigated a proposed site structure. This tested whether the hierarchy was intuitive before any visual design work began.

The research showed that teams wanted to answer five questions on every design system homepage — and that these questions should always appear in the same order, regardless of which system they were looking at.

// homepage structure

Based on the research findings, every design system homepage in the portal follows the same consistent structure:

• What it is for — a clear description of the system's purpose and target audience
• How to use — getting started guides, setup instructions, and onboarding steps
• Where to use — which products, platforms, and contexts the system applies to
• What's possible and not — scope boundaries, supported patterns, and known limitations
• Who to ask — ownership, contact points, and contribution channels

This framework meant that a designer joining from any market could land on any Omni sub-system and immediately orient themselves using the same mental model.

// unbranded and branded templates

The portal needed to support two types of websites built with the system: unbranded (product-focused, neutral visual identity) and branded (campaign sites carrying the full GSK or disease-awareness branding). I designed reference implementations for both, showing how the same component library adapts to each context — from wireframe-level structure to fully rendered pages.

Unbranded website template — wireframe structure alongside the rendered GSK product page

Branded website template — disease awareness campaign built with Omni components

// the portal

The final VisualHub brings everything together. Product teams across all markets use it as their starting point for any design system work — browsing available systems, exploring component libraries, and accessing documentation that follows the consistent five-section structure validated through research.

// outcomes