Podstawowy design system składa się z fundamentów (tokeny kolorów, typografii i odstępów) oraz dwunastu komponentów, które pokrywają większość ekranów aplikacji B2B: przycisku, pól formularza, komunikatów, okna dialogowego, nawigacji i tabeli. Każdy z nich potrzebuje kompletu stanów i opisu, kiedy go używać. Resztę, na przykład wybór daty czy wykresy, lepiej dodać dopiero wtedy, gdy potrzebują jej co najmniej dwa zespoły.
Co powinien zawierać design system, zanim powstaną komponenty
Komponenty korzystają z wartości. Jeśli te wartości nie są nazwane i uzgodnione, każdy komponent utrwala przypadkowe decyzje. Dlatego pierwsza warstwa systemu to fundamenty.
- Design tokeny. Nazwane wartości kolorów, rozmiarów tekstu, odstępów, zaokrągleń i cieni. Warstwa podstawowa przechowuje wartość (na przykład konkretny odcień niebieskiego), warstwa semantyczna jej rolę (kolor akcji głównej). Dzięki temu tryb ciemny albo druga marka to nowy zestaw wartości, bez przerabiania komponentów. W Figmie tokenom odpowiadają zmienne i ich tryby, a wspólny format zapisu opisuje specyfikacja Design Tokens 2025.10. Szerzej opisuje je tekst o tym, czym są design tokeny.
- Typografia. Skala rozmiarów i stylów tekstu z przypisaną rolą: nagłówki, tekst podstawowy, etykiety, tekst pomocniczy.
- Odstępy i siatka. Jedna skala odstępów i zasady układu dla szerokości ekranu, które produkt obsługuje.
- Ikony. Jeden zestaw w jednej grubości linii i w ustalonych rozmiarach.
12 komponentów, od których zaczyna się design system
Lista jest ułożona według kolejności budowy. Pierwsze pozycje występują na prawie każdym ekranie, a kolejne z nich korzystają.
| Nr | Komponent | Stany i warianty do zaprojektowania | Wymagania dostępności |
|---|---|---|---|
| 1 | Przycisk | Główny, drugorzędny, tekstowy, destrukcyjny; najechanie, fokus, aktywny, wyłączony, ładowanie; z ikoną i bez | Widoczny fokus, cel co najmniej 24 na 24 piksele CSS, nazwa dostępna dla przycisku z samą ikoną |
| 2 | Link | W tekście i samodzielny; odwiedzony, fokus | Odróżnienie od tekstu nie tylko kolorem |
| 3 | Pole tekstowe | Puste, wypełnione, fokus, błąd, wyłączone, tylko do odczytu; etykieta, tekst pomocniczy, licznik znaków | Etykieta powiązana z polem, błąd opisany tekstem |
| 4 | Pole wyboru, przełącznik opcji i przełącznik | Zaznaczone, niezaznaczone, częściowo zaznaczone, fokus, błąd, wyłączone | Obsługa klawiaturą, stan odczytywany przez czytnik ekranu |
| 5 | Lista rozwijana | Zamknięta, otwarta, z wyszukiwaniem, wielokrotny wybór, brak wyników | Nawigacja strzałkami, ogłaszanie wybranej opcji |
| 6 | Komunikat w treści | Informacja, sukces, ostrzeżenie, błąd; z akcją i bez | Znaczenie przekazane ikoną i tekstem, nie samym kolorem |
| 7 | Powiadomienie chwilowe | Te same cztery typy; czas wyświetlania, akcja cofnięcia | Treść ogłaszana bez przenoszenia fokusu |
| 8 | Okno dialogowe | Potwierdzenie, formularz, treść przewijana; rozmiary | Fokus zamknięty w oknie, zamknięcie klawiszem Escape, powrót fokusu po zamknięciu |
| 9 | Nawigacja główna | Pozycja aktywna, zwinięta i rozwinięta, wersja na wąski ekran | Oznaczenie bieżącej strony, kolejność tabulacji zgodna z układem |
| 10 | Zakładki i okruszki | Aktywna, nieaktywna, wyłączona, przepełnienie | Obsługa strzałkami, oznaczenie wybranej zakładki |
| 11 | Tabela | Sortowanie, zaznaczanie wierszy, paginacja, stan pusty, ładowanie, błąd | Nagłówki kolumn powiązane z komórkami |
| 12 | Karta, znacznik i stan pusty | Karta klikalna i statyczna; znaczniki statusów; stan pusty z akcją | Kontrast tekstu co najmniej 4,5:1, status opisany tekstem |
Progi liczbowe pochodzą z kryteriów poziomu AA w WCAG 2.2: 1.4.3 (kontrast), 1.4.1 (użycie koloru), 2.4.7 (widoczny fokus), 2.5.8 (rozmiar celu) i 4.1.3 (komunikaty o stanie). Wzorce obsługi klawiaturą dla okna dialogowego, listy rozwijanej, zakładek i tabeli opisuje przewodnik ARIA Authoring Practices Guide publikowany przez W3C. Stan ładowania z przycisku i tabeli omawia osobny tekst o tym, jak dobierać loadery i stany ładowania.
Co musi mieć każdy komponent
Komponent w systemie to więcej niż rysunek. Żeby projektant i programista mogli go użyć bez pytań, potrzebne są cztery rzeczy.
- Komplet stanów. Domyślny, najechanie, fokus, aktywny, wyłączony, a dla pól także błąd i ładowanie. Brakujący stan zostanie dorysowany w pliku produktowym i od tego miejsca zaczyna się druga wersja komponentu.
- Powiązanie z tokenami. Żadna wartość koloru ani odstępu nie jest wpisana ręcznie.
- Zasady użycia. Kiedy sięgnąć po ten komponent, a kiedy po inny, z przykładem poprawnym i błędnym. Jedno zdanie w rodzaju „na ekranie jest najwyżej jeden przycisk główny” oszczędza więcej dyskusji niż strona specyfikacji.
- Odpowiednik w kodzie. Ta sama nazwa, te same właściwości i warianty. Dokumentację techniczną komponentów zespoły często prowadzą w Storybooku, czyli środowisku do budowania i przeglądania komponentów w izolacji.
Co odłożyć na później
Do pierwszej wersji systemu nie powinny trafić komponenty rzadkie i kosztowne: wybór daty i zakresu dat, edytor tekstu, wykresy, kreator wieloetapowy, przesyłanie plików z podglądem, drzewo, kalendarz. Każdy z nich to praca porównywalna z kilkoma komponentami z listy, a używa go zwykle jeden moduł.
Praktyczna zasada brzmi: komponent trafia do systemu, gdy potrzebują go co najmniej dwa zespoły albo występuje w co najmniej trzech miejscach produktu. Do tego czasu zostaje w pliku zespołu, zbudowany z tokenów i mniejszych komponentów systemu. Dzięki temu biblioteka rośnie w tempie, w jakim da się ją utrzymać. Sygnały, że produkt w ogóle dojrzał do systemu, zbiera tekst o tym, kiedy wdrożyć design system.
Wzorce funkcjonalne i percepcyjne
Podział na komponenty i fundamenty ma odpowiednik w literaturze. Alla Kholmatova w książce „Design Systems” (Smashing Magazine, 2017) rozróżnia wzorce funkcjonalne, czyli konkretne elementy jak przyciski i pola, oraz wzorce percepcyjne, czyli style ikon, kolory i typografię, które decydują o charakterze produktu. Wniosek dla planowania jest prosty: lista komponentów bez uzgodnionej warstwy wizualnej daje produkt poprawny, ale bez własnego charakteru, a sama warstwa wizualna bez komponentów nie przyspiesza pracy.
Od listy do działającego systemu
Lista dwunastu komponentów jest punktem startu, a o kolejności decyduje stan obecnego produktu. Dlatego prace nad design systemem zaczynamy w Squares od policzenia, które elementy występują najczęściej i w ilu wersjach. Jak wygląda to liczenie, pokazuje wpis o tym, czym jest audyt design systemu. Koszt takiego zakresu opisuje tekst o tym, ile kosztuje design system.
Najczęstsze pytania
Z czego składa się design system?
Design system składa się z dwóch warstw. Pierwsza to fundamenty: design tokeny, czyli nazwane wartości kolorów, rozmiarów tekstu i odstępów, a także typografia, siatka i ikony. Druga to komponenty zbudowane z tych wartości, każdy z kompletem stanów, zasadami użycia i odpowiednikiem w kodzie. Podstawowa wersja obejmuje dwanaście komponentów.
Ile komponentów potrzebuje design system na start?
Na start wystarcza dwanaście komponentów, które pokrywają większość ekranów aplikacji B2B: przycisk, link, pola formularza, lista rozwijana, komunikaty, okno dialogowe, nawigacja, zakładki, tabela i karta. Komponenty rzadkie i kosztowne, jak wybór daty czy wykresy, trafiają do systemu dopiero wtedy, gdy potrzebują ich co najmniej dwa zespoły.
