Turning regulatory complexity into interfaces advisors actually trust.

I joined this marketplace-for-insurance-brokers project mid-stream, at a point where the client's confidence in the engagement — and in the product's direction — had eroded. There was no shared definition of what "good" looked like, and no consensus on what the platform was actually for.

I rebuilt that alignment through close, consistent stakeholder work and a single, agreed product goal — not a redesign pitch, but a slow re-establishing of trust. I'm developing a strategic foundation document benchmarked against reference marketplaces (Amazon, Udemy, Otto, Atlassian Store), alongside wireframes for the platform's core areas and guidance on structure, navigation, and commercial maturity of the interface. I also lead the project's UI designer.

Part of rebuilding that credibility was proving the platform could hold together as a real product, not just a set of screens. I built a full colour system on top of PrimeNG's palette, tuned to VHV's brand and checked against accessibility contrast requirements, and collapsed a typography system that had sprawled into dozens of overlapping, deeply nested styles — separate scales for Slogan, Headline, Body, and component-specific variants like Filter-Kachel, each with its own desktop/tablet/mobile version — into a single seven-step scale that resizes consistently across breakpoints. That kind of consolidation doesn't show up in a wireframe, but it's what actually lets several teams build across marketplace, shop, and content pages without drifting apart.

The result so far: a measurably stronger client relationship, and the decision to continue working with adesso — the outcome a trust-recovery story is actually measured by.

The health insurance line had to price and gate coverage across an enormous combinatorial space: every possible family constellation — spouses, children, other dependents, legal representatives — crossed with every individual's own health disclosures, each combination feeding into decisions about who can be insured, who pays more, and who's excluded outright. My job wasn't just making individual screens usable; it was making thousands of possible household-and-health combinations behave predictably and consistently, without ever contradicting the underwriting rules sitting underneath them.

Concept, wireframes, and UI for the entire health line were mine, end-to-end — including design-system components the platform's shared design-system team built directly off patterns I'd created for this line first. My wireframes became the working language between me and the Fachbereich (the insurance experts who own the underwriting rules): a way to centralise expertise that otherwise only lived in people's heads into something developers, the other four lines' designers, and the business could all react to and agree on.

A few of the harder problems underneath the "one coherent product" goal: refund logic that had to hold across both Voll-KV and Beihilfe-KV tariff paths; validation across family constellations where several things can be wrong about a household at once (not just one bad field); an advisor-facing tool for assigning legal representative, premium-payer, and policyholder roles across a household that doesn't map one person to one role; and a health-disclosure flow where individual answers feed a preliminary underwriting check in real time. Every screen carries my own annotation notes, written directly for developers, the Fachbereich, and the other line teams — writing tickets and QA'ing implementation myself, not handing off a file and walking away.

SUH (home insurance) had originally been slated as the line to pioneer the platform's rollout. After seeing how far along and how well the health line's designs tested with users, Generali asked my team to lead the launch instead — health went live first among all five lines.

Brillux doesn't sell paint to homeowners — it sells to the specialist trade companies (Fachbetriebe) that homeowners hire. So the business logic behind this brief was indirect: help private customers find and book a specialist faster, and the specialists booked through it buy more Brillux paint to do the job. The tool never mentions a product once.

Brillux already had a very basic version of this — a short, dated question flow that hadn't kept pace with what people expect today. The real problem underneath it: homeowners don't know which specialist to trust, and the good ones are often already booked out. I owned the concept and wireframes end-to-end: an 8-step configurator (area → building component → service type → size) that produces a project card with a rough price estimate before routing the request to a matching specialist — including logic for saving several part-projects, and a conditional contact form for when the job site isn't the customer's home address. The price-estimate logic (each decision step carrying its own min/max value range) was Brillux's own idea; I designed the flow it lives in.

I built the final UI alongside a graphic designer I'm currently mentoring into UX/UI — this project became his first real production work, not a training exercise. It's still in development: stakeholders have responded well to the direction, but there's no client-facing feedback yet, so I'm not going to claim an outcome this early.