Taming the Dark Mode
Turning a simple product requirement into a visual language for complex, AI-powered Pro Apps
Client
sipgate
Timeframe
2018 - 2025
Role
UI, UX, Art Direction
Context
From 2018 to 2025, I worked on sipgate’s App team, first as a Senior Product Designer and later as Head of Design.
When I joined Sipgate, our team was responsible for Apps and AI. The brief for the company's Pro Apps was simple: They should have a dark UI.
I designed the first UI from the ground up, working closely with the CEO and Product Leads. Over time, other designers joined the work, the products became more complex and the individual decisions evolved into a broader design system.
Challenge
How do you make a dark interface work when the product itself keeps getting more complex?
A communication tool has to deal with a lot of information: calls, contacts, statuses, actions, notifications and AI-generated content.
A dark interface can easily become too flat, making hierarchy difficult to understand, or too noisy, with every state competing for attention.
The challenge wasn't simply to make the interface dark.
Starting with an experiment
How do you create depth when everything starts with black?
My first challenge was surprisingly simple: There wasn't enough contrast.
I started looking at other dark interfaces and experimenting with different ways to create hierarchy between surfaces. I didn't start with a sophisticated elevation system. I simply placed white layers on top of the black background and played with their opacity.
Different values were tested until one approach consistently worked: 10% brighter per layer.
I limited the interface to a maximum of three surface levels. This gave us enough distinction to create depth without turning the UI into a collection of slightly different greys.
What started as a simple experiment became one of the basic rules of the visual language:
THE EXPERIMENT
Finding depth in the dark
I started with a simple tool:
just draw a layer and play around with opacity.
TRIAL & ERROR
I tested different values to see what created enough separation without making the UI feel noisy.
10%
20%
30%
40%
50%
THE RESULT
10% steps provided the right balance.
THE RULE
We limited it to three levels.
Simple, Predictable, Scalable.
HIERARCHY WITHOUT THE NOISE
How do you create hierarchy when everything is dark?
Shadows don't work particularly well on dark surfaces, so we used subtle borders to separate elements and create definition without adding visual noise.
I also used contrast deliberately: white was reserved for primary information, headlines and static controls, while secondary and supporting content used progressively softer shades of grey.
The result was a hierarchy built from contrast, borders and spacing rather than heavy shadows or excessive color.
For typography, I relied on the default fonts and text colors of each operating system. This kept the interface familiar and helped me maintain consistent readability across platforms.
Top-level elements such as controls, buttons and search fields use a subtle glass effect with gradient borders, creating a clear visual separation from the content beneath.
COLOR WITHOUT CHAOS
If everything is dark, how do you decide what deserves attention?
Telephony comes with a surprising number of semantic states: missed calls, forwarded calls, answered calls, voicemail, calls on hold, errors, success states and many more.
One of the problems I encountered was that the same color could easily end up meaning different things. Red, for example, could indicate a missed call, an error or a destructive action.
Instead of simply adding more colors, I treated color as an information channel and kept it deliberately restrained.
Color was supported by context, icons, labels and interaction, rather than carrying the entire meaning on its own.
For default avatar states, we used subtle colors and glyphs to keep the interface visually calm.
Static information uses subtle backgrounds and bold glyphs, while temporary information requiring action uses stronger, more prominent colors.
When accessibility became part of the system
What happens when dark mode isn't enough?
Unfortunately, accessibility wasn't part of the initial brief. In the early versions, we focused primarily on establishing the visual language and making the product work. As the product matured, that changed.
Customers started asking for a light mode, and a color-blind co-worker also made us aware of limitations in the dark-only approach.
Later, a dedicated accessibility team extended the product with improvements including Light Mode, a high contrast theme and keyboard shortcuts. This changed the way we thought about the system.
The goal was no longer simply to make a dark interface work.
The system needed to be flexible enough to work for different people.
An example of an overlay before and after our accessibility improvements.
Make it (less) pop
How much AI does a UI really need?
AI was a big part of our apps from the beginning, helping with tasks such as call summaries, action items, CRM notes and call routing - before, during and after a call.
Initially, I made AI highly visible because it was cool: sparkles ✨, animated gradients and visual cues everywhere. But with AI appearing throughout the product, the dark interface quickly risked becoming a theme park at night: glowing everywhere, with everything competing for attention.
At the same time, business calls contain important information. Users were hesitant to blindly trust or forward AI-generated summaries and wanted to know when AI had processed their information.
So we shifted from “Look, it's AI!” to “AI did something for you.”
I used subtle icons, gradients and borders to identify AI-generated content, while keeping the process itself in the background. An animated thought bubble showed when AI was working.
The goal wasn't to hide AI, but to make its involvement clear without letting it take over the interface.
An example how we managed AI generated content
RESUMEE
What I learned
The more complex the product became, the less visual noise it could afford. Dark UI taught me that good hierarchy isn't about making important things louder.
Accessibility should be part of the brief, not the retrofit.
We initially treated accessibility as something we could improve later. That made the eventual changes much harder than they needed to be, especially when we introduced Light Mode.
Looking back, I would build accessibility requirements into the visual system from day one. Making an established UI accessible later is far more expensive than designing with accessibility in mind from the start.
Designing a business tool means designing for people who may spend hours looking at it. For example: German workplace regulations explicitly require appropriate contrast between the screen and its surroundings and require text and graphics to be clear and sufficiently legible. Screen brightness and contrast must also be adjustable to the working environment.
Dark mode is harder design constraint
Dark interfaces don't give you the same tools as light interfaces. Shadows become almost useless, subtle contrast differences become more important, colors behave differently and creating hierarchy without visual noise takes much more effort.
That doesn't mean every product should start in Light Mode. It means the underlying system should be designed to support both from the beginning.
Dark mode taught me that the real challenge isn't making an interface dark. It's making sure it still works when everything around it gets more complex.
