Back
Back

Allianz Product Design

Unifying a Giant

Allianz doesn't ship one product — it ships hundreds, one per market, each built by a local team on its own components and its own idea of what a button is. I worked on the interaction model for a shared design language meant to let sixty markets build one coherent experience without erasing what makes each of them local.

Role
Product Design
Timeline
Internship project
Team
Design systems squad
Focus
Consistency, Governance, Adoption

Context

Sixty markets, sixty front doors.

Allianz doesn’t ship one product. It ships hundreds — a motor-claims flow in Germany, a life portal in Italy, a health app across Southeast Asia — each built by a local team, on its own timeline, from its own components. To a customer holding policies in two countries, it doesn’t read as one company. To the people building it, every screen starts from a blank page a team three markets over has already drawn.

So the brief was never “make a new website.” It was to give a company the size of a small country one way to build — a shared design language a team in São Paulo and a team in Milan could both reach for without a meeting.

Approach

Unifying a giant isn’t a redesign. It’s a set of agreements.

You can’t redraw sixty products. You can only change what every future screen is built from — and to do that you have to win three arguments at once, none of them really about pixels.

Make the shared thing the fast thing

A system only unifies if reaching for it beats rolling your own. Every component shipped with its code, its usage rules and its accessibility already solved — so the shared path was also the lazy path. Teams took it because it saved them the week, not because a mandate told them to.

Let each market keep its accent

One system, not one skin. Tokens carried the brand — spacing, type, the Allianz blue — while leaving each market room to set its own density and locale. Unification that flattened local nuance would have been rejected on arrival. The goal was one grammar, many sentences.

Govern it like a product

A system that ships once and freezes is dead in a quarter. An owning team, a versioned release train, and a request path any market could file against kept the library earning its place — instead of quietly decaying into the thing everyone builds around.

Each of those is a habit, not a feature — and habits are what a design system actually has to change. The components were the easy half.

Solution

One grammar, sixty voices.

The interaction model treated every pattern as a contract between the system and the market: the system guarantees the behaviour and the accessibility; the market supplies the content and the accent. A stepper behaves like a stepper everywhere, but what it steps through — currencies, date formats, the length of a legal disclaimer — stays local. That split is what let a single library survive contact with sixty very different teams.

Result

A shared floor to build up from.

The measure of unification isn’t a screenshot — it’s how much of the next product a team doesn’t have to invent. Early adopting markets started shipping flows assembled almost entirely from shared parts, which turned design review from re-litigating buttons into a conversation about the actual product. The honest scope: durable adoption across every market is a multi-year governance story, not something an internship closes. What this set was the floor — and a way of working that makes the floor rise on its own.

Built with Agentation and Claude Code using Astro

Kampen, Oslo