Systemy projektowe i ich dokumentacja

1) Co to jest system projektowania i dlaczego jest potrzebny

System projektowy jest jednym źródłem prawdy dla interfejsu: zestaw żetonów, komponentów, praktyk i dokumentacji, który zapewnia przewidywalność UX, prędkość rozwoju i skalowalność.

• Spójność warstwy wizualnej i behawioralnej we wszystkich produktach.
• Prędkość: ponowne użycie komponentów, mniejsze koszty przeglądu.
• Jakość: ogólne wzory A11y, lokalizacja, testy, standardy zawartości.
• Możliwość zarządzania: jasna odpowiedzialność, wydania, plan działania.

2) Architektura systemu projektowego (warstwy)

1. Żetony projektowe (fundamenty): kolory, typografia, wymiary, promienie, cienie, tiret, stany, a także tokeny semantyczne ('kolor. powierzchnia. ostrzeżenie „,” przestrzeń. xs').
2. Elementy interfejsu użytkownika: przyciski, pola wejściowe, okna modalne, krople, tabele, toasty, banery, wpisy, puste stany, szkielety.
3. Wzory i kompozycje: formularze KYC, przepływ płatności, zero wyników, mistrzowie kroków, karty treści.
4. Przewodnik po treści (mikrokopia): ton, słownik terminów, wzorce błędów/sukcesów, push/banery.
5. Infrastruktura: przewodnik po A11y, testach, lokalizacji, wersjach, uczestnikach (wnoszących wkład).

3) Żetony projektowe: zasady

Semantyka> „surowy” styl. Użyj 'koloru. tekst. zmiotł "zamiast" # 6B7280 ".
Tematyka i platformy. Żetony źródłowe → mapowania platformy (Web, iOS, Android, e-mail).
Jasny/ciemny motyw i kontrast WCAG na poziomie żetonu.
Skale globalne i kontekstowe: "przestrzeń. 2 ',' promień. md', "elewacja. 1 „,” nieprzezroczystość. wyłączony ".
Token versioning: zmiany - poprzez politykę deprecacji i noty migracyjne.

4) Elementy: wymagania i skład strony w dokumentacji

• Opis i cel. Kiedy używać/nie używać.
• Warianty/stany. Wymiary, typy (podstawowe/wtórne/duchy), wyłączone, ładowanie, niszczące.
• Dostępność. Rola, nawigacja klawiatura, 'aria-', kontrast, pierścienie ostrości.
• Tekst i przykłady mikrokopii. Ważne etykiety/znaczniki, błędy, pomoc.
• Przykłady kodów. Minimalne API, kontrolowane/niekontrolowane.
• Integracja z formularzami i i18n. Przypadki długich linii, numery/waluty/daty.
• Anty-przykłady. Błędne wzorce użytkowania.
• Matryca testowa. Migawki wizualne, jednostka/interakcja, czytniki ekranu.

5) Wzory składu (Przepisy)

Formularze rejestracyjne/CUS: kreator krok po kroku, postęp, inline + podsumowanie walidacji, wzory błędów.
Przepływ płatności: wybór metody, opłaty, daty, reguła tej samej metody, potwierdzenie i status.
Puste stany: kontekst + wartość + CTA, zero wyników wyszukiwania.
Komunikaty o sukcesie/błędzie: hierarchia statusu, żetony wizualne, tosty/banery/modale.
Nawigacja i filtry: wyszukiwanie globalne, szybkie ustawienia wstępne, tagi.
Strony wzoru powinny pokazywać skład komponentów gotowych do kopiowania, z mikrokopią i notatkami A11y.

6) Przewodnik po treści (głos i ton, mikrokopia)

Głos: profesjonalny, jasny; ton zależy od kontekstu (wejście na pokład, płatność, bezpieczeństwo).
Jednolity słownik terminów: płatności, bonusy, limity, KYC - jedna wartość na produkt.
Szablony: CTA, błędy, ostrzeżenia, sukcesy, puste stany, powiadomienia.
Lokalizacja-pierwszy: zapasy na długość linii, numery/waluty/daty według regionu.
A11y-vocabulary: wyraźne etykiety, aria-opisy, bez dwuznaczności.

7) Dostępność (A11y) jako standard systemu

