30 tickets left20 Networking Passesuntil sold out
Design Stage

How We Safely Landed Our Design System: Lessons from Wolt’s First 9 Months in Orbit

September 18, 2025 1:40 PM
Long Lecture
🇬🇧 English
Wisła

About

Building a design system rarely starts from scratch. More often, you join mid-flight—surrounded by existing patterns, tools, and habits. In this talk, I’ll share how we spent our first nine months evolving Wolt’s design system: introducing a full token architecture, creating a scalable component library, and aligning teams—without disrupting ongoing work. You’ll learn why thinking in orbits, not timelines, helps you navigate inherited systems, and how to design for both today’s needs and the next decade of growth.

‍

Talk by

Photo of Francesco Cutolo, Leading design systems at Wolt
Francesco Cutolo
Leading design systems at Wolt

Watch the full talk

Watch this WaysConf session, then continue with related talks or explore the current programme.

Explore the 2026 agendaMore WaysConf recordings
From the recording

Talk in brief

This talk recounts the first nine months of building Wolt’s design system from the middle of an established, multi-platform product rather than from a clean component library. It presents a sequence of maneuvers: understand the current landscape, win credibility through tactical fixes while keeping a business horizon, embrace differences across platforms, avoid treating code parity as the only measure of design quality, and use automation and AI where they reduce maintenance work. The conclusion favors a focused starting point, strong collaboration, and continuous adaptation over an idealized system designed in isolation.

Key takeaways

  1. 01

    Start from the system that already exists

    An established product carries components, conventions, code, teams, and constraints; useful design-system work begins by mapping that reality.

    Watch from 4:20
  2. 02

    Pair tactical wins with a strategic horizon

    Fixing icons, tokens, and immediate friction proves value, but the team also needs a view of the business and product direction beyond those tasks.

    Watch from 9:21
  3. 03

    Cross-platform does not mean identical

    A shared system must coordinate product intent across platforms while respecting native behavior and the different needs of designers and engineers.

    Watch from 14:11
  4. 04

    Do not make parity the only goal

    Perfect equivalence between design files and code can reduce usability for designers and distract from whether the system improves product work.

    Watch from 15:01
  5. 05

    Automate maintenance without abandoning ownership

    AI and tooling can help produce documentation and bridge gaps, but teams still need clear decisions, review, and responsibility for the system.

    Watch from 20:09
Read edited transcript highlights

These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.

A mature product is not a blank canvas

Most design-system examples begin with a new palette or component library. This team began much later, inside a functioning product with accumulated decisions, multiple platforms, and active delivery. The first responsibility was therefore investigative: understand what already worked, where teams experienced friction, and which constraints could not be wished away by naming a new system.

Watch from 4:20

Short wins should point beyond themselves

Icons, tokens, and other immediate repairs can establish credibility because teams feel the benefit quickly. Yet a backlog of small fixes is not a strategy. The design-system group also needs to understand where the product and business are going, so tactical decisions form foundations for the next stage rather than becoming a collection of disconnected improvements.

Watch from 8:59

Shared intent permits platform variation

Cross-platform consistency does not require every component to behave or look identical. Each platform brings native expectations, implementation details, and different working needs. The system can preserve shared principles and product meaning while allowing appropriate variation, provided those differences are deliberate and understood rather than accidental drift.

Watch from 13:40

Synchronization is a means, not the product

Complete parity between code and design artifacts can sound like the final measure of maturity. The speaker questions that assumption. A technically synchronized library may still be awkward for designers or fail to improve delivery. The stronger test is whether the system supports confident decisions and collaboration across the people who build the product.

Watch from 15:01

Begin with one meaningful foundation

The recap encourages teams to understand their position, address tactical pain, work across platforms, use automation thoughtfully, and retain sight of the larger product. A design system does not need to launch as a complete universe. One well-chosen foundation—typography, a core control, or another shared element—can create the first credible orbit for continued work.

Watch from 25:40
Explore WaysConf 2026

View the agenda

Get tickets