TUI / Enterprise design system

Independent products. One reusable language.

A reusable component system supporting TUI’s global rebrand across independently developed internal applications.

Inspect the framework
APP 01 Operations
APP 02 Reporting
APP 03 Administration
SHARED FOUNDATION TUI Next Tokens / components / patterns / implementation
Responsive Documented Reusable
Client
TUI
Context
Global rebrand across internal applications
Role
Senior Product Designer, Design Systems Designer & Front-end Developer
Delivery
Component library, documentation and front-end framework

Delivered framework evidence

Reusable parts made visible in one working environment.

The framework brought interface components, navigation, charts and product patterns into a shared reference that teams could inspect and apply.

TUI Next framework shown across two desktop screens with reusable controls, navigation and data visualisation patterns.
FIG 01 TUI Next framework evidence showing reusable controls, navigation and chart patterns.

System problem

A global identity met a fragmented product estate.

Multiple internal applications needed to adopt TUI Next, but their interfaces had evolved independently. Recurring controls and behaviours were being solved repeatedly, producing duplicated effort and inconsistent experiences.

The design-system work had to preserve the new brand language while remaining practical for teams assembling different products, data views and workflows.

PRODUCT A PRODUCT B PRODUCT C
RECURRING NEEDS Audit / organise / standardise
ONE SYSTEM Shared decisions, reusable implementation

Component architecture

Built from small decisions into complete products.

Atomic Design provided a useful organising model, but the system remained grounded in recurring product needs, documented behaviour and implementation constraints.

  1. 01 Foundations Brand, colour, typography and spacing rules
  2. 02 Components Controls and repeated interaction behaviours
  3. 03 Patterns Navigation, forms, tables and data views
  4. 04 Products Different applications assembled from shared parts

Decision register

Three decisions kept reuse practical.

The system needed enough control to create consistency and enough flexibility to support genuinely different applications.

  1. 01
    Organise around recurring product needs. The system was not modelled around one application’s page structure.

    Patterns were derived from repeated interface requirements, allowing the framework to support different product contexts.

  2. 02
    Make documentation part of delivery. A component without behaviour and usage guidance was incomplete.

    Documentation connected visual examples to intent, interaction and implementation expectations.

  3. 03
    Separate consistency from uniformity. Shared foundations did not require every product to become the same page.

    Teams could compose different workflows while retaining recognisable brand and interaction decisions.

Delivery trace

A framework designed to travel between teams.

Evidence boundary

Reusable UI patterns and a working implementation foundation were delivered.

The supplied evidence supports real-application reuse. It does not provide quantified adoption, delivery-speed, productivity or maintainability gains, so none are claimed.

Next case study

TUI 360° / Aircraft Experience

Examine TUI 360°

Need one system to support different products?

Tell me where inconsistency is creating friction and what your teams need to deliver repeatedly.

Start a conversation

I usually respond within two working days.