Skip to content

SIXT / Current

Case study

Designing systems for operational product work.

Shaping back-office design systems, revenue-management tools, and AI-supported delivery workflows where reusable foundations make complex product work faster, clearer, and easier to hand over.

Mobility platform

SIXT
SIXT premium rental vehicle context
Mobility context for the customer-facing ecosystem connected to the internal product work.

Overview

At SIXT, design work had to improve both the internal tools and the way teams built them.

The work sat inside back-office applications, revenue-management workflows, reusable component systems, and AI-supported delivery processes. Improving the UX meant shaping the product surfaces and the operating model around them.

I helped establish shared foundations, applied them as the solo designer for revenue-management tooling, and then brought the same system logic into AI-assisted prototyping and design-to-code workflows.

At a glance

Scope in one pass

3

Workstreams

Design-system foundations, revenue-management redesign, and AI-supported delivery moved together as one operating model.

DS

Shared foundation

The design system supported consistency across back-office products and became part of the prototyping and handover workflow.

AI

Delivery leverage

AI tools were connected to Figma and the codebase so prototypes, rules, and engineering handover could become faster and more consistent.

Contributions

Moved from design-system foundations to solo product redesign and AI-enabled delivery practice.

Together with another designer, I helped establish the design system for back-office applications, worked with engineering to get the system implemented, and wrote the first draft of component guidelines so teams had a practical starting point.

I then applied that system as the solo designer for the revenue-management department, revamping the product experience and introducing component and UX patterns across the applications I designed for.

As AI entered the workflow, I connected the design system to my prototyping process, improved the Figma-to-Claude-to-Cursor loop, supported other designers and POs with Claude and Cursor skills and rules, and later carried that practice into PO responsibilities while prototyping directly in the codebase.

Three connected use cases

Three projects show how the work changed as the product problem changed.

The workstreams focus on different product problems. Together, they show how the design approach adapted while the underlying need for clarity stayed consistent.

Back-office foundation

Foundations

The first layer was establishing a design system for back-office applications that engineering could actually implement.

Together with another designer, I helped establish the design system for SIXT's back-office applications. The work was not just component cleanup. It meant creating a shared foundation that could support dense internal products and still stay practical for engineering teams.

I worked with engineering on implementation and wrote the first draft of the component guidelines. That documentation helped turn the system from a Figma layer into a usable product foundation: clearer rules, more consistent components, and better shared language between design and development.

Design pressure

Back-office products needed consistency without losing the flexibility required by complex internal workflows.

What it demonstrates

Ability to connect design-system thinking to implementation, documentation, and cross-functional adoption.

Design system to implementation

SIXT
SIXT back-office design-system foundation with component guidelines, interface states, tokens, and engineering handoff notes
A design-system foundation for back-office product work: component rules, interface states, tokens, implementation notes, and reusable patterns staged as one operating layer.

Implementation

Design-system decisions were shaped with engineering so the foundation could move beyond static design files.

Guidelines

The first draft of component guidelines gave teams a practical reference for usage, consistency, and product judgment.

Adoption

The system created a stronger base for multiple back-office applications rather than solving each product in isolation.

Revenue management

Redesign

As solo designer for revenue management, I revamped the product experience around clearer UX and reusable patterns.

In the revenue-management department, I worked as the solo designer across applications that depended on dense information, operational constraints, and business-critical decisions. The redesign was not a visual refresh alone. It was a restructuring of product behavior around clearer flows, better hierarchy, and a more coherent component language.

By introducing component and UX patterns across the applications I designed for, the work improved overall usability and made the experience feel less fragmented. The design system became a practical way to raise product quality across related tools, not a separate library sitting outside the work.

Design pressure

Revenue-management products carry dense data, operational logic, and high decision cost, so weak UX creates real drag.

What it demonstrates

Ability to lead product design independently across a department and translate system foundations into better day-to-day usability.

Revenue management

