RL
01–DLA KOGO
Design systems · Warszawa

Porządkuję design systemy w firmach produktowych z wieloma zespołami. Tokeny, governance, biblioteka, która zgadza się z kodem.

Lokalizacja
Warszawa · Polska
Kontakt
radoslaw.latarski@gmail.com

Design system to nie biblioteka komponentów. To kontrakt między designem a kodem – albo ułatwia firmie pracę, albo ją po cichu sabotuje. Trzecia opcja nie istnieje.

01

Dla kogo

Pracuję z firmami, które mają design system na papierze, ale nie mają procesu, który by go utrzymywał.

Pracujemy razem, jeśli:

  • Masz design system w jakiejś formie i widzisz, że zaczyna się rozjeżdżać.
  • Pracujesz w firmie 50–500 osób, z kilkoma zespołami produktowymi naraz.
  • Patrzysz na swój system i widzisz zbiór komponentów – ale czujesz, że to nie wszystko.
  • Tokeny i komponenty co chwilę rozsynchronizowują się między Figmą a kodem.

Nie dla Ciebie, jeśli:

  • Szukasz pojedynczych ekranów albo szybkiego UI, bez systemu pod spodem.
  • Twój DS jest dojrzały – masz governance, proces, nikt go nie obchodzi bokiem.
  • Twoja firma nie ma developerów. Design system bez devów to dokumentacja, nie system.
02

Co się psuje, kiedy nikt nie pilnuje systemu

Design system rzadko psuje się od razu. Psuje się powoli, decyzja po decyzji, której nikt nie podjął.

Najpierw pojawia się trzeci odcień niebieskiego, bo komuś było szybciej zahardkodować wartość niż znaleźć token. Potem dwa komponenty robią to samo, tylko inaczej, bo dwa zespoły nie wiedziały o sobie. Po roku biblioteka w Figmie i kod żyją osobno. Każdy designer wie, że „prawda jest gdzieś indziej", ale nikt nie wie gdzie.

To nie problem braku komponentów. To problem braku decyzji i jednego źródła prawdy.

Najczęściej słyszę to samo: „mamy design system, ale ludzie i tak go obchodzą". To nie wina ludzi. To znak, że system nie ma właściciela ani procesu – i każdy idzie na skróty, bo skrót jest tańszy niż walka z systemem.

Tu zaczyna się moja praca. Nie od dorysowania kolejnego komponentu, tylko od nazwania, gdzie naprawdę leży problem.

03

Jak mogę pomóc

Pięć sposobów wejścia, zależnie od tego, gdzie jesteś. Każdy kończy się czymś, czego zespół może użyć następnego dnia.

  • 01 / 05 Jednorazowo

    Audyt Design Systemu

    Kiedy nie wiesz, co naprawdę masz w systemie i od czego zacząć porządki.

    Dostajesz
    • raport: co działa, co naprawić, co wyrzucić
    • priorytety napraw od najpilniejszej
    • plan na 90 dni, gotowy do wdrożenia z zespołem
    3–4 tygodnie · od 25 000 PLN Szczegóły audytu →
  • 02 / 05 Pilotaż

    Pilotaż współpracy

    Kiedy chcesz sprawdzić współpracę, zanim wejdziesz w coś dłuższego.

    Dostajesz
    • jeden konkretny fragment DS doprowadzony do końca
    • namacalny rezultat, nie prezentację
    • jasną podstawę do decyzji o stałej współpracy
    2–4 tygodnie · od 15 000 PLN Szczegóły pilotażu →
  • 03 / 05 Stała współpraca

    Wsparcie zespołu DS

    Kiedy masz design system, ale nie masz osoby od jego utrzymania.

    Dostajesz
    • code review komponentów i tokenów
    • governance (kto i jak decyduje o zmianach w systemie) oraz kierunek jego rozwoju
    • mentoring zespołu w bieżącej pracy
    Część etatu · od 12 000 PLN/mc Szczegóły wsparcia →
  • 04 / 05 Drugie zdanie

    Niezależna ocena DS

    Kiedy chcesz drugie spojrzenie na pracę głównego dostawcy.

    Dostajesz
    • niezależną ocenę architektury i tokenów
    • weryfikację kierunku, w którym idzie projekt
    • drugie spojrzenie obok głównego dostawcy (Accenture, EPAM, Deloitte)
    2–4 tygodnie · od 4 000 PLN/dzień Szczegóły oceny →
  • 05 / 05 Praktycznie

    Warsztat dla zespołu

    Kiedy zespół ma wspólnie przerobić jeden temat i podjąć decyzje.

    Dostajesz
    • jeden temat przerobiony do końca: tokeny, governance albo struktura biblioteki
    • pracę z zespołem produktowym i designerskim naraz
    • konkretne decyzje na koniec, nie slajdy
    Pół dnia lub cały dzień · od 8 000 PLN Szczegóły warsztatu →

