TL;DR:

Design systemy odnoszą sukces tylko gdy łączą się z rzeczywistą wartością produktową, nie tylko konsystencją wizualną
Implementacja powinna odbywać się flow-by-flow zamiast component-by-component, z akceptacją tymczasowych niespójności
Prawdziwa współpraca między designerami a developerami jest ważniejsza niż automatyzacja i narzędzia
Design tokeny działają jak frontend infrastruktura, definiując role elementów interfejsu zamiast konkretnych wartości
Właścicielami systemu powinni być ludzie, którzy się o niego troszczą, niezależnie od działu organizacji
Technika „Indiana Jones swap” pozwala zastąpić legacy komponenty bez wpływu na doświadczenie użytkowników
Zespoły systemowe powinny zaczynać małe i stopniowo rosnąć wraz z udowadnianiem wartości

Poniższe notatki powstały na podstawie rozmowy z Bradem Frostem, autorem metodologii Atomic Design i ekspertem od design systemów. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od rozmówców.

W erze AI rola designera ulega transformacji

Brad Frost zauważa fundamentalną zmianę w branży. Dzisiaj sztuczna inteligencja może w kilka minut stworzyć przyzwoicie wyglądający interfejs. Jednak kluczowe pytanie pozostaje niezmienione: czy to jest dobre?

Nowa rola designera według Frosta:

Ocena jakości zamiast tworzenia ładnych makiet
Określanie kryteriów dobrego designu w kontekście produktu
Rozróżnianie między tym co „dobrze wygląda” a tym co „jest dobre”
Definiowanie standardów dla zespołów i AI

Frost podkreśla różnicę między powierzchowną estetyką a funkcjonalnością. W świecie, gdzie AI może wygenerować stronę internetową na polecenie, potrzeba ludzi, którzy potrafią określić kryteria dobrego designu.

Problem gotowych systemów i moment przełomu

Frost analizuje popularność gotowych rozwiązań jak Material Design czy Bootstrap. Startupy często zaczynają od takich systemów, ponieważ pozwalają szybko validować produkt. Jednak problem pojawia się w tak zwanym „nastoletnim” okresie firmy.

Checklist: Czy Twoja firma potrzebuje własnego design systemu?

Sprawdź, czy doświadczasz tych sygnałów:

Masz opinię o swojej marce i chcesz się wyróżnić
Gotowe komponenty nie spełniają Twoich potrzeb
Musisz tworzyć własne nadpisania i dostosowania
Zespół ma czas i zasoby na utrzymanie systemu
Zarządzasz więcej niż jednym produktem cyfrowym
Planowane są kolejne produkty lub ekspansja

Według Frosta punkt przełomu następuje, gdy organizacja ma już własne opinie o marce i doświadczeniu użytkownika. Wtedy gotowe rozwiązania stają się ograniczeniem zamiast pomocą.

Firma zaczyna uderzać w ściany tego, co zewnętrzne narzędzia mogą zaoferować. To sygnał do przejścia na własny system.

Gdy zły UX ma dramatyczne konsekwencje

Frost dzieli się osobistym przykładem z systemu opieki zdrowotnej. Próbował zaktualizować kartę kredytową w systemie autopłatności. Jednak interfejs był tak źle zaprojektowany, że mimo starań nie znalazł wszystkich miejsc do aktualizacji.

Informacja o płatności była ukryta w ostatniej klatce starego carousel jQuery. W rezultacie żona otrzymała powiadomienie o problemach z płatnością. W systemie opieki zdrowotnej takie błędy mogą prowadzić do bankructwa medycznego lub braku dostępu do krytycznej opieki.

Frost podkreśla wagę dobrego UX w krytycznych systemach, wskazując, że ludzie mogą popaść w bankructwo medyczne lub nie dostać operacji ratującej życie z powodu takiego wzorca interakcji.

Jak przeprowadzić remont nie zamykając sklepu

Frost używa metafory centrum handlowego do opisania wyzwań implementacji. Legacy produkty to jak stare, ale funkcjonalne centra handlowe – generują pieniądze, jednak potrzebują modernizacji.

Dlaczego podejście komponent-po-komponencie nie działa

Frost opisuje popularne, ale błędne podejście: „Widzieliśmy wiele zespołów próbujących zacząć od buttonów, potem przejść do checkboxów”.

Problem polega na ogromnej powierzchni działania nawet w małych organizacjach. To jak powolne wypełnianie wanny – długo nie widać rezultatów, brak wartości biznesowej w początkowej fazie. Powstaje też efekt Frankensteina, gdzie użytkownicy przechodzą między różnymi designami w tym samym produkcie.