Kryteria podstawowe: WCAG 2. 1 AA dla kontrastu, skupienie jest zawsze widoczne, nawigacja klawiatura.
Role i atrybuty: składniki opisują „role”, „aria-label”, „aria-describby”, żywe regiony dla tostów/wpisów.
Czytniki na ekranie: przykłady zwrotów, kolejność odczytu, prawidłowe statusy („asertywne/grzeczne”).
Procedury testowe: automatyczne kontrole + ręczne skrypty.

8) Lokalizacja i internacjonalizacja

klucze i18n obok kodu komponentu + opis kontekstu.
Numery/waluty/daty poprzez narzędzia formatowania; nie hardcode tekst w szablonach.
Testy długości: „długi niemiecki”, „wąski mobilny”, warianty RTL.
Ton w językach: mapa dźwiękowa dla kroków krytycznych (płatności/bezpieczeństwo).

9) Dokumentacja: konstrukcja i nawigacja

1. Wprowadzenie: misja, zasady, obszary odpowiedzialności.

2. Żetony: kolory, typografia, siatka, wymiary, cienie, stany, motywy.

3. Komponenty: katalog z filtrami (według roli, platformy, A11y).

4. Wzory: scenariusze (formularze, płatności, puste stany, sukces/błędy).

5. Przewodnik po treści: głos i ton, słownik, szablony mikrokopii.

6. Dostępność: normy, listy kontrolne, skrzynki testowe.

7. Lokalizacja: zasady, przykłady, glosariusze według rynku.

8. Integracja i kod: instalacja, wersje, przykłady, jak migrować.

9. Wkład: procesy przyczyniające się, przegląd projektu, przegląd kodu, definicja wykonanych.

10. Changelog i plan działania: wydania, deprecacje, plan rozwoju, znane kwestie.

10) Zarządzanie i procesy

Role: właściciel systemu (DesignOps/UX Platform), opiekunowie (design/FE), konsultanci (BE, A11y, lokalizacja).
Komisja ds. Zmian: Ocena wniosków, ustalanie priorytetów, pojednanie API/tokenów.
Procesy: RFC dla nowych komponentów, wewnętrzne formularze emisji, SLA dla błędów.

Definicja Wykonanego: projekt (Figma)

11) Wkład: jak dodać/zmienić

Szablon RFC: problem → opcje → wybrana decyzja → A11y → i18n → migracja → ryzyko.
Flow PR: design review → code review → UX copywriter → A11y sprawdź → uwagi do wydania.
Zasady kompatybilności wstecznej: niewielka/łatka dla nieniszczących, poważnych - z deprecacją i automatyczną migracją, tam gdzie to możliwe.

12) Weryfikacja, zwolnienia, migracje

SemVer dla pakietów ('@ company/ds-core', '@ company/ds-forms', '@ company/ds-charts').
Uwagi do wydania: zmiany tokenu, interfejsy API komponentów, zachowanie domyślne, zmiany łamania, przewodniki migracji.
Deprecacje: markupy dokowe, reguły lintera, moduły kodowe do wymiany masy.
Rurociąg tokenów projektowych: pojedyncze źródło (JSON/YAML) → konstrukcje platformy (CSS vars, iOS, Android).

13) Badanie jakości

Testy jednostkowe zachowania i warunków.
Migawki wizualne (regresja tematu/stanu).
testy A11y: automatyczne + ręczne skrypty czytnika ekranu.
E2E przypadki przepływów krytycznych (rejestracja, płatności, KYC).
Budżety PERF: ograniczenia pakietów/renderek i zakazy uzależnień.

14) Metryki dojrzałości systemu projektowego

Adopcja:% ekranów/repozytoriów przy użyciu DS.
Prędkość: Czas od układu do dostawy.
Jakość: wady UI/A11y do 1 zwolnienia.
Spójność: liczba „jednorazowych” komponentów/stylów poza DS.
Docs: zasięg komponentu dokującego, wewnętrzny NPS odbiorców (projektanci/programiści/analitycy).

15) Anty-wzory

Żetony jako paleta bez semantyki („tylko kolor”).
Komponenty bez dokumentacji i bez przykładów skrajnych przypadków.
Ignorowanie A11y (brak ostrości, niski kontrast, brak „arii”).
Łamanie wersji bez deprecjacji i przewodnika migracji.
Ukryta logika w komponentach (reguły biznesowe zamiast zachowania interfejsu użytkownika).
Powielanie komponentów dla wąskich przypadków zamiast rozszerzenia API.

