Kiedy rosnący produkt potrzebuje design systemu (i jak go zacząć)
UX
Kiedy rosnący produkt potrzebuje design systemu (i jak go zacząć)
Sygnały, że strona lub SaaS potrzebuje design systemu, co powinien zawierać (tokeny, komponenty, wzorce, dokumentacja), jak go zbudować bez zatrzymywania prac nad produktem i jak utrzymać go przy życiu.
W skrócie
Sygnały, że strona lub SaaS potrzebuje design systemu, co powinien zawierać (tokeny, komponenty, wzorce, dokumentacja), jak go zbudować bez zatrzymywania prac nad produktem i jak utrzymać go przy życiu.
Produkt potrzebuje design systemu, gdy te same decyzje dotyczące interfejsu zapadają w kółko: nowe ekrany wyglądają trochę inaczej niż stare, programiści budują przyciski i formularze od nowa przy każdej funkcji, a przeglądy projektów schodzą na odstępy zamiast na problemy użytkowników. Design system rozwiązuje to wspólnymi tokenami (kolory, typografia, odstępy), biblioteką zakodowanych komponentów, wzorcami dla typowych sytuacji i krótką dokumentacją, która mówi, czego kiedy używać.
Pięciostronicowa strona nie potrzebuje design systemu. Prawdopodobnie potrzebujesz go, gdy produkt ma dziesiątki ekranów, projektuje lub buduje go więcej niż jedna osoba albo kilka produktów ma wyglądać jak jedna marka.
Sygnały, że to już czas
Istnieją trzy różne niebieskie przyciski i nikt nie wie, który jest właściwy
Każda nowa funkcja zaczyna się od „jak tym razem ma wyglądać tabela?”
Programiści kopiują komponenty między plikami i lekko je zmieniają
Tryb ciemny, nowy kolor marki albo poprawki dostępności oznaczałyby edycję setek miejsc
Przekazanie projektu do developmentu trwa dłużej niż budowa
Użytkownicy zauważają, że części produktu wyglądają jak różne aplikacje
Co zawiera design system
Warstwa
Co to jest
Przykład
Tokeny
Nazwane wartości decyzji projektowych
color.primary, space.4, radius.md, font.heading
Komponenty
Zakodowane klocki wielokrotnego użytku
Przycisk, pole, lista wyboru, modal, tabela, karta, toast
Wzorce
Połączenia dla typowych zadań
Formularze z walidacją, puste stany, filtry, onboarding
Zasady
Kiedy i jak ich używać
„Jeden główny przycisk na ekranie”
Narzędzia
Gdzie to wszystko żyje
Biblioteka w Figmie, pakiet w kodzie, strona z dokumentacją
Tokeny to fundament. Gdy kolory i odstępy są tokenami, zmiana koloru marki albo dodanie trybu ciemnego to zmiana w jednym pliku, a nie polowanie w całym kodzie.
Zacznij od tego, co już istnieje
Nie projektuj systemu od zera na pustym ekranie. Zacznij od inwentaryzacji:
Zrób zrzut każdego ekranu i pogrupuj podobne elementy: wszystkie przyciski, pola, tabele.
Policz warianty. Często znajdziesz wiele odcieni szarości i kilka stylów przycisków.
Wybierz najlepszą wersję każdego elementu i ustal ją jako standard.
Zamień wartości w tokeny: kolory, rozmiary fontów, odstępy, zaokrąglenia, cienie.
Zbuduj najpierw najczęściej używane komponenty, zwykle przyciski, pola, listy wyboru, karty, modale i tabele.
Dzięki temu system odzwierciedla prawdziwy produkt, a zespół go rozpoznaje.
Użyj dobrej bazy zamiast wymyślać wszystko od nowa
Nowoczesne biblioteki komponentów dają dostępne, dobrze przetestowane fundamenty. W produktach w React często budujemy na shadcn/ui i Tailwind CSS: komponenty żyją w Twoim kodzie, więc dopasujesz je do marki, a tokeny naturalnie mapują się na zmienne CSS. Tak podchodzimy do dashboardów i interfejsów SaaS, w tym naszych narzędzi wewnętrznych.
Niezależnie od bazy upewnij się, że komponenty od pierwszego dnia obsługują klawiaturę, stany focus, czytniki ekranu i kontrast. Dostępność w systemie jest dużo tańsza niż poprawianie jej ekran po ekranie.
Zbuduj go bez zatrzymywania prac nad produktem
Projekt design systemu, który na miesiące zamraża nowe funkcje, rzadko przetrwa. Zamiast tego:
Buduj komponenty, gdy potrzebują ich funkcje. Kolejna funkcja z tabelą buduje systemową tabelę.
Wymieniaj stare komponenty stopniowo, strona po stronie, przy normalnej pracy.
Ustal zasadę: nowe ekrany używają komponentów systemu, wyjątki wymagają uzasadnienia.
Wyznacz właściciela, choćby na część etatu, który przegląda dodatki i aktualizuje dokumentację.
Dokumentacja, którą ludzie naprawdę czytają
Niech dokumentacja będzie krótka i blisko kodu:
Podgląd każdego komponentu na żywo z wariantami
Przykłady „tak” i „nie”
Fragmenty kodu do skopiowania
Uwagi o dostępności i treściach (etykiety przycisków, komunikaty błędów)
Storybook albo prosta strona wewnętrzna wystarczą. Długich PDF-ów nikt nie czyta.
Jak sprawdzić, że działa
Nowe ekrany szybciej się projektuje i buduje
Mniej uwag w przeglądach o odstępach i kolorach
Mniej zgłaszanych błędów interfejsu
Zmiana marki lub motywu trwa godziny, nie tygodnie
Nowe osoby w zespole w pierwszym tygodniu dostarczają spójne ekrany
Design system dla strony a dla produktu
Strona marketingowa korzysta z lżejszego systemu: skali typografii, kolorów, odstępów, układów sekcji i kilku komponentów (hero, blok korzyści, opinia, wezwanie do działania, formularz). Produkt SaaS potrzebuje więcej: tabel danych, formularzy, nawigacji, stanów informacji zwrotnej i złożonych wzorców. Wiele firm dzieli tokeny między oba, żeby marka była spójna od landing page'a po aplikację.
Przy prostej stronie wystarczy przewodnik stylu. Przy produkcie z wieloma ekranami albo kilkoma osobami w zespole nawet mały system tokenów i podstawowych komponentów szybko oszczędza czas.
Czy biblioteka w Figmie to design system?
To jedna część. Pełny design system ma też zakodowane komponenty, więc to, co rysują projektanci, jest tym, co dostarczają programiści.
Ile trwa zbudowanie design systemu?
Przydatna pierwsza wersja z tokenami i dziesięcioma najczęstszymi komponentami może być gotowa w kilka tygodni. Potem rośnie razem z produktem.
Czy możemy użyć gotowej biblioteki, np. Material lub shadcn/ui?
Tak. Start od solidnej biblioteki i dopasowanie jej do marki jest zwykle szybsze i bardziej dostępne niż budowanie każdego komponentu od zera.