Kiedy warto użyć narzędzia do automatycznej konwersji zamiast ręcznego wdrażania?
Narzędzia do automatycznej konwersji przydają się przy szybkim prototypowaniu lub generowaniu szkieletu struktury, który inżynier następnie przepisuje. Rzadko nadają się do kodu produkcyjnego, bo nie potrafią myśleć o wielokrotnym użyciu, responsywności ani stanach interaktywnych.
Ręczne wdrażanie jest właściwym wyborem zawsze, gdy wynik będzie utrzymywany, rozwijany lub używany w więcej niż jednym kontekście, a to opis niemal każdej produkcyjnej bazy kodu.
Ile trwa typowe wdrożenie Figma do React?
Czas trwania zależy od rozmiaru design systemu i złożoności komponentów. Skupione wdrożenie obejmujące podstawowy zestaw UI primitives trwa zazwyczaj od czterech do ośmiu tygodni. Pełne wdrożenie design systemu z dokumentacją i QA zajmuje dłużej, precyzyjnie określamy zakres po wstępnym audycie.
Planujemy dostarczanie etapami, tak by Twój zespół otrzymywał działające, przetestowane komponenty stopniowo, zamiast czekać na jedno duże wydanie.
Jak zarządzacie design systemem po zbudowaniu komponentów?
Konfigurujemy pipeline tokenów i dokumentację Storybook, które sprawiają, że design system jest samorządny przy rutynowych zmianach. Aktualizacje koloru, odstępów i typografii przepływają ze zmiennych Figma przez pipeline tokenów do CSS custom properties bez konieczności modyfikowania kodu każdego komponentu.
W przypadku zmian strukturalnych, nowych wariantów, nowych komponentów, modyfikacji układu, rekomendujemy lekki proces governance: wyznaczonego właściciela design systemu po każdej stronie, który weryfikuje zmiany w Figmie zanim trafią do kolejki wdrożeniowej.
Co się dzieje, gdy projekt Figma zmienia się po wdrożeniu?
Zmiany w designie to normalny element każdego cyklu życia produktu. Ponieważ wdrażamy komponenty z typowanymi propsami i pipeline'em tokenów, wiele zmian wizualnych, kolor, odstępy, typografia, propaguje się automatycznie przez warstwę tokenów bez ingerencji w kod komponentów.
Zmiany strukturalne, takie jak nowe warianty czy modyfikacje układu, wymagają aktualizacji kodu. Nasza dokumentacja przekazania sprawia, że Twój wewnętrzny zespół może wprowadzać te zmiany sprawnie, i pozostajemy do dyspozycji w ramach wsparcia, jeśli wolisz, żebyśmy zarządzali nimi bezpośrednio.
Czy pracujecie z istniejącymi bazami kodu React, czy tylko z projektami greenfield?
Pracujemy z oboma. W przypadku istniejących baz kodu audyt design systemu obejmuje przegląd obecnej architektury komponentów, nowe komponenty integrują się z Twoimi wzorcami zamiast wprowadzać równoległy system.
Szczególną uwagę poświęcamy konfliktom architektury CSS, kolizjom nazw i wpływowi na bundle, to praktyczne punkty tarcia, które pojawiają się przy dodawaniu nowej biblioteki komponentów do dojrzałej bazy kodu.
Jak zapewniacie dostępność budowanych komponentów?
Dostępność uwzględniamy na poziomie komponentu podczas budowania, nie audytujemy jej retrospektywnie. Piszemy semantyczny HTML, stosujemy role i atrybuty ARIA tam, gdzie natywna semantyka jest niewystarczająca, testujemy nawigację klawiaturą dla każdego komponentu interaktywnego i weryfikujemy kontrast kolorów względem WCAG AA jako minimum.
Komponenty niespełniające kryteriów dostępności nie przechodzą naszej bramki QA, Twój zespół przejmuje bibliotekę spełniającą wymogi zgodności już od pierwszego wydania.