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

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

Framework in practice

Shared parts became a working product framework.

Reusable controls, navigation and data-visualisation patterns brought the component architecture into one inspectable environment that teams could apply across different internal products.

TUI Next framework shown across desktop screens with reusable controls, navigation and data-visualisation patterns.
FIG 01 Working framework demonstrating reusable controls, navigation and chart patterns assembled from the shared system.

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.

Implementation perspective

Reuse had to remain practical for developers.

The framework was not only a visual system. Its value depended on collaboration with the developers who had to implement and extend it.

“Michael has always collaborated on his work with developers to ensure it fits the requirements and allows for easy implementation.”

Viktor Tkachuk
Read full testimonial

Michael is the UX Designer CIO at The Content Hub and is responsible for user experience designs across the majority of the projects; often working on multiple projects at once, never failing to deliver amazing solutions. Michael has always collaborated on his work with developers to ensure it fits the requirements and allows for easy implementation. His work has always impressed our customers, who often asked why solutions from other parts of TUI don’t have as good a look and feel and how he managed to achieve it. Even though Michael’s job was to create designs, it didn’t stop him from exploring other areas of development, and he has done an amazing job learning JavaScript and jQuery to deliver complex solutions. In the last few days of working for TUI he has even started learning Angular. During the development cycle, Michael gave a lot of constructive criticism and analytical feedback on the solutions, which has helped The Content Hub to deliver better products. Working with Michael has always been a pleasure as he is always happy to assist with any issues or questions, often finding new, better ways.

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.