Pilotaż to wycinek audytu doprowadzony do wdrożenia – mniejsza skala, namacalny efekt. Audyt to pełna diagnoza całego systemu. Większość współprac zaczyna się od jednego z tych dwóch.

Ceny netto, orientacyjnie – finalna wycena zależy od zakresu. Najprościej zacząć od krótkiej rozmowy, odpowiadam w 1–2 dni.

Więcej o moim podejściu: governance design systemu, design tokens, case study.

04

Skąd to wiem?

Najdłuższy rozdział mojej pracy to prawie cztery lata przy jednym design systemie – w jednej z największych instytucji finansowych w Polsce.

System obsługiwał trzy platformy naraz: web w Angularze, iOS w SwiftUI, Android w XML. Ponad 50 komponentów i wiele zespołów produktowych korzystających z niego równolegle. Pełna architektura tokenów – od prymitywnych po semantyczne. Dokumentacja w Storybooku, governance, szkolenia wewnętrzne.

Najtrudniejsze nie było zaprojektowanie komponentów. Najtrudniejsze było sprawić, żeby system był naprawdę używany, a nie tylko udokumentowany. Żeby zespoły z różnymi terminami i priorytetami sięgały po wspólne tokeny zamiast po własne skróty. To wymaga procesu, nie kolejnego pliku w Figmie.

W regulowanym środowisku nie ma miejsca na „jakoś to będzie". Dostępność, spójność na trzech platformach, kontrola zmian – wszystko policzalne i powtarzalne. Tę dyscyplinę przynoszę do każdego mniejszego projektu, gdzie stawka jest niższa, ale problem ten sam.

Poza pracą klientową

05

O mnie

Radosław Latarski, portret

Projektuję produkty cyfrowe od dwunastu lat. Pierwsze design systemy budowałem dla polskich firm produktowych i SaaS, później dla międzynarodowych sieci handlowych i sektora publicznego. Potem prawie cztery lata przy systemie na trzech platformach w dużej instytucji finansowej.

Przez te lata nauczyłem się jednej rzeczy: o sile design systemu nie decyduje liczba komponentów. Decyduje to, czy ludzie chcą z niego korzystać, kiedy mają termin na karku. Reszta to konsekwencja.

Dziś pracuję z firmami, które są dokładnie w tym miejscu – mają system, mają zespoły, brakuje im tylko kogoś, kto pilnuje, żeby to wszystko trzymało się kupy. Prowadzę też Design Systems Warsaw – meetup o design systemach w skali enterprise.

  • Tokeny
  • Governance
  • Angular
  • SwiftUI
  • Figma
  • Storybook
06

Porozmawiajmy

Jeśli coś na tej stronie brzmi znajomo i masz u siebie podobny problem, najlepszym pierwszym krokiem jest krótka rozmowa. Bez zobowiązań, bez prezentacji handlowej.

Napisz dwa zdania: jaki masz system i gdzie zaczyna się rozjeżdżać. To wystarczy na start. Powiem szczerze, czy to coś, w czym mogę pomóc, i od czego ja bym zaczął. Czasem wystarczy jedna rozmowa, żeby zobaczyć problem inaczej – i nie zawsze potrzebujesz do tego całego projektu. Odpowiadam w 1–2 dni.

E-mail
radoslaw.latarski@gmail.com
Kalendarz
Zarezerwuj rozmowę 
LinkedIn
linkedin.com/in/radoslawlatarski 
GitHub
github.com/velmighty