SIXT
SIXT revenue-management redesign direction with dense operational screens, component states, and design-system handoff details
A visual direction for the revenue-management redesign: dense operational screens, reusable interface states, component rules, and handoff details brought into one product system.

Solo ownership

I drove the design revamp across revenue-management applications as the solo designer for the department.

UX patterns

Reusable interaction patterns helped make related workflows more predictable and easier to understand.

Usability

The outcome was stronger overall UX through clearer structure, more consistent components, and less product-by-product drift.

AI delivery workflow

Acceleration

AI became more useful when it was connected to the design system, Figma, Claude, Cursor, and the actual codebase.

As AI tools entered the product workflow, I worked the design system into my AI process so prototyping could move faster without losing consistency. The important part was not using AI as a shortcut around design judgment, but giving the tools better structure: components, rules, product context, and clearer links between Figma and the codebase.

I improved the design-to-code workflow by connecting Cursor, Claude, and Figma more deliberately, then helped other designers and POs with Claude and Cursor skills and rules that made their prototyping and AI workflows more consistent. Later, after taking over PO responsibilities for the team I was working in, I continued prototyping directly in the codebase and improving the team's workflow with AI tools.

Design pressure

AI speed only helps when the output stays aligned with product rules, design-system patterns, and engineering reality.

What it demonstrates

Ability to turn design-system knowledge into faster prototyping, better handover, and stronger team operating habits.

AI workflow

SIXT
SIXT AI-supported delivery workflow connecting product context, design system, Figma workspace, AI assistant, implementation, and handoff
A structured delivery workflow connecting product context, design-system rules, Figma workspace, AI assistance, implementation, and handoff into one operating model.

Design to code

Figma, Claude, and Cursor were connected into a more reliable workflow for turning design intent into working prototypes.

Team enablement

Claude and Cursor skills and rules helped other designers and POs produce more consistent AI-assisted work.

PO practice

The work expanded into PO responsibilities, direct codebase prototyping, and improving team productivity through AI-enabled workflows.

What connected the work

The workstreams point to the same enterprise-design pattern: foundations become valuable when they change how teams design, build, and decide.

01

Systems before screens

The useful design question was not only how a screen should look, but which shared rules and patterns would let many tools improve together.

02

Consistency through context

Reusable components worked best when they were connected to actual revenue-management workflows, not treated as abstract UI inventory.

03

AI with guardrails

AI prototyping became more reliable when Claude, Cursor, and Figma were guided by design-system rules, product context, and reusable prompts.

Impact

What it proved

This chapter proves senior product-design depth: design systems, department-level UX improvement, AI-supported delivery, and operational product ownership in a business-critical mobility environment.

Impact read

What the work established

DS

Back-office system

Shared component foundations and guidelines helped back-office applications become more consistent and easier to implement.

RM

Revenue UX

A department-level redesign introduced component and UX patterns that improved usability across revenue-management applications.

AI

Workflow leverage

Design-system-aware AI workflows improved prototyping speed, engineering handover, and consistency across designers and POs.

Learnings

Enterprise products need craft at the level of systems, workflow, and delivery practice.

Foundations need adoption

A design system becomes valuable when it is implemented, documented, and used inside real product work, not only maintained as a design artifact.

Solo redesign needs system leverage

Revenue-management UX improved because reusable components and UX patterns gave complex applications a clearer shared language.

AI needs product structure

Claude and Cursor became more useful when the workflow included design-system rules, Figma context, and codebase-based prototyping instead of generic prompting.

This chapter shows mature product judgment. The work is less about showing confidential screens and more about making complex internal products clearer, more scalable, faster to prototype, and easier for teams to build consistently.

Career sequence

You are on chapter 1 of 4. Continue through the sequence for the clearest career story.

Newer chapter

Sequence boundary

Return to the work index if you want to compare the broader career arc.

Earlier chapter

Supporting chapter

Fleet Charging product bridge

Elli

Elli Fleet Charging across driver app, console context, shared components, and process.

A bridge into mobility-service complexity, focused on making driver charging journeys, fleet oversight, and reusable product foundations easier to work with.