Skuteczniejsze jest podejście flow-by-flow lub „sklep-po-sklepie”. To oznacza przeprojektowanie całych ścieżek użytkownika, nie pojedynczych komponentów.

Strategia „sklep po sklepie” krok po kroku

Frost proponuje systematyczne podejście do modernizacji, które można opisać w trzech krokach:

Krok 1: Wybierz jeden, konkretny obszar Zamiast myśleć o całej aplikacji, skup się na jednym, izolowanym przepływie użytkownika (np. proces logowania) lub jednej sekcji.

Krok 2: Przebuduj go w całości „Odgrodź” ten obszar i zmodernizuj go od początku do końca przy użyciu nowego design systemu.

Krok 3: Dostarcz wartość i przejdź dalej Po wdrożeniu jednej części, przejdź do kolejnej, powtarzając proces.

Technika „Indiana Jones swap”

W ramach tego podejścia Frost opisuje technikę „Indiana Jones swap”. Zespół tworzy systemową wersję istniejącej strony, która wygląda identycznie jak oryginał. Następnie wykonuje swap – zamienia starą wersję na nową.

Z perspektywy użytkownika nic się nie zmienia. Pod spodem powstaje jednak czysta, systematyczna architektura z lepszą dostępnością i wydajnością. To minimalizuje ryzyko biznesowe przy jednoczesnym testowaniu systemu na prawdziwym produkcie.

Wartość produktowa ponad konsystencją

Frost podkreśla kluczowy problem wielu organizacji. Zespoły systemowe skupiają się na konsystencji i spłacaniu długu designerskiego zamiast na wartości produktowej.

Frost wyjaśnia biznesowy kontekst design systemów: „Z perspektywy produktowej chodzi o to, żeby ludzie wchodzili do naszego sklepu i kupowali rzeczy, które utrzymują światła włączone”.

Trójkąt decyzyjny: speed, quality, budget

Frost przypomina o klasycznym dylemacie projektowym – można wybrać tylko dwa z trzech elementów. Ten framework pomaga zespołom jawnie definiować priorytety zamiast udawać, że można mieć wszystko.

Sukces wymaga połączenia wysiłków systemowych z celami produktowymi. Dlatego system musi pomagać w realizacji rzeczywistych zadań biznesowych, nie być tylko bocznym projektem.

Atomic Design nadal aktualny

Frost przypomina, że atomic design pozostaje relevantny właśnie dlatego, że skupia się na prawdziwych zastosowaniach. Buttony i checkboxy nigdy nie istnieją w izolacji – służą tworzeniu rzeczywistych produktów.

Problem pojawia się, gdy zespoły systemowe i produktowe się oddalają. Frost obserwuje ten trend w wielu organizacjach.

Współpraca vs nadmierna automatyzacja

Frost krytykuje obsesję branży na punkcie narzędzi i automatyzacji. Paradoksalnie, im więcej „kolaboracyjnych” funkcji w narzędziach, tym mniejsza prawdziwa współpraca między ludźmi.

Wszyscy myślą, że są wyjątkowi

Frost ma trafną obserwację o uniwersalności problemów organizacyjnych. Każdy klient mówi: „Brad, nie rozumiesz – jesteśmy firmą healthcare/finansową/retailową. Jesteśmy wolni, biurokratyczni, mamy ludzi którzy nie rozmawiają ze sobą.”

Prawda jest taka, że to uniwersalne problemy ludzi próbujących współpracować. Niezależnie od branży, organizacje borykają się z tymi samymi wyzwaniami komunikacyjnymi i koordynacyjnymi.

Problem z handoff-ami

Frost wprost wyraża swoją opinię: „Nienawidzę słowa handoff”. Uważa, że automatyzacja między Figmą a kodem zastępuje potrzebną komunikację między designerami a developerami.

Dawniej w Photoshopie nie było responsywnych funkcji. Designerzy musieli rozmawiać z developerami o implementacji. Dzisiejsze narzędzia pozwalają zostać w strefie komfortu, ale designerzy unikają trudnych rozmów i marnują czas na nierealistyczne projekty.

Frost zauważa ironię: narzędzia reklamowane jako „collaborative” faktycznie izolują dyscypliny od siebie. Trzy minuty rozmowy na początku może zaoszczędzić pięć dni błędnej pracy.

Agile jako proces dehumanizujący

