Skip to content
Dark mode shipped · system in active development

Shipping app-wide dark mode at GetirFinans

Role
Product Design, Design Systems
Timeline
November 2025 — Present
Team
Partnered with the core development team and iOS/Android engineers
Platforms
iOS and Android, with a documentation site

A standalone GetirFinans app needed dark mode, but its inherited color foundation described appearance rather than purpose. I owned the product-side system work: defining semantic roles, documenting their use, and working with the core development team to make the migration practical for the release.

GetirFinans account screens in light and dark mode, shown side by side.
Shipped product capture: the same account and credit-card surfaces in light and dark mode.

Delivery

Dark mode had to work across the app

The work supported the standalone app release. The implementation window was two months, completed with the core development team ahead of that release. The result was an app-wide light and dark experience, rather than a set of isolated screen treatments.

I separate that delivery window from the longer system work. The migration is the shipped scope; adoption and further system layers remain active work.

The consequential decision

Name intent, not a color

The previous foundation contained color values with visual names. That was fast for a single light mode, but it made every dark-mode choice a local exception. We moved the decision into semantic roles such as surface, content, border, and action: a role keeps its meaning while its light and dark values change.

This was more work than supplying dark equivalents for each existing color, but it reduced the need to reinterpret a color every time a surface changed. It also made the foundation usable for the components that followed.

Evidence and handoff

Make the system usable by other people

The token naming convention page on the GetirFinans design-system documentation site, showing category, concept, and role guidance.
A real documentation page used to explain the naming convention and its component examples.

The documentation site and implementation guidance made the semantic model inspectable during handoff. I used them in working sessions with design and engineering so token references could be reviewed in context, not treated as a private Figma cleanup.

The interactive bottom-sheet example below is an illustration of the semantic approach. It demonstrates the behavior of the reconstructed example, not production code or a token export.

Standalone App
rating sheet · every color a semantic token
09:41
5G100%

Transfer İşlemi Başarılı

₺2.500,00 Ulaş Alyeşil hesabına gönderildi.

GetirFinans'ı seviyor musun?

Dürüst görüşün bizi daha iyi yapar.

What remains

A foundation, not a finish line

Color was the urgent layer because it was required for the release and visible in every product surface. Dimensional and component layers need the same proof in real product work before they become system rules.

The main lesson was collaborative: the system became viable when the naming, documentation, and implementation path were considered together. Treating them as one delivery made it possible to change the foundation while keeping the release moving.