Dark mode case study

VIGo is the design system powering Neuron — an internal platform used across major Czech insurance companies. I spent most of my time at AIS contributing to it, across component building, documentation, and interface work. The task I owned most completely was also the most technically demanding: building dark mode across three brand themes, touching nothing but the semantic token layer.

1. The Constraint

One rule, three themes

VIGo already had three light themes built on an industry-standard three-tier token foundation:

• Core tokens - the raw values. Base colors, spacing, typography. Never used directly in components.
• Semantic tokens - the meaning layer. Mapping core values to roles like surface/primary or text/inverse.
• Component tokens - the application layer. Consuming semantic tokens to style specific components.

The goal was to produce three matching dark counterparts while keeping the core and component layers completely untouched. Every change had to live in semantics and brand colors only. That constraint sounds limiting - in practice it forced a very disciplined token architecture that makes a system scalable. If the semantic layer was sloppy, dark mode would expose it immediately - which proved itself correct from the early stages as my work ended up serving as a stress test for the token structure the core team had built.

2. The Problem

Dark mode isn't just inversion

The naive approach is flipping light and dark values. It breaks almost immediately:

• Contrast ratios shift in unexpected ways
• Elevation and shadow logic that reads clearly in light feels flat or heavy in dark
• Surfaces that work at one end of the spectrum often fail at the other

It was clear that manically playing around with tokens and seeing what looks pretty wasn’t going to do it. I had to understand what the semantic layer was actually communicating - not what color something was, but what role it was playing - and whether that role held up when the context flipped.

3. Iteration

What broke, and what I learned from it

The first versions weren't right. Assumptions about how surface and text pairings would behave in dark context turned out to be wrong once tested against real components. The process looked roughly like this:

1. Apply semantic changes system-wide
2. Stress-test against existing components
3. Identify where the logic failed
4. Revise and repeat

Each failure pointed to a semantic token carrying an assumption baked in from the light context - or doing double duty it shouldn't have been doing.

4. The Outcome

A single switch, three themes, zero exceptions

The final implementation switches between light and dark across all three brand themes by changing only the semantic and brand color layers. No component needed special-casing, no one-off overrides, no duplicated token trees.

The most telling detail: the dark theme logic is identical across all three brand themes. The only thing that differs between them is the brand colors themselves - which is exactly how a well-structured design system should behave. One unified dark mode approach, three distinct brand expressions on top of it. The constraint that initially seemed restrictive turned out to be the right one." Gives it a proper landing

Interface design case study

Alongside design system work, I was assigned to interface design for a specific domain within Neuron - working directly with analysts and business stakeholders to translate their requirements into production-ready designs. The job was three things at once: understanding what the business needed, designing within the constraints of the design system, and staying in sync with the design system team on what was available and what was coming.

1. The setup

Three conversations, one interface

Every domain assignment started with the analyst and business stakeholder. The analyst understood the data and workflows - the business person understood what the insurance company needed from the platform. My job was to sit between both of them and turn that into a design that could actually be built, on time, using what the design system had available.

That last part mattered more than it sounds. VIGo was actively in development throughout my time at AIS - not every component existed yet. Designing with a system that's still being built meant that you had to be constantly aware of what you can use today, what's coming next sprint, and what you simply can't do yet.

2. The friction

When the business wants everything custom

The most recurring challenge was scope. Business stakeholders naturally wanted layouts tailored to their exact mental model of the domain - custom arrangements, one-off components, specific interactions that didn't exist in VIGo. Some of those requests were genuinely reasonable but a lot of them weren't feasible within the development timeline.

Pushing back on a business stakeholder as a junior designer isn't the most comfortable position to be in. I learned to consult with my design team colleagues and lead first, and then communicate the limitation directly - not as a personal decision, but as a team one. The constraint wasn't me being difficult, it was the project scope, the design system rules, and the development capacity. Framing it that way made the conversations easier and kept the relationship intact.

3. Maximizing the design system

Using what exists, feeding back what's missing

Working within VIGo wasn't just about constraint - it was about fluency. The instruction was to maximize the design system in every design decision. That meant understanding the component library deeply enough to know when an existing component solved a problem the business hadn't even articulated clearly yet.

It also meant staying in close contact with the design system team - understanding what was being built, communicating the needs of my domain, and flagging components or features that business stakeholders were asking for repeatedly. That feedback loop went both ways. My domain work informed the system's roadmap, and the system's progress directly shaped what I could deliver.

4. What it taught me

Beyond the component level

Interface design work sharpened how I think about users in a way that design system work alone doesn't. Each domain had its own user workflows - insurance agents, analysts, administrators - and understanding those workflows was the foundation of every layout decision. A component placed in the wrong context, even a perfectly built one, still fails the user.

It also taught me that communicating design decisions is as much a part of the job as making them. Holding a business request, explaining why, and proposing an alternative that still meets the underlying need - that's a skill that Figma couldn’t help with.