Frost krytykuje także współczesne podejście do procesów. Przekształcenie pracy w mikro-taski w JIRA nazywa „nieposzanowaniem, dehumanizacją i przeciwieństwem tworzenia wielkich rzeczy.”

Według niego prawdziwa kolaboracja to zespół ludzi pracujący razem nad tym samym celem, nie przekazywanie ticketów między osobami. Mała struktura jest dobra, ale różnica między prowadzeniem listy zadań a dzieleniem wszystkiego na mikroskopijne, izolowane silosy jest ogromna.

Design tokeny jako infrastruktura frontend

Frost wprowadza koncepcję design tokenów przez przykład Starbucks. Wyobraź sobie, że marka zmienia kolor z zielonego na fioletowy. Bez tokenów każda aplikacja – strona, iOS, Android, kiosk – musiałaby być aktualizowana osobno.

Checklist: Implementacja design tokenów krok po kroku

Krok 1: Rozmowa z zespołem

Porozmawiaj z developerami o obecnych zmiennych w kodzie
Sprawdź, czy używają Sass, CSS custom properties czy innych rozwiązań
Zidentyfikuj istniejące zmienne (np. $cat-yellow, $brand-blue)

Krok 2: Definicja tokenów

Stwórz repozytorium z plikami JSON
Zdefiniuj kolory w colors.json
Zdefiniuj typografię w typography.json
Zdefiniuj spacing, shadows, border-radius w odpowiednich plikach

Krok 3: Mapowanie ról

Zamień konkretne wartości na role (np. background-brand zamiast starbucks-green)
Zdefiniuj kontekstowe wykorzystanie kolorów
Przygotuj mapowanie dla różnych trybów (light/dark mode)

Krok 4: Konwersja i dystrybucja

Skonfiguruj Style Dictionary lub podobne narzędzie
Zdefiniuj formaty wyjściowe (CSS, Sass, iOS, Android)
Skonfiguruj automatyczne buildy tokenów
Połącz z Figma Variables lub Token Studio

Praktyczna implementacja tokenów

Design tokeny to właściwości designu zdefiniowane jako role w interfejsie, nie konkretne wartości. Zamiast „Starbucks Green” używasz „background-brand” mapowany na kolor marki.

Frost wyjaśnia architekturę: tokeny żyją jako JSON, niezależny od implementacji. Narzędzia jak Style Dictionary konwertują je na CSS, Sass, obiekty JavaScript czy formaty iOS/Android.

To pozwala jednocześnie wspierać różne platformy i łatwo zarządzać rebrandingiem lub wprowadzaniem trybu ciemnego.

Kto potrzebuje tokenów

Frost przyznaje: „Nawet ja potrzebuję systemu tokenów dla mojej marki”. Jego kolor pomarańczowy, niebieski i brązowy musi być spójny między stroną WordPress, platformą kursów i newsletterem Mailchimp.

Korzyści skalują się z wielkością organizacji, ale podstawowa wartość – strukturalne podejście do designu – jest uniwersalna.

Kto powinien być właścicielem systemu

Frost podkreśla, że właścicielami systemu powinni być ludzie, którzy się o niego troszczą. System może żyć w marketingu, produkcie, IT lub nowym dedykowanym zespole.

Najważniejsze to dedykacja. Design system to infrastruktura frontend, równie krytyczna jak API płatności dla sklepu e-commerce.

Checklist: Budowanie zespołu systemowego

Faza startowa (0-6 miesięcy)

Znajdź 1-2 osoby na pół etatu (design + dev)
Zdefiniuj pierwszy quick win – jeden flow do przeprojektowania
Skup się na demonstracji wartości biznesowej
Dokumentuj oszczędności czasu i poprawę jakości

Faza rozwoju (6-18 miesięcy)

Pokaż rezultaty pierwszego przeprojektowania
Zdobądź entuzjazm innych zespołów produktowych
Dodaj kolejne osoby do zespołu (docelowo 2-4 osoby)
Zdefiniuj roadmapę kolejnych flows do modernizacji

Faza stabilna (18+ miesięcy)

Stwórz dedykowany zespół systemowy
Ustanów proces przyjmowania wniosków od zespołów produktowych
Zdefiniuj metryki sukcesu (adoption rate, dev velocity)
Zaplanuj długoterminową roadmapę i wydarzenia edukacyjne

Partnership model vs „rzuć i uciekaj”

Frost podkreśla kluczową różnicę w pracy z design systemami. Stary model agencyjny to „oto twoja nowa strona, zadzwoń za 3-5 lat kiedy będziesz potrzebować nowej.”

