Design system w nowej wersji składa się z trzech głównych obszarów: Base, Back i Front, opartych na metodologii Atomic Design oraz zdefiniowanych variables (dla kolorów, typografii, spacingu, komponentów interaktywnych) z uwzględnieniem breakpointów: desktop, tablet, mobile.
Pierwotna wersja zestawu komponentów została kompleksowo przebudowana i oparta o system zmiennych Variables zapewniając znaczącą kompresję ilości wariantów komponentów oraz umożliwiając stosowanie responsywności w projektach. Wydajność użycia dzięki powyższym znacznie wzrosła, struktura oparta o Atomic Design została uproszczona.
Samodzielne obszary obiektowe Back oraz Front służą budowaniu responsywnych widoków końcowych oraz generowaniu klikalnych prototypów bezpośrednio z opcji konfiguracji komponentów bazowych.
Całość jest spięta w globalne komponenty zmiennymi Spacing oraz Gap, które definiują odgórnie zasady konstrukcji sekcji Body oraz Header / Footer. Gwarantuje to spójność oraz powtarzalność konstrukcji widoków niezależnie od obszaru.
W sekcji body widnieją sloty jako placeholdery treści, podmieniane na docelowe obiekty z biblioteki komponentów Base bądź kontekstowych Back/Front w zależności od obszaru.
Integralną częścią Design Systemu jest zestaw zmiennych (Variables) opisany w trzech trybach (Dekstop, Tablet, Mobile) opisujący aspekty wizualne oraz interakcyjne komponentów we wskazanych trzech obszarach. Zastosowanie zmiennych do opisu formy oraz zachowania komponentów pozwoliło na znaczącą kompresję wariantów oraz przede wszystkim uruchomienie trybów responsywnych dla projektów. Stanowi to również punkt wyjścia do pracy deweloperskiej nad zestawami arkuszy styli oraz organizacji zmiennych w spójną, logiczną strukturę.
Odrębnym aspektem sa wytyczne WCAG, które wynikają z raportów przeprowadzonych dla apteline.pl oraz swiatzdrowia.pl. Przebudowa gwarantowała spełnienie wytycznych wizualnych przed audytem, dostarczył on informacji o interkacjach oraz parametrach Aria jak i metodach implementacji deweloperskich.
01 Base
Base to fundament całego systemu. Obejmuje trzy poziomy atomic design:
Atoms
- Typografia: nagłówki (H1–H6), teksty akapitowe, etykiety, linki.
- Kolory i style: paleta brandowa, warianty stanów (hover, disabled, focus).
- Ikony i proste elementy UI: przyciski podstawowe (primary, secondary, ghost), checkboxy, radio, pola formularzy.
- Grid i spacing: podstawowe zasady responsywności (desktop, tablet, mobile).
Przypadki użycia: te elementy są niezależne i wykorzystywane do budowy bardziej złożonych komponentów w Back i Front.
Molecules
- Form controls: pola wyszukiwania, input z labelką i walidacją, select, textarea.
- Button groups: zestawy przycisków (np. CTA + secondary).
- Badge i tagi: informacyjne, statusowe, z ikonami.
- Navigation items: elementy menu, breadcrumbs.
Przypadki użycia: tworzenie powtarzalnych fragmentów interfejsu, np. sekcje formularzy, listy z filtrami.
Organisms
- Header / Navbar: logo, nawigacja, ikony użytkownika/koszyka.
- Cardy: z obrazem, opisem, CTA.
- Tabele: z sortowaniem, paginacją.
- Form sections: wielopolowe formularze, układy gridowe.
- Modal i Drawer: złożone interaktywne okna.
Przypadki użycia: kompletne sekcje, które mogą być stosowane zarówno w Back, jak i Front.
02 Back
Komponenty Back bazują na Base i są zoptymalizowane pod użytkownika zalogowanego, gdzie kluczowe są funkcje transakcyjne i zarządzanie danymi.
Produktywność i niezawodność w pracy na danych; złożone formularze i tabele; kontekst „Konto pacjenta” itp.
Typy komponentów Back (zbudowane na Base):
- Obszar Content agregujący: AppShell (Sidebar + TopBar + Content), Layout z breadcrumbs; kontener Body, Footer
- Nawigacja aplikacyjna: Sidebar (sekcje, akordeony), Breadcrumbs, Tabs do przełączania widoków edycji.
- Formularze złożone: wieloetapowe (wizard), walidacja inline, pola zależne, inputy z maskami (PESEL, daty), selecty z wyszukiwaniem, uploady dokumentów.
- Statusy i notyfikacje: Tag/Badge statusowe (np. „wystawiona recepta”, „w trakcie”), Toastery i Alerty; paski postępu (progress-bar).
- Wzorce bezpieczeństwa: widoki błędów, stany pustki, potwierdzenia destrukcji, timeouts.
Przypadki użycia: backoffice typu "Konto pacjenta", gdzie użytkownik zarządza swoim profilem, danymi medycznymi, receptami, rezerwuje wizyty.
03 Front
Komponenty Front również bazują na Base, ale są projektowane z myślą o użytkowniku niezalogowanym i aspektach sprzedażowo-marketingowych z niskim zakresem pracy na danych wprowadzanych do systemu.
Rozwijany system komponentów frontowych bazuje na dotychczasowych formach wizualnych stosowanych na swiatzdrowia.pl oraz apteline.pl.
Typowe komponenty Front:
- Landing page layout: hero section z nagłówkiem, CTA i grafiką.
- Product listing: siatka kart produktowych (np. leki, suplementy).
- Content sections: blog, artykuły, FAQ.
- Promocje i bannery: dynamiczne bloki reklamowe (zewnętrzne strefy bannerowe)
- Formularze lead generation: newsletter, kontakt.
- Stopki i nagłówki: zoptymalizowane pod SEO i UX marketingowy.
Przypadki użycia: strony przed zalogowaniem, np. sprzedaż leków online, kampanie promocyjne, landing page aptek i portali zdrowotnych.
04 Zmienne
Zestaw zmiennych został przygotowany obiektowo w grupach zależnych od siebie i budujących system wizualny w płaszczyznach:
- warstwa wizualna (kolory, kroje fontów, zaokrąglenia etc)
- warstwa opisu komponentów oraz ich wariantów (kolory, style fontów, spacingi, gapy, typy oraz stany komponentów)
- warstwa struktury kontenerowej agregującej komponenty (spacingi, gapy)
- warstwa responsywności (wprowadzone wartości w trzech trybach breakpoint - desktop/tablet/mobile)
Grupy zmiennych:
- Primitives – surowe wartości wykorzystywane jako parametry do budowy docelowych zmiennych wykorzystywanych w komponentach (kolory, spacing, typografia).
- Tokens – rola w UI (Primary, Text, Surface…), które aliasują prymitywy.
- Responsive – trzy zestawy wartości (Desktop/Tablet/Mobile) jako zmienne budujące w sposób automatyczny widoki w danym breakpoincie.
Wynikowo każdy komponent ma stałą strukturę w domyślnym wariancie różniącym się tokenami przypiętymi w danym trybie.
Pozwala to na znaczącą kompresję ilości wariantów komponentów (rozmiary, stany) oraz automatyzację generowania widoków w różnych breakpointach.
Klasyczne podejście:
rozmiar × stan × kolorystyka × device = n/wariantów
Obecne podejście:
bazowe komponenty + sloty na tokeny = wariant
Opisane breakpointu gwarantują trzy gotowe „preset-y”:
- te same nazwy tokenów, różne wartości per tryb (np. font-size, spacing, szerokości),
- zmiana tryb powoduje adaprację interfejsu do właściwych parametrów i formy wizualnej
- brak multiplikowania wariantów p/komponent typu -md, -xl etc.
Zalety obiektowej struktury zmiennych opartej o tryby:
- skomporesowny design system – krótsza lista komponentów, łatwiejsze utrzymanie
- szybkie iteracje – zmiana wartości opisujących obszar primitives bądź tokens dystrybuuje je automatycznie na wskazane obszary podczas aktualizacji repozytorium
- spójność i skalowalność – identyczne nazewnictwo i role (dev), jednolita struktura kontenerów Header, Body, Footer i pochodnych, niezależnie od konstrukcji docelowej projektu i breakpointa
- lepsza dostępność (WCAG) – kontrola kontrastu i typografii na poziomie tokenów, zwinne zmiane w przypadku aktualizacji wytycznych wynikających z kolejnych wersji dokumentacji
- gotowość na theming – motywy to kolejne zestawy wartości w Tokens/Responsive (inne brandy, tryby jasne/ciemne)
Statystyki ilości obiektów:
Progres w zakresie ilości wariantów:
05 Użycie
Całość systemu wizualnego pozwala na efektywną realizację zadań w oparciu o analityczne podejście do zakresu prac, kompleksowy opis zadań projektowych oraz stanowi odpowiedź na potrzeby sprawnego realizowania prototypów klikalnych zwizualizowanych na różnych urządzeniach. Jest integralną częścią zwinnego procesu wytwórczego oprogramowania.
Kontrola wytycznych WCAG na globalnym poziomie zmiennych pozwala na sprawną adaptację do nowych wymagań.
Budowa projektów opiera się również na komponowaniu zestawu komponentów lokalnych p/zadanie w zakresie kontekstów w nim występujących jak typy wizyt, rodzaje płatności czy warianty formularzy danych. Gwarantuje to replikowalność oraz zwinność zmian na wielu ekranach jednocześnie.
Efekty biznesowe:
- krótszy time-to-market dzięki mniejszemu długowi w wariantach
- niższe koszty utrzymania design systemu
- łatwiejsze testy A/B i redesigny (zmiana konfiguracji zmiennych komponentów)
Obszary w ramach których stosowany jest DS Neuca:
- apteline.pl (nowe funkcjonalności jak kalkulatory BMI, pytanie do farmaceuty etc oraz założenia WCAG)
- swiatzdrowia.pl (przyrostowo wraz z założeniami WCAG)
- moj.swiatzdrowia.pl (w ramach v2 implementowana w całości w nowym obszarze projektowym Konto pacjenta)
06 Przykłady
Proces wdrażania nowego systemu wizualnego Neuca przebiega przyrostowo wraz nowymi funkcjonalnościmi oraz implementacją wytycznych WCAG. Implementacja DS Neuca w nowej wersji skróciła proces przekazywania i późniejszej analizy pod kątem implementacji deweloperskiej oraz przekazywania prototypów w zakresIe decyzji projektowych PO przy założeniu klarownego procesu generowania wymagań.
Abonamenty - grafik
Realizacja zadania związanego z wizualizacją procesu wyboru terminu wizyty płatnej z możliwością wyboru dnia oraz lekarza w formie klikalnego prototypu oraz w dwoch wariantach breakpoint - desktop oraz mobile.
Abonamenty - zakres pakietów
Realizacja nowego wymagania wizualizacji listy pakietów dostepnych dla pacjenta. Zakres projektu wygenerował potrzebę aktualizacji dostępnych komponentów w zakresie obszaru Base. Prototyp klikalny w wariancie desktop oraz mobile.
Kalkulator BMI
Druga wersja systemu bookowania wizyt lekarskich oparta o pierwotne założenie oraz umożliwiające zamawianie wizyt NFZ/Płatncyh. Proces projektowy rozpoczął etap budownia komponentów frontowych DS.
Kalkulator BMI
Frontowy projekt kalkulatora wagi opartego o założenia nowego DS i rozbudowanego o występujące w nim elementy. Przyrostowy proces wytwarzania składowych DS stanowi rozwój obszaru Front.