Audyt design systemu to przegląd, który odpowiada na trzy pytania: ile wersji tych samych elementów istnieje dziś w produkcie, czy biblioteka projektowa zgadza się z kodem i czy zespół faktycznie z niej korzysta. Wynikiem jest lista zmian ułożona według wpływu na tempo pracy, a nie ocena estetyki. Audyt ma sens zarówno przed budową systemu, jak i wtedy, gdy istniejący system przestał nadążać za produktem.
Kiedy audyt design systemu jest potrzebny
Audyt zamawia się w czterech sytuacjach. Pierwsza: produkt nie ma systemu, a zespół chce wiedzieć, od czego zacząć i ile to będzie kosztować. Druga: system istnieje, ale projektanci odpinają komponenty od biblioteki, a programiści piszą własne wersje. Trzecia: planowana jest duża zmiana, na przykład tryb ciemny, nowa marka albo zgodność z WCAG 2.2, i trzeba oszacować jej zakres. Czwarta: zespół przejmuje produkt po innym wykonawcy i nie wie, w jakim stanie jest biblioteka.
Dla osoby odpowiedzialnej za budżet produktu audyt daje liczby, którymi można uzasadnić inwestycję w system albo decyzję, że na system jest za wcześnie. Jak rozpoznać ten moment, opisuje wpis o pięciu sygnałach, że produkt potrzebuje design systemu.
Co sprawdza audyt design systemu: pięć obszarów
1. Inwentaryzacja interfejsu
Audyt zaczyna się od produktu, a nie od biblioteki. Zbieramy zrzuty wszystkich wystąpień przycisków, pól formularzy, tabel, okien dialogowych i komunikatów, a potem grupujemy je i liczymy. Wynik to tabela w rodzaju: przycisk główny, liczba wersji, czym się różnią, która zostaje. Ta jedna tabela zwykle wystarcza, żeby zespół zobaczył skalę problemu bez dodatkowych argumentów.
2. Fundamenty i tokeny
Sprawdzamy, ile kolorów, rozmiarów tekstu i wartości odstępów jest faktycznie używanych w plikach projektowych i w kodzie oraz ile z nich ma nazwę. Design tokeny, czyli nazwane wartości, z których korzystają komponenty, powinny mieć warstwę podstawową (konkretna wartość) i semantyczną (rola, na przykład tło ostrzeżenia). W Figmie odpowiadają im zmienne i ich tryby. Punktem odniesienia dla formatu wymiany jest specyfikacja Design Tokens 2025.10, opublikowana jako stabilna w październiku 2025 r. przez grupę społecznościową działającą przy W3C.
3. Biblioteka komponentów
Dla każdego komponentu oceniamy komplet stanów (domyślny, najechanie, fokus, aktywny, wyłączony, błąd, ładowanie), sposób budowy wariantów, nazewnictwo i opis. Osobno liczymy komponenty odpięte od biblioteki w plikach produktowych. Wysoki odsetek odpięć przy jednym komponencie oznacza, że brakuje mu wariantu, którego zespół potrzebuje.
4. Zgodność projektu z kodem
Porównujemy bibliotekę projektową z komponentami w kodzie: nazwy, właściwości, warianty, wartości tokenów. Sprawdzamy, czy istnieje jedno miejsce z dokumentacją techniczną, na przykład Storybook, i czy pokazuje ono te same komponenty, które widzi projektant. Rozbieżności w tym obszarze kosztują najwięcej, bo każda oznacza pytanie programisty i odpowiedź projektanta przy każdym zadaniu.
5. Proces i odpowiedzialność
Ostatni obszar dotyczy ludzi. Kto zatwierdza nowy komponent, jak zespół produktowy zgłasza potrzebę, jak publikowane są zmiany i skąd pozostałe zespoły o nich wiedzą. System bez właściciela i bez ścieżki zgłoszeń przestaje być aktualny w ciągu kilku kwartałów, niezależnie od jakości biblioteki. Stałą opiekę nad systemem po audycie obejmuje usługa DesignOps.
Lista kontrolna audytu design systemu
| Obszar | Pytanie kontrolne | Sygnał problemu |
|---|---|---|
| Inwentaryzacja | Ile wersji ma każdy z dziesięciu najczęstszych elementów? | Więcej niż jedna wersja bez uzasadnienia w funkcji |
| Kolory | Ile kolorów jest w użyciu, a ile ma token? | Wartości wpisane ręcznie, kilka odcieni tej samej szarości |
| Typografia i odstępy | Czy rozmiary tekstu i odstępy pochodzą ze skali? | Wartości spoza skali w plikach i w kodzie |
| Stany | Czy każdy komponent interaktywny ma fokus, błąd i stan wyłączony? | Stany dorysowywane w plikach produktowych |
| Dostępność | Czy kontrast, widoczność fokusu i rozmiar celu spełniają WCAG 2.2 AA? | Tekst poniżej 4,5:1, cele mniejsze niż 24 na 24 piksele CSS |
| Odpięcia | Ile instancji jest odpiętych od biblioteki? | Jeden komponent odpinany częściej niż pozostałe |
| Projekt i kod | Czy nazwy i właściwości komponentów są takie same w obu miejscach? | Ten sam element pod dwiema nazwami |
| Dokumentacja | Czy opis mówi, kiedy komponentu użyć, a kiedy nie? | Opis ogranicza się do wyglądu |
| Proces | Kto zatwierdza nowe komponenty i jak publikowane są zmiany? | Brak właściciela, brak rejestru zmian |
Progi kontrastu i rozmiaru celu pochodzą z kryteriów 1.4.3 i 2.5.8 WCAG 2.2.
Co jest wynikiem audytu
Po audycie zespół ma cztery dokumenty.
- Inwentarz. Tabela elementów z liczbą wersji i decyzją: zostaje, scalamy, usuwamy.
- Lista rozbieżności. Miejsca, w których projekt różni się od kodu, z oceną, po której stronie jest wersja docelowa.
- Kolejność prac. Zmiany ułożone według tego, ile pracy oszczędzają i ile kosztują. Scalenie kolorów i odstępów zwykle idzie pierwsze, bo odblokowuje resztę.
- Zakres i wycena. Liczba komponentów do zbudowania albo przebudowania, która pozwala podać koszt systemu. Sposób liczenia opisuje tekst o tym, ile kosztuje design system.
Ile trwa audyt i czego wymaga od zespołu
Czas zależy od liczby ekranów i od tego, czy audyt obejmuje kod. Potrzebny jest dostęp do plików projektowych, do działającego produktu i, jeśli porównujemy z kodem, do repozytorium albo dokumentacji komponentów. Po stronie zespołu wystarczają dwie rozmowy: na początku o tym, jak powstają nowe ekrany, i na końcu o wnioskach.
Audyt nie obejmuje badań z użytkownikami ani oceny użyteczności ścieżek. To zakres audytu UX/UI, który odpowiada na inne pytanie: gdzie produkt traci użytkowników. Kryteria wyboru wykonawcy przy dużych bibliotekach opisuje osobny tekst o audycie design systemu w dużej organizacji.
Audyt jako pierwszy etap design systemu w Squares
W Squares audyt jest pierwszym z czterech etapów usługi Design system, wycenianej od 12 000 zł netto. Po audycie zespół dostaje zakres i wycenę kolejnych etapów i decyduje, czy prace idą dalej.
Najczęstsze pytania
Ile trwa audyt design systemu?
Czas zależy od liczby ekranów i od tego, czy audyt obejmuje kod. Potrzebny jest dostęp do plików projektowych, działającego produktu i, przy porównaniu z kodem, do repozytorium albo dokumentacji komponentów. Po stronie zespołu wystarczają dwie rozmowy: na początku o tym, jak powstają nowe ekrany, i na końcu o wnioskach.
Co jest wynikiem audytu design systemu?
Cztery dokumenty: inwentarz elementów z liczbą wersji i decyzją, co zostaje, lista rozbieżności między projektem a kodem, kolejność prac ułożona według oszczędzanej pracy i kosztu oraz zakres z wyceną. Ostatni dokument podaje liczbę komponentów do zbudowania albo przebudowania, więc pozwala określić koszt całego systemu.
