Przycisk „Zapisz” wygląda inaczej w każdym widoku, a poprawka w jednym miejscu nie zmienia pozostałych. W takiej sytuacji design system może uporządkować pracę zespołu, ale tylko wtedy, gdy obejmuje więcej niż wspólną bibliotekę komponentów. Sama paczka przycisków nie rozwiąże problemu, jeśli projektanci i programiści inaczej rozumieją ich zastosowanie.
Dobry design system łączy decyzje projektowe z kodem i sposobem użycia
- System obejmuje style, komponenty, wzorce oraz dokumentację ich zastosowania.
- Tokeny semantyczne przypisują wartościom, takim jak kolor, określoną rolę w interfejsie.
- Komponent powinien mieć opisane stany, dostępność i zachowanie, nie tylko wygląd.
- Rozwijaj system na podstawie powtarzających się potrzeb, zamiast tworzyć katalog każdej możliwej kontrolki.
- Sprawdź obszar klikalny i odległość od sąsiednich elementów, szczególnie w małych przyciskach ikonowych.
Biblioteka komponentów nie wystarczy, gdy brakuje zasad użycia
Dwie karty w Figmie mogą wyglądać identycznie, a w produkcie działać inaczej: jedna jest klikalna, druga tylko prezentuje dane. Design system łączy wygląd, zachowanie i kontekst użycia, żeby zespół nie musiał za każdym razem ustalać tych rzeczy od początku.
Dobrym punktem odniesienia jest GOV.UK Design System, który rozdziela style, komponenty i wzorce. Komponent to pojedynczy element, na przykład pole tekstowe; wzorzec opisuje sposób wykonania zadania, takiego jak sprawdzenie odpowiedzi przed wysłaniem formularza. To rozróżnienie pomaga uniknąć błędu, w którym gotowy przycisk uznaje się za gotowe rozwiązanie całego przepływu.
W praktyce system może zawierać tokeny, komponenty, wzorce, dokumentację i zasady współpracy. Tokeny to nazwane wartości, takie jak kolor tekstu głównego czy odstęp między sekcjami; komponenty korzystają z nich, a dokumentacja wyjaśnia, kiedy i jak ich używać. Uważam, że najbardziej użyteczny system to taki, który podpowiada zespołowi właściwą decyzję, zamiast jedynie udostępniać ładne pliki.
Token semantyczny pozwala zmienić rolę bez szukania koloru w kodzie
Jeśli kolor błędu jest zapisany jako niepowiązany z rolą odcień czerwieni, jego zmiana może wymagać szukania wartości w wielu komponentach. Token semantyczny nazywa funkcję, na przykład „tekst błędu”, a nie samą barwę; komponent odwołuje się do tej roli, a nie do konkretnego kodu koloru.
Warstwę bazową można zbudować z surowych wartości, takich jak paleta barw czy skala odstępów. Warstwa semantyczna przypisuje im znaczenie, a komponent korzysta z odpowiedniego tokenu. Przy zmianie motywu lub marki aktualizujesz mapowanie wartości, zamiast ręcznie poprawiać każdy przycisk i komunikat.
Przed dodaniem tokenu sprawdź, czy odpowiada on powtarzalnej decyzji projektowej. Jeśli jednorazowy ekran potrzebuje nietypowego odstępu, tworzenie globalnej zmiennej może tylko powiększyć słownik. Lepiej opisać wyjątek lokalnie i wrócić do niego, gdy podobna potrzeba pojawi się w kolejnych częściach produktu.
Przycisk bez opisanych stanów przenosi niejasność do interfejsu
Komponent często wygląda przekonująco na makiecie w stanie domyślnym. Problem wychodzi później: użytkownik czeka na zapis, ponawia kliknięcie albo nie widzi, które pole wymaga poprawy. Każdy komponent interaktywny powinien mieć opisane stany, nie tylko wariant wizualny.
Dla przycisku opisz co najmniej stan domyślny, fokus, wyłączenie i oczekiwanie na wynik działania. Dla pola formularza dodaj błąd, tekst pomocniczy i informację, jak komunikat wiąże się z polem. Nazwa dostępna dla czytnika ekranu jest szczególnie ważna przy przycisku z samą ikoną, bo sama grafika nie wyjaśnia jego funkcji.
Wymagania dotyczące małych kontrolek łatwo przeoczyć w gęstym pasku narzędzi. W3C w wyjaśnieniu kryterium WCAG 2.2 dotyczącego minimalnego rozmiaru celu wskazuje próg 24 na 24 piksele CSS dla celu wskaźnika, z wyjątkami obejmującymi między innymi odpowiedni odstęp od innych celów. Ikona może więc być mała wizualnie, ale jej obszar klikalny powinien uwzględniać wymóg rozmiaru lub odstępu.
GOV.UK i Material Design pokazują dwa różne punkty startu
Gotowy system może przyspieszyć pracę, ale nie każdy będzie pasować do produktu. GOV.UK Design System mocno porządkuje usługi i zadania, takie jak formularze czy sprawdzanie odpowiedzi; Material Design 3 oferuje rozbudowany język wizualny i role kolorów, które można dopasowywać do motywu. Wybór zależy więc od tego, czy ważniejsza jest zgodność z określonym typem usługi, czy elastyczność wizualna.
W GOV.UK wzorce opisują zadania użytkownika i pokazują, jak łączyć komponenty w kontekście. W Material Design tokeny kolorów pełnią role w systemie, a komponenty korzystają z przypisanych ról. Nie kopiuj systemu wyłącznie dlatego, że jest znany: styl zaprojektowany dla usług publicznych może nie pasować do narzędzia analitycznego, a rozbudowana personalizacja może być zbędna w małym panelu administracyjnym.
| Potrzeba zespołu | Punkt startu | Na co uważać |
|---|---|---|
| Spójne formularze i przepływy usługowe | GOV.UK Design System | Sprawdź dopasowanie języka wizualnego i wzorców do produktu. |
| Tematy kolorystyczne i interfejs oparty na rolach wizualnych | Material Design 3 | Nie wprowadzaj całej złożoności systemu, jeśli produkt potrzebuje kilku komponentów. |
| Produkt o własnej marce i specyficznych zadaniach | Własny, mały system oparty na sprawdzonych zasadach | Zespół musi utrzymywać dokumentację i pilnować zgodności projektu z kodem. |
Przy małym produkcie z jedną aplikacją wybrałbym lekką bibliotekę własnych komponentów i przejął z gotowego systemu sprawdzone wzorce dostępności. Gdy kilka zespołów buduje różne usługi, postawiłbym na pełniejszy system z właścicielem, procesem zmian i dokumentacją, bo bez tych ustaleń wspólne komponenty szybko się rozchodzą.
Rozwijaj system tam, gdzie powtarzają się decyzje
Największe ryzyko to budowa rozbudowanej biblioteki, zanim wiadomo, z czego zespoły rzeczywiście korzystają. Zacznij od elementów powtarzających się w produkcie: typografii, kolorów, przycisków, pól i komunikatów. Rzadki komponent dodaj dopiero wtedy, gdy jego zachowanie da się uzasadnić potrzebą użytkownika, a nie samą chęcią kompletności katalogu.
Przy każdym elemencie zapisz właściciela, status, dozwolone warianty i sposób zgłaszania zmian. Dokumentacja powinna łączyć przykład wizualny z kodem oraz wyjaśniać, kiedy użyć elementu, a kiedy wybrać inny. W przeciwnym razie zespół zobaczy gotowy komponent, ale nadal będzie musiał zgadywać, jak rozwiązać problem w konkretnym widoku.
Najlepszy test dojrzałości systemu pojawia się przy zmianie: czy aktualizacja wspólnej decyzji przechodzi do właściwych komponentów bez serii lokalnych poprawek? Jeśli tak, system wspiera codzienną pracę. Jeśli nie, być może brakuje semantycznych tokenów, jasnych reguł albo synchronizacji między projektem a kodem.
