Ustal jasne zasady nazewnictwa, wariantów i układu dla komponentów UI wielokrotnego użytku, aby zespoły szybko tworzyły spójne ekrany w edytorze wizualnym.
Edytory wizualne umożliwiają szybkie dostarczanie ekranów. Ta prędkość może jednak ukryć powolny dryf w wyglądzie i zachowaniu UI. Gdy kilka osób buduje równocześnie, drobne decyzje się kumulują: ktoś doda 12px paddingu, inny użyje 16px, a trzeci skopiuje starszy przycisk z innego ekranu.
Zwykle pierwsze symptomy są widoczne wcześnie: niemal identyczne komponenty, odstępy, które różnią się między ekranami, i nieco inne słowa na tę samą akcję (Zapisz, Wyślij, Potwierdź). Stany też często się rozjeżdżają. Jeden formularz pokazuje stan ładowania, inny nie. Komunikaty o błędach są różne, a „szybkie poprawki” pojawiają się na pojedynczych stronach i nigdy nie wracają do wspólnego wzorca.
Tak zaczyna się dług UI. Każda niespójność wydaje się drobna, ale z czasem produkt traci wiarygodność. Spowalnia to też zespoły, bo ludzie tracą czas na szukanie „właściwej” wersji, porównywanie ekranów i poprawianie drobiazgów na końcu przeglądu.
Biblioteka komponentów w edytorze wizualnym to wspólny zestaw klocków (przyciski, pola, karty, nagłówki, stany puste), z którego wszyscy korzystają zamiast odtwarzać elementy. W platformie takiej jak AppMaster zwykle oznacza to tworzenie wielokrotnego użytku elementów wewnątrz narzędzi UI, a następnie uzgodnienie, jak je nazywać, konfigurować i umieszczać, aby ekrany pozostały spójne mimo pracy różnych osób.
Celem nie jest zabicie kreatywności. Chodzi o to, by codzienne elementy były przewidywalne, a wybory — celowe. Cztery dźwignie, które zapobiegają dryfowi, to: jasne nazewnictwo, sensowne warianty, podstawowe zasady układu (odstępy, wyrównanie, siatki) oraz zwyczaje zespołu, które utrzymują bibliotekę w dobrej kondycji w miarę wzrostu aplikacji.
Nie każdy estetyczny element zasługuje na to, by zostać komponentem. Jeśli zrobisz z wszystkiego komponent, ludzie będą tracić czas, przeszukując bibliotekę i zmieniając opcje, które w ogóle nie powinny istnieć.
Dobry komponent wielokrotnego użytku to coś, co spodziewasz się widzieć na wielu ekranach albo coś, co musi wyglądać i zachowywać się za każdym razem tak samo. Pomyśl o wzorcach, które użytkownicy rozpoznają natychmiast: przycisk podstawowy, pole tekstowe z podpowiedzią, karta podglądu rekordu.
Mały zestaw startowy zwykle pokrywa większość ekranów: przyciski, pola, karty, nagłówki stron i kilka typów modalnych okien (potwierdzenie i formularz).
Praktyczna zasada ekstrakcji upraszcza decyzje: jeśli ten sam UI używasz 2–3 razy albo jest kluczowy dla marki i musi być identyczny, wyodrębnij go. Jeśli pojawia się raz, zostaw go lokalnie.
Co powinno pozostać jednorazowe? Wysoce specyficzne układy związane z jednym ekranem, sekcje eksperymentalne, które zmieniasz codziennie, oraz wszystko, co w większości jest treścią. Na przykład jednorazowy baner onboardingu z niestandardowym tekstem i ilustracją rzadko jest wart komponentyzacji.
Trzymaj każdy komponent skupiony. Jeden komponent powinien wykonywać jedno zadanie. „Karta użytkownika”, która jednocześnie zarządza uprawnieniami, statusem rozliczeń i akcjami administracyjnymi, staje się trudna do ponownego użycia. Czystsze podejście to karta wyświetlająca informacje oraz oddzielne przyciski akcji i znaczniki statusu.
Gdy zespół działa szybko, nazwy są pierwszą rzeczą, która się psuje. Ktoś duplikuje „Button2”, inny tworzy „CTA Button”, a trzeci używa „BlueButton”. Tydzień później nikt nie wie, którą wersję ponownie użyć, więc tworzy nową. W ten sposób biblioteka staje się zbiorem niemal duplikatów.
Prosty wzorzec pomaga zachować spójność nawet gdy jesteś zmęczony: Component - Part - State. Większość komponentów nie potrzebuje wszystkich trzech części, ale kolejność pozostaje taka sama.
Używaj słów, które ludzie naprawdę mówią. Jeśli zespół mówi „Karta klienta”, nie nazywaj jej „CRM Tile”. Jeśli produkt nazywa ją „Plan”, nie nazwij jej „SubscriptionBox”. Prosty język wygrywa, bo jest łatwiejszy do wyszukania.
Jedna zasada zapobiega wielu nieporozumieniom: nie mieszaj „jak to wygląda” z „do czego służy” na tym samym poziomie nazwy. Wybierz jedno podejście. Jeśli nazywasz według celu, unikaj słów kolorowych. Jeśli według wyglądu, unikaj znaczeń biznesowych. Nazewnictwo oparte na celu zwykle lepiej się skaluje.
Przykłady, które łatwo zeskanować na liście komponentów:
Ustal formatowanie raz i zapisz: Title Case czy sentence case, spacje wokół myślników i brak skrótów, chyba że są uniwersalne (np. URL). W edytorach wizualnych, gdzie wiele osób wnosi elementy, te drobne ustalenia utrzymują bibliotekę czytelną w miarę jej rozrostu.
Warianty pozwalają na ponowne użycie jednego komponentu w wielu miejscach bez tworzenia kopii. Sztuka polega na tym, by z góry ustalić, które różnice mają znaczenie i zablokować wszystko inne.
Zacznij od kilku wymiarów wariantów, które pokrywają realne potrzeby. Dla wielu komponentów wystarczą trzy: rozmiar (S/M/L), intencja (primary/secondary/danger) i stan (default/hover/active). Jeśli nowa opcja nie mieści się w tych wymiarach, potraktuj ją jako nowy komponent, a nie „jeszcze jeden wariant”.
Wartości domyślne mają większe znaczenie, niż się wydaje. Nowe ekrany powinny wyglądać poprawnie, nawet gdy ktoś przeciągnie komponent i nic w nim nie zmieni. Ustaw bezpieczne wartości domyślne (np. size=M, intent=primary, state=default), żeby prędkość nie zamieniała się w losowe stylowanie.
Dla każdego komponentu z wariantami zapisz i egzekwuj:
Przykład: masz przycisk „Submit” w całym portalu klienta. Jeśli ktoś zrobi „Wide Submit Button”, a inny „Rounded Submit Button”, dryf pojawi się szybko. Dzięki regułom trzymasz jeden komponent Button. Pozwalasz na rozmiar i intencję, zabraniasz niestandardowego paddingu i promienia rogów, i definiujesz „Loading” raz (pokaż spinner, zablokuj kliknięcia), żeby zachowywał się wszędzie tak samo.
Gdy ktoś prosi o „jeszcze jeden styl”, zapytaj, jaki problem użytkownika to rozwiązuje. Jeśli odpowiedź jest niejasna, prawdopodobnie to chaos pod przykrywką potrzeb.
Jeśli zasady układu są nieprecyzyjne, każdy ekran powoli staje się jednorazowy. Najszybszy sposób, by utrzymać spójność komponentów, to uczynienie odstępów i wyrównania nudnymi: kilka dozwolonych opcji, używanych zawsze w ten sam sposób.
Zacznij od skali odstępów i zabroń wszystkiego poza nią. Wybierz mały zestaw (na przykład 4, 8, 12, 16, 24) i traktuj go jak klawiaturę: możesz zagrać wiele utworów, ale tylko na tych klawiszach. Jeśli ktoś potrzebuje „18px”, zwykle oznacza to, że komponent lub siatka są źle dobrane.
Bądź precyzyjny, co oznaczają odstępy:
gap zamiast nakładających się marginów, aby odstępy nie sumowały się przypadkowo.Zasady wyrównania eliminują niekończące się „przesuń trochę”. Prosty domyślny zestaw dobrze działa: wyrównanie tekstu do lewej, równe pionowe linie dla etykiet i pól, oraz spójne umieszczanie akcji głównych (np. prawy dolny róg w modalach i wyrównanie do prawej w stopkach formularzy). Używaj wyrównania do linii bazowej dla wierszy bogatych w tekst. Wyśrodkowanie zostaw dla rzędów z samymi ikonami.
Siatki nie muszą być skomplikowane, ale muszą istnieć. Zdecyduj o kolumnach i odstępach między nimi oraz określ zachowanie na mniejszych ekranach (nawet podstawowe „12 kolumn na desktopie, jedna kolumna na mobile” pomaga). Ustal szerokości kontenerów i breakpointy raz, a potem buduj ekrany w tych ramach.
Typowe pułapki do obserwowania: zagnieżdżone kontenery, które każdy dodają padding, niespójne marginesy stron, mieszanie stałych szerokości z responsywnymi kolumnami oraz „magic numbers”, które naprawiają tylko jeden ekran.
Tokeny stylów to wspólne wybory, których wszyscy używają. Gdy tokeny są jasne, komponenty wielokrotnego użytku pozostają spójne, nawet gdy różni ludzie budują ekrany.
Zacznij od typografii jako jednego źródła prawdy. Wybierz małą skalę rozmiaru czcionek, wagę i wysokość linii, a potem trzymaj się tego. Większość zespołów potrzebuje tylko kilku kroków (np. body, small, caption, title i page heading). Umieść te wybory w jednym miejscu, aby nowy tekst zaczynał od tych samych domyślnych ustawień.
Kolory działają najlepiej, gdy są nazywane przez znaczenie, a nie przez kody farb. Primary sygnalizuje główną akcję. Success oznacza „powodzenie”, a Warning — „sprawdź to”. Unikaj nazw typu blue-500, chyba że zespół już myśli w paletach.
Podstawy dostępności, które zapobiegają problemom później:
Tokeny powinny łączyć się bezpośrednio z wariantami komponentów. Wariant Buttona jak Primary, Secondary czy Danger powinien zmieniać zatwierdzone tokeny (kolor, obramowanie, styl tekstu), a nie wprowadzać jednorazowego stylu.
Trzymaj listę tokenów na tyle krótką, żeby ludzie z niej korzystali. Dobry test: czy ktoś wybierze właściwy token w 5 sekund? Jeśli nie, scal lub usuń.
Prosty zestaw startowy może obejmować typografię (text.body, text.small, text.title), kolory (color.primary, color.success, color.warning, color.danger), odstępy (space.8, space.16, space.24), promienie (radius.sm, radius.md) i fokus (focus.ring).
Biblioteka komponentów to mniej kwestia „perfekcji projektowej”, a więcej usuwania codziennych mikrodecyzji. Gdy wszyscy wybierają te same klocki, ekrany pozostają spójne nawet przy pracy różnych osób.
Zrób audyt tego, co już macie. Wybierz 5–10 prawdziwych ekranów i zanotuj duplikaty, które widzisz często: przyciski, pola tekstowe, nagłówki sekcji, karty i stany puste.
Wybierz małą pierwszą falę do ustandaryzowania. Celuj w top 10 elementów, które pojawiają się wszędzie i powodują najwięcej rozbieżności. Dla wielu zespołów to przyciski, pola, dropdowny, dialogi modalne, nagłówki tabel i karty.
Zapisz zasady zanim zaczniesz budować. Krótko: nazwa komponentu, kiedy go używać, dozwolone warianty i zasady układu wokół niego (odstępy, wyrównanie, szerokość).
Zbuduj raz, potem zastępuj stopniowo. Utwórz nowe komponenty w edytorze wizualnym i zablokuj warianty, na które się umówiliście. Wymieniaj stare kopie ekran po ekranie. Nie próbuj refaktoryzować wszystkiego w jednym sprincie.
Dodaj lekką bramkę przeglądu. Jedna osoba (rotująca co tydzień) sprawdza nowe komponenty i warianty. Celem nie jest karanie, a zapobieganie przypadkowym rozwidleniom.
Wiesz, że to działa, gdy projektant lub PM może powiedzieć: „Użyj standardowej karty z kompaktowym nagłówkiem”, a dwie osoby zbudują ten sam efekt. To korzyść: mniej jednorazowych decyzji, mniej subtelnych niespójności i szybsze tworzenie ekranów.
Trzymaj bibliotekę celowo małą. Jeśli ktoś prosi o nowy wariant, zadaj najpierw jedno pytanie: czy to rzeczywista potrzeba, czy istniejący wariant nie da się użyć z inną treścią?
Większość niespójności nie wynika ze złego gustu. Powstaje, bo kopiowanie jest łatwe, poprawki szybkie, a nikt nie wraca, by to uporządkować. Efekt to zestaw prawie takich samych ekranów, które trudno zaktualizować.
Jedną z typowych pułapek jest tworzenie niemal duplikatów zamiast dodania wariantu. Ktoś potrzebuje „przycisku primary, ale trochę wyższego” i duplikuje komponent. Tydzień później inna osoba duplikuje ten duplikat. Masz trzy przyciski, które wyglądają podobnie, ale zachowują się inaczej, a każda zmiana to polowanie.
Innym spowolnieniem jest komponent zbyt konfigurowalny: mega-komponent z dziesiątkami przełączników. Na początku wydaje się elastyczny, potem staje się nieprzewidywalny. Ludzie przestają mu ufać i tworzą „na to właściwy przypadek” wersje, co podważa sens biblioteki.
Błędy w układzie robią równie dużo szkody. Największy to mieszanie odpowiedzialności: komponent kontroluje własne marginesy zewnętrzne, a ekran też dodaje odstępy. Powstają przypadkowe luki, które różnią się w zależności od strony. Prosta zasada pomaga: komponenty definiują padding wewnętrzny, ekrany kontrolują odstępy między komponentami.
Problemy, które zwykle pojawiają się najpierw: zasady nazewnictwa pękają przy pośpiechu, stany są dodawane późno (loading, empty, error), jednorazowe poprawki stają się trwałe, a różni ludzie rozwiązują ten sam układ różnymi sposobami.
Zanim dodasz cokolwiek nowego, zatrzymaj się na 60 sekund i sprawdź podstawy. Ekran może wyglądać dobrze, a jednocześnie w tajemnicy łamać system — a te małe złamania szybko narastają, gdy kilka osób pracuje równolegle.
Form/Input, Form/Input.HelperText, Table/RowActions). Jeśli nazwa nie pomoże komuś szybko wyszukać i umieścić komponentu, zmień ją teraz.Maya i Leon pracują w zespole wsparcia klienta. Potrzebują dwóch ekranów: listy zgłoszeń (do szybkiego przeglądu) i szczegółów zgłoszenia (do działania). Dzielą pracę i budują w edytorze wizualnym.
Bez zasad każdy robi „kartę” po swojemu. Maya używa białej karty z cienką ramką i cieniem. Leon używa szarej karty bez ramki, ale z dodatkowymi paddingami. Na jednym ekranie jest zaokrąglony przycisk primary, na drugim kwadratowy przycisk i link tekstowy. Status pojawia się jako kropka na jednym ekranie, a jako pigułka na drugim. Na stronie szczegółów pola nie są wyrównane, bo etykiety mają różne szerokości, więc cały formularz wygląda chwiejnie.
Spotkanie przeglądowe zamienia się w debatę o stylach, a prosta aktualizacja (np. dodanie pola „Priorytet”) oznacza poprawki w wielu jednorazowych układach.
Z zasadami zaczynają od wspólnej biblioteki komponentów: TicketCard dla struktury i odstępów, StatusBadge dla stylu statusów i kontrastu oraz ActionBar dla spójnych akcji głównych.
Teraz ekran listy używa kompaktowego wariantu TicketCard do najważniejszych pól i podglądu. Ekran szczegółów używa wariantu szczegółowego dla pełnego opisu, timeline'u i dodatkowych pól. Struktura pozostaje ta sama; wariant kontroluje, co się pojawia.
Najlepsze jest to, czego nie widać: mniej komentarzy w przeglądach, mniej pytań „dlaczego to wygląda inaczej?” i szybsze późniejsze aktualizacje. Gdy zespół zmieni „Closed” na „Resolved” i dostosuje kolor, zmienia StatusBadge raz i oba ekrany aktualizują się razem.
Spójność to nie jednorazowa konfiguracja. Gdy więcej osób buduje ekrany, drobne „tylko na tę stronę” decyzje mnożą się i biblioteka zaczyna dryfować.
Prosty proces zmian trzyma zespół w ruchu bez zamieniania każdej poprawki przycisku w debatę:
Decyzje potrzebują domu. Krótki dokument „UI rules” wystarczy, jeśli zawiera konwencje nazewnictwa, oficjalną listę wariantów (co jest, a czego nie ma) i listę zakazów (np. „Nie twórz drugiego 'Primary Button' z innym paddingiem”).
Zaplanuj comiesięczne porządki. Użyj ich do łączenia duplikatów, usuwania nieużywanych elementów i oznaczania starszych komponentów jako przestarzałe, żeby ludzie przestali pobierać niewłaściwe wersje.
Refaktoryzuj, gdy widzisz ten sam wzorzec dwukrotnie (np. dwa zespoły stworzyły nieco różne stany puste). Pozwól na jednorazowość, gdy coś jest naprawdę unikatowe, pilne i mało prawdopodobne, że się powtórzy.
Jeśli budujesz w AppMaster, praktyczny następny krok to ustandaryzowanie jednego workflow najpierw (np. „Create ticket”), a potem rozszerzanie. Edytory UI ułatwiają udostępnianie tych samych komponentów między ekranami, a appmaster.io może być punkt odniesienia, jeśli zespół chce podejścia no-code, które wspiera pełne aplikacje, a nie tylko układy stron.
What’s the fastest way to start a component library without slowing the team down?Rozpocznij od ustandaryzowania elementów, które pojawiają się prawie na każdym ekranie: przyciski, pola tekstowe, karty, nagłówki i jeden lub dwa typy modalnych okien. Zbuduj je jako komponenty wielokrotnego użytku, ustaw sensowne wartości domyślne, a potem wymieniaj stare kopie ekran po ekranie, zamiast próbować refaktoryzować wszystko naraz.
How do I decide what should be a reusable component and what should stay one-off?Dobrym domyślnym kryterium jest ekstrakcja, gdy ten sam element UI użyto dwa–trzy razy lub gdy musi wyglądać i zachowywać się identycznie za każdym razem (np. akcje główne czy pola formularzy). Jeśli element jest naprawdę jednorazowy, przypisany do jednego ekranu lub zmienia się codziennie, zostaw go lokalnie, aby biblioteka pozostała prosta w użyciu.
What naming convention works best when multiple people build screens?Stosuj prosty i spójny wzorzec nazewnictwa, np. Component - Part - State. Używaj słów, które zespół rzeczywiście stosuje w rozmowach, i unikaj nazw opartych na kolorach, takich jak BlueButton, bo stają się wprowadzające w błąd, gdy styl się zmienia.
How many variants should a component have before it becomes chaos?Ogranicz warianty do różnic, które naprawdę się powtarzają, takich jak rozmiar, intencja (primary/secondary/danger) i stan. Wszystko inne trzymaj zablokowane, żeby ludzie nie „dostrajali” komponentów pod każdy ekran i nie tworzyli dryfu. Jeśli nowa prośba nie pasuje do istniejących wymiarów wariantów, zwykle oznacza to nowy komponent, a nie kolejny przełącznik.
How do we stop spacing from drifting between screens?Wybierz małą skalę odstępów i używaj wyłącznie tych wartości w całej aplikacji, a każda inna liczba powinna sygnalizować, że siatka lub komponent jest nieprawidłowy. Preferuj gap w kontenerach zamiast nakładających się marginów, żeby uniknąć podwójnego odstępu przy zagnieżdżaniach.
Do we really need style tokens, or can we just copy styles as we go?Używaj tokenów nazwanych przez znaczenie, a nie przez kody kolorów, aby zespoły wybierały primary i danger zamiast tworzyć nowe odcienie. Upewnij się, że warianty komponentów mapują się na te tokeny, więc „Primary Button” zawsze pobiera tę samą typografię i kolory.
Which UI states should be standardized across components?Każdy współdzielony komponent interaktywny powinien mieć przynajmniej stan wyłączony (disabled) i ładowania (loading), a tam, gdzie może wystąpić błąd (formularze, akcje sieciowe), dodaj także stan error. Brak ustandaryzowanych stanów sprawia, że ekrany będą niespójne nawet jeśli wyglądają podobnie.
Why are “mega components” a bad idea in a visual builder?Komponenty zbyt rozbudowane w opcje wydają się elastyczne, ale zachowanie staje się nieprzewidywalne i przestaje się im ufać. Trzymaj komponenty skupione na jednym zadaniu i buduj większe układy przez kompozycję mniejszych kawałków, by łatwiej było je ponownie wykorzystywać.
How do we keep the library consistent over time without turning it into bureaucracy?Wprowadź lekką kontrolę: jedna osoba (zmieniająca się co tydzień) sprawdza nowe komponenty i warianty pod kątem nazewnictwa, zasad odstępów i podstawowych wymagań dostępności. Celem nie jest nadzór, a wczesne zapobieganie niezamierzonym forkom.
How would I implement this approach in AppMaster specifically?W AppMaster twórz wielokrotnego użytku elementy UI wewnątrz web i mobile UI builders, a potem ustandaryzuj ich nazwy, konfiguracje i umieszczenie, by inni mogli je pewnie reuse'ować. Dobrym podejściem jest najpierw ustandaryzować jeden workflow (np. „Create ticket”), dopracować komponenty i warianty tam, a potem rozszerzać bibliotekę.
21 sty 2026
8 min
20 sty 20268 min
20 sty 20268 minEksperymentuj z AppMaster z darmowym planem.
Kiedy będziesz gotowy, możesz wybrać odpowiednią subskrypcję.
