Structuring Design in a Highly Constrained Technical Context
Context
Structuring design in a constrained environment
I joined Tixeo as a product designer working on B2B secure video conferencing interfaces. It quickly became clear that the real challenge was not designing new features, but structuring design in an environment where no coherent system existed and where technical constraints (security, data sovereignty, legacy stack) imposed significant limitations.
The challenge
Creating consistency without an existing design system
The interface had accumulated visual and behavioral inconsistencies across iterations. No clear hierarchy existed between base components and complex patterns, making it impossible to know which elements to reuse or how to combine them. Each designer worked in isolation, each developer implemented their own patterns. This fragmentation slowed down design and multiplied back-and-forth.
Technical constraints (legacy architecture, specific stack, security limitations) made it impossible to adopt standard solutions. The challenge was to create a hierarchical token architecture and a clear component structure while remaining pragmatic. The goal was not immediate perfection, but laying solid foundations that would enable adoption and iteration.
My role
UX/UI Designer - Design System
I initiated and structured the foundations of the Tixeo design system in close collaboration with the development team. My role combined auditing the existing state, defining the system structure, and creating the first documented components.
01 Audit and pattern identification Full inventory of components used in the interface, identification of inconsistencies, and detection of reusable patterns. Analysis of technical constraints to understand what was technically feasible.
02 Token structure definition Creation of a token architecture (colors, typography, spacing) adapted to technical constraints and aligned with implementation possibilities. Dev collaboration to validate feasibility.
03 Component creation and documentation Design of the first reusable components (buttons, inputs, modals, states) with variants, states, and use cases. Usage guideline documentation with do's & don'ts.
04 Integration into the Scrum workflow Integration of the design system into 3-week sprints. Daily collaboration with developers to validate implementation, iterate on components, and ensure progressive adoption.
05 Maintenance and evolution Continuous updates to the system based on product needs, dev feedback, and newly identified technical constraints.
Design decisions
Build progressively, adopt quickly
Starting from the existing, not from scratch
Rather than rebuilding everything from scratch, the audit of the existing state made it possible to identify patterns already in use and formalize them. This approach facilitated adoption: developers recognized components they were already using, simply better structured and documented.
Identified inconsistencies (button variations, arbitrary spacing, non-systematic colors) were progressively consolidated. Each sprint included cleanup and migration tasks toward the new components.
Building with technical constraints
The token architecture was designed in direct collaboration with developers to ensure it integrated naturally into the existing stack. Technical limitations guided design decisions rather than blocking them.
Each component was designed with its variants and states (default, hover, active, disabled, error) to cover real use cases. Documentation included do's & don'ts to prevent misuse and enable designer and developer autonomy.
Close collaboration within the Scrum framework allowed rapid iteration: design a component, technical validation, implementation, testing, adjustment. This short loop ensured the design system remained aligned with the reality of the code.
Impact
A system that structures and accelerates
- Strengthened alignment between design and development teams through a shared language established by tokens and shared documentation
- Reduced design time for recurring features by enabling designers to reuse components instead of redrawing everything
- Improved consistency across the interface through progressive consolidation of visual and behavioral inconsistencies
- Streamlined dev/design collaboration through systematic technical validation and short iteration loops within sprints
- Scalable foundation for future evolution with a token architecture and component structure allowing new patterns to be added without a full overhaul
Reflections
Key takeaways
A design system is organizational infrastructure
To me, a design system is not a component library. It's infrastructure that allows teams to move faster together while maintaining consistency. My goal was for the system to reduce design debt rather than create it, accelerate delivery without sacrificing consistency, and create a shared language between design and development.
A design system must be pragmatic
An imperfect but adopted design system is better than a perfect one that nobody uses. Adoption and iteration matter more than initial perfection. Starting small, with the most-used components, and building progressively is more effective than trying to define everything at once.
Technical constraints shape the system
Working in a constrained environment (security, legacy stack) forces you to co-build with developers from the start. This isn't a limitation — it's an opportunity to create a system that integrates naturally into technical reality. The design system cannot exist in a silo.
Documentation is as important as the design
An undocumented component is a component that won't be used correctly. Documentation (guidelines, do's & don'ts, use cases) is what enables adoption and team autonomy. It's as much a deliverable as the components themselves.