Definiuj decyzje, nie tylko galerię stylów
Design system to więcej niż zrzuty ekranu. Zapisuje decyzje, które się powtarzają: odstępy między sekcjami, sposób prezentacji akcji głównej, zachowanie błędu formularza i język używany po powodzeniu lub porażce. USWDS opisuje design tokens jako dyskretne palety wartości dla typografii, odstępów, kolorów, wysokości linii i przezroczystości. Udokumentuj regułę, cel, zatwierdzone warianty i właściciela. Zacznij od fundamentów i pięciu–ośmiu komponentów używanych najczęściej w kluczowych podróżach użytkownika; standaryzacja każdej strony naraz zwykle wprowadza więcej szumu niż jasności.
Zapisz zatwierdzone role kolorów, kroje, odstępy, obramowania, promienie zaokrągleń, punkty przerwania i wybory animacji, których serwis faktycznie używa.
Używaj wzorca dla powtarzalnego układu zadania, takiego jak zakładanie konta czy wyniki wyszukiwania, zamiast dla pojedynczego efektu wizualnego.
Używaj tokenów do kontrolowania powtarzalnych wartości
Token projektowy to czytelna dla człowieka nazwa powiązana z wartością. Design Tokens Community Group opisuje tokeny jako platformowo-niezależny sposób wyrażania decyzji projektowych; minimum, czym jest token, to nazwa i wartość. Używaj nazw celowych, takich jak color-action-primary lub space-section zamiast rozrzucania surowych wartości w szablonach. Zachowaj udokumentowane mapowanie od tokenów celowych do wartości bazowych. Tokeny ułatwiają skoordynowane zmiany, ale nie gwarantują kontrastu, tożsamości marki ani dobrej hierarchii. Waliduj każdą renderowaną kombinację i stan strony.
Twórz tokeny dla powtarzalnych wyborów, a nie dla każdego wyjątku; w przeciwnym razie lista tokenów jedynie zachowa niespójność.
Dla tokena używanego szeroko wymień strony, które on dotyczy, przetestuj reprezentatywne ekrany i zapewnij wskazówki migracyjne lub wycofania, gdy to potrzebne.
Buduj komponenty z zachowaniem i granicami
Komponent to wielokrotnego użytku element interfejsu z zachowaniem, a nie tylko kształt wizualny. Udokumentuj strukturę semantyczną, wymagane i opcjonalne wejścia, warianty, zachowanie responsywne oraz wszystkie istotne stany: ładowanie, wyłączony, błąd, pusty i powodzenie. Dołącz zachowanie z klawiatury i wskazówki dotyczące treści. Nie zmuszaj każego układu do bycia komponentem. GOV.UK ocenia współdzielone komponenty pod kątem użyteczności, unikalności, używalności, spójności i wszechstronności; to przydatna dyscyplina przy podejmowaniu decyzji, co zasługuje na wspólne utrzymanie. Szeroko stosowany komponent może też szeroko rozpowszechnić defekt, więc testuj go na stronach, gdzie ludzie z niego korzystają.
Wymień każdy widoczny dla użytkownika stan i pokaż rzeczywiste etykiety, długie treści i błędy, żeby widoczne były ograniczenia implementacji.
Oznacz stare warianty wyraźnie, nazwij zamiennik i usuń je dopiero po przejrzeniu wszystkich dotkniętych podróży.
Uczyń dostępność warunkiem wydania
Dostępność musi być wbudowana w system, ponieważ powtarzalne wybory mogą powielać bariery. WCAG 2.2 wymaga, na poziomie A, obsługi klawiatury dla funkcjonalności z wyjątkiem przypadków, gdzie ścieżka ruchu jest istotą interakcji, oraz wymaga sensownego porządku fokusu, gdy sekwencja ma znaczenie. Uczyń semantyczne kontrolki, widoczny fokus, etykiety, logiczny ruch fokusu, identyfikację błędów i możliwość wykonania zadania bez wskaźnika częścią wytycznych komponentów. Korzystaj z automatycznych kontroli wcześnie, a następnie wykonuj ręczne testy klawiaturą, powiększaniem, responsywnością i testy stron. USWDS ostrzega, że dostępne komponenty nie gwarantują dostępnej usługi; niestandardowy kod, treść, integracje i kontekst wciąż wymagają przeglądu.
Potwierdź, że użytkownicy mogą dotrzeć do kontrolek, obsługiwać je, rozumieć je i opuścić bez pułapki klawiaturowej.
Obowiązki prawne różnią się w zależności od jurysdykcji i umowy. Przy kwestiach istotnych prawnie zasięgnij kwalifikowanej opinii dostępności i prawnej.
Traktuj standardy treści jak standardy interfejsu
Słowa to wejścia komponentu, a nie ozdoba dodawana po projektowaniu. Ustal reguły dla etykiet akcji, etykiet pól formularzy, komunikatów o błędach, nagłówków, linków, terminologii, dat, liczb i skrótów. Wytyczne GOV.UK preferują stronę czynną i zwracanie się do użytkownika per „ty”, gdy to możliwe; stosuj zasadę jasnego, konsekwentnego języka, dostosowując ton do odbiorcy. Sparuj reguły z modelem treści: określ, które pola są obowiązkowe, sensowne ograniczenia długości i co się dzieje, gdy informacji brakuje. Umieść wytyczne w dokumentacji komponentów i w przepływach pracy CMS, tak by redaktorzy mogli ich używać.
Powiedz, co zawiodło, gdzie to się stało i jaka jest następna akcja, gdy jest to bezpieczne i użyteczne.
Limit to sygnał do przeprojektowania lub skrócenia, a nie pozwolenie na usunięcie istotnego znaczenia.
Zarządzaj systemem zanim urośnie szybciej niż zaufanie
Zarządzanie to lekkie procesy dotyczące własności, zgłoszeń, przeglądu, wydań i wycofywania. Wskaż odpowiedzialnego właściciela i grupę przeglądową, która może zgromadzić wiedzę z zakresu projektowania, inżynierii, treści i dostępności. Dopasuj dowody do promienia wybuchu (blast radius). Lokalny wzorzec może wymagać opisu problemu i testu strony. Zmiana wspólnego przycisku lub tokena powinna zawierać dotknięte podróże, kontrole dostępności, porównanie wizualne, notatki migracyjne i instrukcje rollbacku. GOV.UK prosi współtwórców, by pokazali, że komponent jest użyteczny dla wielu zespołów, nie jest duplikatem i był testowany z reprezentatywnymi użytkownikami; traktuj to jako praktyczny model, a nie uniwersalną zasadę.
Zapisz problem, opcje, decyzję, właściciela, dotkniętą wersję i datę przeglądu tam, gdzie zespoły mogą to wyszukać.
Oznaczaj zmiany jako poprawkę (patch), dodatkowe (additive) lub łamiące zgodność (breaking), żeby konsumenci wiedzieli, kiedy potrzebna jest migracja i okres kompatybilny.
Zapobiegaj regresjom przed wydaniem
Powiąż system z procesem dostarczania. Wymagaj, by zmiana wskazywała dotknięte tokeny i komponenty, a następnie testuj dotknięte stany i reprezentatywne strony. Porównania wizualne, testy interakcji, przegląd treści i kontrole dostępności wykrywają różne rodzaje defektów. Priorytetyzuj podróże o wysokich konsekwencjach oraz te o dużym ruchu; dostęp do konta i formularze kontaktowe mogą być istotne nawet przy skromnym ruchu. To wspiera pracę Status Is UP nad proaktywną optymalizacją dostępności i remediacją przez zawężenie zakresu defektu i ułatwienie weryfikacji zatwierdzonej poprawki. Nie jest to monitorowanie przestojów ani substytut planu reagowania na incydenty.
Przechowuj wersję komponentu, wyniki testów, ustalenia, zatwierdzenia i wszelkie zaakceptowane ryzyko razem z rekordem wydania.
Zachowaj poprzednią stabilną wersję i przetestuj pisemne kroki przywrócenia i weryfikacji podczas okien konserwacyjnych o niskim ryzyku.