Skuteczne systemy wymagają prawdziwego partnerstwa. To oznacza uczenie organizacji robienia tego samodzielnie. Frost opisuje swoje podejście: zespół zewnętrzny prowadzi pierwszy projekt, drugi robi wspólnie 50/50, przy trzecim organizacja przejmuje kontrolę.

Frost wyjaśnia: „Żeby system był długoterminowo udany, musi być ich własny. Muszą znać go dogłębnie”. Zewnętrzne wsparcie może przyspieszyć początki, ale właścicielstwo musi przejść do organizacji.

Co unikać przy budowaniu zespołu:

Nie rzucaj 12 osób na nowy zespół od razu
Nie zaczynaj bez jasnej wizji biznesowej
Nie pracuj w izolacji od zespołów produktowych
Nie skupiaj się tylko na konsystencji wizualnej
Nie ignoruj potrzeb różnych platform technologicznych

Frost ostrzega: „Nie rzucaj 12 osób na nowy zespół od razu”. Potrzeba szybkich zwycięstw, które można stackować jeden na drugim.

Design systemy jako sport zespołowy

Frost kończy obserwacją o ludzkiej naturze pracy. Sukces design systemów – jak każdego biznesu – zależy od umiejętności ludzi do współpracy, komunikacji i koordynacji.

Frost mówi wprost: „To ma bardzo mało wspólnego z tym, jak dobry jest design czy technologia. Ma wszystko wspólnego z ludźmi i ich zdolnością do współpracy.”

Zespoły odnoszące sukces charakteryzuje psychologiczne bezpieczeństwo – ludzie mogą swobodnie wyrażać opinie i kwestionować autorytety. Ważna jest otwartość na rozmowę, gdzie komunikacja przeważa nad sztywnymi procesami. Każda dyscyplina wnosi wartość, jeśli zespół ma wspólną wizję i potrafi balansować ideały z rzeczywistością.

Frost podkreśla, że największe wyzwania nie są techniczne. To pytania o dynamikę zespołu, władzy i komunikacji. Designerzy mają przewagę – rozumieją te dynamiki i mogą projektować lepsze procesy oraz środowiska pracy.

Lista kontrolna: Audyt design systemu według Brada Frosta

Użyj tych pytań, aby ocenić, czy Twój design system podąża we właściwym kierunku:

Powiązanie z biznesem

Czy każda duża inicjatywa w design systemie jest bezpośrednio powiązana z konkretnym celem biznesowym lub planem rozwoju produktu?

Prawdziwa współpraca

Czy regularnie organizujemy spotkania interdyscyplinarne (projektanci, deweloperzy, PM) na wczesnym etapie projektu, zanim powstanie ostateczny design?

Plan migracji

Czy nasz plan modernizacji starszych produktów opiera się na strategii modernizacji całych przepływów, a nie pojedynczych komponentów?

Mierzalna wartość

Czy potrafimy zmierzyć i zademonstrować, jak system przyspiesza pracę zespołów lub poprawia kluczowe metryki produktu (np. czas wdrożenia, wydajność)?

Jedno źródło prawdy

Czy nasz system wykorzystuje design tokeny jako centralny punkt zarządzania stylami dla wszystkich platform, na których działamy?

Kluczowy insight

Paradoks współpracy

Standardowo myślimy: Lepsze narzędzia do handoffu i automatyzacja między Figmą a kodem poprawią współpracę między designerami a developerami.

W praktyce okazuje się, że: Im bardziej automatyzujemy przekazywanie projektów, tym mniej ludzie ze sobą rozmawiają. Narzędzia reklamowane jako „collaborative” faktycznie izolują dyscypliny od siebie.

Dlaczego to jest istotne: Prawdziwe problemy produktowe rozwiązuje komunikacja między ludźmi, nie synchronizacja między narzędziami. Trzy minuty rozmowy na początku może zaoszczędzić pięć dni błędnej pracy.

Test na jutro: Następnym razem gdy planujesz nowy feature, zamiast od razu rzucać się do projektowania spróbuj najpierw 15-minutową rozmowę z developerem o ograniczeniach i możliwościach i sprawdź czy oszczędzisz czas w całym procesie.

Ten wpis zawiera notatki z podcastu Productcraft z Bradem Frostem. Wszystkie przemyślenia i obserwacje pochodzą od rozmówców. Źródło: https://www.youtube.com/watch?v=CTcAbikYX5A

Tag: Frontend Infrastruktura

Beyond Consistency – Design systemy które tworzą wartość produktową #EN293