Shadcn/ui nie jest gotową biblioteką komponentów do Figmy. To zestaw komponentów dla Reacta, oparty na Tailwind CSS, który dodajesz do własnego projektu i możesz modyfikować w kodzie. W Figmie pracujesz więc z osobnym UI Kitem, najczęściej przygotowanym przez społeczność, a następnie mapujesz jego style i komponenty na rozwiązania używane w aplikacji.

Czym jest shadcn/ui w kontekście projektowania?

shadcn/ui działa w modelu code-first. Zamiast instalować zamkniętą bibliotekę komponentów, kopiujesz wybrane komponenty do własnego projektu React i dostosowujesz je do potrzeb produktu. Ich wygląd i zachowanie opierają się między innymi na Tailwind CSS, zmiennych CSS oraz elementach takich jak warianty komponentów.

To ważne rozróżnienie, ponieważ nie istnieje jeden oficjalny plik .fig, który byłby bezpośrednim odpowiednikiem całego shadcn/ui. W Figma Community znajdziesz zestawy inspirowane tym systemem, ale są to zasoby społecznościowe. Mogą różnić się zakresem, jakością i aktualnością względem bieżącej wersji komponentów w kodzie.

Przeczytaj też: Figma Dev Mode – czym jest i jak z niego korzystać?

Jak wdrożyć shadcn/ui do workflow w Figmie?

Najlepiej potraktować plik Figmy jako wizualną warstwę tego samego systemu, który developer rozwija w kodzie. Samo skopiowanie UI kitu nie wystarczy. Trzeba jeszcze ustalić wspólne nazwy, wartości i zasady modyfikowania komponentów.

Workflow może wyglądać tak:

  1. Wybierz UI Kit – znajdź w Figma Community zestaw odwzorowujący komponenty shadcn/ui i sprawdź, kiedy był aktualizowany. Zwróć uwagę na obecność wariantów, stanów, trybu jasnego i ciemnego oraz komponentów opartych na Auto Layout.
  2. Skonfiguruj zmienne – utwórz w Figmie Variables dla kolorów, typografii, promieni zaokrągleń i odstępów. Nazwy powinny odpowiadać tokenom używanym w projekcie, na przykład primary, primary-foreground czy muted.
  3. Zmapuj wartości z Tailwindem – porównaj zmienne Figmy z konfiguracją projektu i zmiennymi CSS. Dzięki temu designer nie projektuje na podstawie wartości, których developer nie ma w kodzie.
  4. Rozbuduj komponenty o realne stany – dodaj warianty takie jak disabled, loading, error, focus i hover. Komponent w Figmie powinien odzwierciedlać zachowanie interfejsu, a nie tylko jego wygląd statyczny.

Największą rolę odgrywają tu Design Tokens. Są wspólnym językiem dla Figmy i kodu. Kolor zdefiniowany jako token może mieć swoją reprezentację w Figma Variables, zmiennej CSS i konfiguracji Tailwind CSS. Nie oznacza to automatycznej synchronizacji, ale znacznie ogranicza rozbieżności podczas handoffu.

Zobacz także: Figma Jam – czym jest i jak korzystać z tablicy?

Cecha Design-first Code-first (shadcn/ui)
Źródło prawdy Biblioteka komponentów w Figmie Komponenty i tokeny w repozytorium kodu
Elastyczność Szybkie prototypowanie w ramach gotowego UI kitu Swobodne modyfikowanie komponentów i ich zachowania
Handoff Developer odtwarza rozwiązanie na podstawie projektu Projekt pokazuje strukturę, warianty i wartości używane przez kod

Jak utrzymać spójność między projektem a kodem?

Spójność nie wynika z używania identycznego pliku w Figmie i aplikacji. Powstaje wtedy, gdy oba środowiska korzystają z tych samych reguł. Designer i developer powinni uzgodnić nazwy tokenów, sposób budowania wariantów oraz granice odpowiedzialności komponentów.

W codziennej pracy pomagają następujące zasady:

  • Wspólne nazewnictwo – stosuj te same nazwy w Figma Variables, dokumentacji i kodzie, na przykład primary-foreground, border albo radius-md.
  • Auto Layout jako model elastyczności – buduj komponenty w Figmie tak, aby ich rozmiar wynikał z zawartości. To lepiej odpowiada układom tworzonym z użyciem Flexboxa i Gridu niż ręczne ustawianie pozycji.
  • Warianty zgodne z API komponentu – jeśli komponent w kodzie ma wariant variant i rozmiar size, podobną strukturę warto zachować w Figma Component Properties.
  • Regularne uzgadnianie zmian – każda zmiana tokenu, wariantu lub zachowania komponentu powinna trafić zarówno do dokumentacji, jak i do odpowiedniego środowiska pracy.

Figma pokazuje, jak komponent ma wyglądać i zachowywać się w określonym scenariuszu. Ostatecznym źródłem prawdy dla działania interfejsu pozostaje kod.

Sprawdź także: Tailwind Figma – jak wykorzystać te narzędzia w projektowaniu?

Nie warto też traktować UI Kitu jako nienaruszalnego wzorca. Jeśli produkt wymaga innych stanów, dodatkowych właściwości albo własnych zasad dostępności, lepiej rozbudować system świadomie niż dopasowywać projekt do ograniczeń pobranego pliku.

Jakie narzędzia ułatwiają pracę z shadcn w Figmie?

Najczęściej przydają się zasoby, które skracają etap przygotowania wizualnej biblioteki, ale wymagają weryfikacji przed użyciem:

  • UI Kity inspirowane shadcn/ui dostępne w Figma Community
  • Figma Variables do przechowywania kolorów, typografii i innych tokenów
  • Storybook lub podobna dokumentacja do prezentowania komponentów w kodzie
  • v0 i Lovable jako narzędzia AI wspierające tworzenie interfejsów na bazie komponentów

Zasoby społecznościowe mogą być dobrym punktem startowym, ale nie gwarantują zgodności z aktualnym kodem. Przy małym projekcie wystarczy ręczne mapowanie tokenów i regularny handoff. Przy większym produkcie opłaca się stworzyć własny UI Kit oraz dokumentację, które będą rozwijane razem z komponentami shadcn/ui.