16) Listy kontrolne

• Nazwy semantyczne i cel.
• Kontrast AA w obu tematach.
• Skale i wykorzystanie są udokumentowane.

• Warianty/państwa są uwzględnione.
• A11y-description, „aria-”, focus.
• Przykłady mikrokopii (etykiety, błędy, wskazówki).
• Próbki kodowe i przypadki krawędzi (długie linie, obciążenie, puste).
• Unit/visual/A11y testy są zielone.

• Uwagi do wydania z przykładami przed/po.
• Przewodnik migracji - deprecates.
• Aktualizowane historie/demo, linki w doku.

17) Przykłady przed/po

• Różne przyciski główne: kolory/promienie/indenty nie pasują; różne teksty CTA.

• Pojedynczy 'przycisk' z żetonami: 'size = md', 'variant = primary', 'radius = lg', 'spacing = md', tekst w stylu 'action + object'.

• Wiadomości techniczne, brak linków.

• Komponent '< Error severity = „error”> Nieprawidłowy format daty. Użyj DD. MM. RRRR. '+ auto-focus.

18) Szablon strony składowej (szkielet)

Nazwa: przycisk

Opis: rozpoczyna działanie; 1 główny na ekran.
Opcje: pierwotny, wtórny, duch, destrukcyjny; wymiary sm/md/lg.
Stany: zawisza, ostrość, aktywny, załadunek, wyłączony.
A11y: dostępne z klawiatury; „aria-naciśnięta” do przełączania.

Mikrokopia: "Zapisz zmiany", "Kontynuuj weryfikację. "Unikaj "OK"

Kod (przykład API): „Przycisk {wariant, rozmiar, ikona, ładowanie}”.
Anty-przykłady: podwójny podstawowy na tym samym poziomie hierarchii.
Testy: migawki wizualne, kontrast, pierścień ostrości.

19) Projekt systemu implementacji playbook (rollout)

1. Audyt interfejsu: spis kolorów/typografii/komponentów/wzorów.
2. Żetony MVP i główne komponenty: przycisk, wejście, wybrać, Modal, Alert, EmptyState, Toast.
3. Dokumentacja i książka historyjna: przykłady na żywo, snippety kodowe, przewodniki.
4. Produkt pilotażowy: wymiana widżetów, zbieranie opinii.
5. Przewodnik migracji: moduły kodowe, zasady deprecacji.
6. Rozszerzenie zestawu: tabele, paginacja, fora formularzy, kroki kreatora.
7. Skalowanie: wzorce produktów (płatności, KYC), integracja z analityką i A/B.
8. Wsparcie: kanał pytań, SLA, warsztaty wewnętrzne.

20) Szybkie szablony dokumentacji

• Nazwa: 'kolor. granica. ostrzeżenie "
• Cel: ramki ostrzegawcze i banery Uwaga/Ostrzeżenie
• Kontrast: AA przeciw 'kolor. powierzchnia. niewykonanie zobowiązania "
• Nie: używać dla małych rozmiarów tekstu
• Powiązane: 'kolor. powierzchnia. ostrzeżenie „,” ikona. ostrzeżenie "

Wzór wzoru: pusty stan (noResults)

Cel: Skorygować zapytanie bez odczuwania „złego”

Skład: nagłówek (hurt), tekst (zdanie 1-2), CTA, wtórna CTA, ikona/ilustracja

Mikrokopia: "Nic nie zostało znalezione przez "{query}" Zresetuj filtry lub dopracuj zapytanie"

A11y: 'rola =' status ',' aria-live = 'grzeczny' '

Końcowy arkusz oszustwa

Żetony semantyczne + dyscyplina A11y = podstawa.
Pełne strony składowe: cel, warianty, A11y, mikrokopia, kod, testy.
Wzory = kompozycje komponentów z gotowymi tekstami i zasadami.
Docs - produkt: wersja, wydania, migracje, proces wpłat.
Pomiar dojrzałości: przyjęcie, prędkość, wady, spójność, NPS wewnętrznych poleceń.