Design system, którego zespoły naprawdę używają
Jak z systemu na papierze zrobić narzędzie, którego używa się codziennie. Tokeny, governance, adopcja.
Zobacz pełne case study
Design systems · Warszawa
Porządkuję design systemy w firmach produktowych z wieloma zespołami. Tokeny, governance, biblioteka, która zgadza się z kodem.
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.
Problem nie jest brak komponentów – jest nim brak 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, tylko 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
Dwa główne wejścia, zależnie od tego, gdzie jesteś. Każdy kończy się czymś, czego zespół może użyć następnego dnia.
-
01 / 02 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
-
02 / 02 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
Większość współprac zaczyna się od jednego z tych dwóch.
Inne formy współpracy
-
01 / 03 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
-
02 / 03 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)
-
03 / 03 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
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
Design Systems Warsaw
Meetup o design systemach w skali enterprise, który sam prowadzę. Warszawa, co 6–8 tygodni, dla osób, które na co dzień walczą z tym samym, o czym jest ta strona.
05
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ą
Design System inaczej
Mini-kurs dla projektantów. 8 lekcji o tym, co naprawdę widzisz, kiedy patrzysz na swój design system. Plik Figma jako wspólny bohater. Bez kodu, bez teorii.
designsystemthinking.plKnowForm
Narzędzie do audytu widoczności marek w systemach AI. 13 modeli językowych, 14 metryk, 128 promptów.
Knowform.pl06
O mnie
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
07
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.
- linkedin.com/in/radoslawlatarski
- GitHub
- github.com/velmighty