Adaptacja i rozwój Design Systemu
Dla aplikacji WMS na urządzenia mobilne z Androidem
Kontekst projektu
Organizacja z branży technologiczno-handlowej wdrażała system WMS (Warehouse Management System) do obsługi paczek i przesyłek za pomocą urządzeń skanujących (Android, ekran 4-6”).
Aplikacja miała wspierać użytkowników w:
- przyjmowaniu towaru,
- kompletacji,
- etykietowaniu,
- śledzeniu przesyłek w czasie rzeczywistym,
- oraz relokacji pomiędzy magazynami
Problem
Zespół produktowy otrzymał otwartoźródłowy Design System (bazujący na Material Design), ale był on:
- nieskalowalny,
- niedostosowany do urządzeń przemysłowych,
- pozbawiony systemu tokenów, styli i dokumentacji.
Wyzwania
- Brak hierarchii zmiennych i stylów (wszystko lokalne, statyczne wartości)
- Brak spójności wizualnej między ekranami
- Design System nie wspierał projektów mobilnych w środowisku przemysłowym
- Zespół developerski miał trudności z implementacją – brak dokumentacji, namingów, opisów stanu komponentów
- Problemy z accessibility: niski kontrast, małe strefy dotyku
Zakres mojej odpowiedzialności
- Przeprojektowanie struktur tokenów
- Implementacja systemu Figma Variables + semantyczna siatka tokenów
- Refaktoryzacja i dokumentacja komponentów
- Przygotowanie strategii wersjonowania i branchingów
- Współpraca z devami: CI/CD tokenów, dokumentacja
- Audyt i wdrożenie zasad accessibility (WCAG 2.2 AA)
Process
1. Audyt otwartego Design Systemu
Na wstępnym etapie przeprowadziłem kompleksowy audyt istniejących zasobów Figma, które miały stanowić punkt wyjścia do rozwoju aplikacji mobilnej WMS. Design System, z którego korzystał zespół, był open-source’owy, lecz jego implementacja została przeprowadzona niezgodnie z dobrymi praktykami projektowania systemowego:
- Brak komponentów:
Elementy UI, takie jak przyciski czy inputy, były rozrysowane ręcznie jako ramki (frames) – bez komponentów głównych, bez wariantów, bez struktur umożliwiających reużywalność i aktualizację. - Brak wariantów i properties:
Różne stany komponentów (np. Button Primary, Button Hover, Button Disabled) były tworzone jako osobne obiekty graficzne, bez zależności, co uniemożliwiało skalowalność i szybką modyfikację.
Niespójne style i brak semantyki:
Zidentyfikowałem ponad 150 stylów kolorystycznych, z których wiele miało nazwy typu Sky_blue_75, Grayish-Text, Dark-hover-line, co nie odzwierciedlało ich funkcji w UI. Style nie były mapowane do żadnych tokenów, przez co zespół tracił kontekst i kontrolę nad użyciem koloru w komponentach.
2. Refaktoryzacja struktury i system tokenów
Po przeprowadzeniu audytu zdecydowałem się na pełną refaktoryzację stylów w oparciu o system tokenów zdefiniowany w Figma Variables, zgodnie z najlepszymi praktykami projektowania skalowalnych interfejsów
Zamiast korzystać z nieczytelnych, statycznych stylów typu Sky_blue_75 czy gray-dark-v2, zaprojektowałem dwuwarstwową strukturę tokenów:
Primitive – surowe wartości (np. #507CFF, 16px, 4)
Semantic – znaczeniowe odniesienia, np.:
color.text.primary
spacing.md
radius.input
font-size.body
Podział ten umożliwia zespołowi zmianę wartości w jednym miejscu (primitive), bez naruszania semantyki komponentów w całym systemie.
Zakres tokenów w systemie
Wdrożony system obejmuje:
Spacing: spacing.xs, sm, md, lg, xl
Radius: radius.sm, md, lg, input, button
Typography: font-size.sm, md, lg, line-height.md, font-weight.bold
Sizing: button-height.sm, input-height, icon-md, tap-target
Color Tokens (przygotowane do implementacji później):
color.brand.primary, color.text.primary, color.background.default, z trybami: Light, Light-HC, Dark, Dark-HC
Każdy token został nadany w sposób semantyczny i funkcjonalny, co pozwoliło znacząco zredukować chaos w systemie.
3. Stworzenie biblioteki komponentów mobilnych (Android)
- Komponenty zdefiniowane w 3 rozmiarach (S/M/L)
- Uwzględniono minimalne targety dotyku, kontrast, focus state
- Nazewnictwo zgodne z tokenami i warstwą semantyczną
4. Branching i wersjonowanie
- Każda zmiana DS przechodziła przez branch w Figma + review + changelog
- Utworzono reguły governance:
- feature/new-input, fix/color-contrast, refactor/list-token-structure
5. Dokumentacja i handoff
- Stworzyłem szablon dokumentacyjny dla każdego komponentu:
- Zastosowanie, warianty, tokeny, a11y
- Dokumentacja publikowana w wewnętrznym systemie u klienta + linki do komponentów Figma
6. Accessibility (a11y)
- Wdrożono kontrasty WCAG 2.2 AA
- Zwiększono strefy dotyku do min. 48x48px
- Dodano opisy: aria-label, aria-live dla dynamicznych stanów
- Zbudowano checklistę a11y dla QA i devów
Efekty współpracy z devami
- Handoff dzięki tokenom + JSON był błyskawiczny (zamiast .PDFów i ręcznych opisów)
- Devowie zaoszczędzili średnio 2,3h na wdrożeniu każdego komponentu
- Design System został podpięty do CI/CD → każda zmiana tokenów generowała pull request z nowym buildem
- Dokumentacja była ustandaryzowana i dostępna w jednym miejscu (+ README)
"Intuicyjny produkt to podstawa sukcesu w dzisiejszym cyfrowym świecie."
Zaprojektuję dla Ciebie UX, który nie tylko będzie przyjemny dla Twoich klientów,
ale przede wszystkim poprawi sprzedaż Twojej firmy.
Zaprojektuję dla Ciebie UX, który nie tylko będzie przyjemny dla Twoich klientów, ale przede wszystkim poprawi sprzedaż Twojej firmy.