palisis
An ongoing UX/UI, design system, and DesignOps project across the Palisis product ecosystem. I am redesigning the platform after identifying that the existing design system was positioned incorrectly for the products and their development needs. The new structure connects shared foundations to reusable components and then to product-specific patterns for five digital teams.
Client
Palisis
Year
2025-2026
Project type
Product Design, Design Systems & DesignOps
Credits
Philipp Fueglistaller, Josef Birchler
Product Design
Design System
DesignOps
Platform Redesign
Problem
Palisis had an existing design system, but it was in the wrong place for the products and the way the teams developed them. Shared components did not always map to real product needs, patterns were difficult to scale across different contexts, and each team risked solving similar problems in isolation.
Role & Scope
I am currently redesigning the entire Palisis platform and building the design system alongside the product work. My role spans product UX/UI, foundations, component architecture, product patterns, DesignOps, and collaboration across MPoS, CPoS, Back end, The Boxoffice, and the Webshop. I am also applying lessons from the Caraer design-system project to make this system more useful in practice.
Outcome
The work is ongoing, but the new direction establishes a clearer three-level structure: Foundation, Components, and each product’s Patterns. The goal is a storybook of the entire Design System which eventually will be available for the larger public.
Process
01
Discovery & Problem
We started by looking beyond the component library and into the products themselves. The main issue was that the design system lived in the wrong place: it was not close enough to the product logic or the development reality of the teams using it.
02
Research & Principles
I studied the existing platform, the five team contexts, and the lessons from building the Caraer system. A key principle became clear: the system should be a connected structure from foundation to component to product pattern, rather than a flat collection of reusable parts.
03
Ideation & Creation
I designed a new system architecture with three levels: Foundation, Components, and each product’s Patterns. Foundations create consistency, components create reuse, and product patterns explain how the system behaves inside a specific workflow.
04
Cross-team Product Work
The system is being shaped with five digital teams: MPoS, CPoS, Back end, The Boxoffice, and the Webshop. Working across these contexts helps reveal which patterns should be shared, which should be specialized, and where the platform needs stronger product decisions.
05
Ongoing Redesign & Refinement
This project is still in progress. I am redesigning the wider platform while refining the system through real product work. The current focus includes creating a new sales channel, a website proposition, or a product-list experience, using the system to test whether the new structure truly supports development and delivery.
Design Decision
Flat Library vs Product-connected System
The first major decision was how to place the design system in relation to the products. A broad library can look complete while still being disconnected from the workflows and teams that need it.
Option A
Maintain one broad shared component library
Option B
Connect foundations to components and product patterns
Chose: A three-level product-connected system
I chose to structure the system as Foundation → Components → Each product’s Patterns. This creates shared principles without pretending that MPoS, CPoS, Back end, The Boxoffice, and the Webshop all have the same needs.
Learnings
◉
A design system can be technically reusable and still be strategically misplaced. Its position in the product organization matters as much as the quality of its components.
◉
Caraer taught me the value of building the foundation first and working closely with development. Palisis is giving me the opportunity to apply those lessons at a larger, more distributed platform scale.
◉
Five teams do not need five separate systems, but they do need five clear contexts. Product patterns are the layer that keeps shared components useful instead of generic.
◉
An ongoing system should be tested through real product decisions. The new sales channel, website proposition, and product-list work are not separate from the system; they are the proof that the system can support future work.
What I'd do differently
◉
I would establish stronger recurring rituals between the five teams earlier, so decisions about reuse, exceptions, and product-specific patterns could be documented continuously.
◉
I would define success measures for the system from the start, including reduced duplication, faster development handoff, clearer ownership, and improved consistency across product journeys.
Next project
