Otago Design System
Design system dla ekosystemu ponad 80 aplikacji webowych dla instytucji publicznych w Polsce. Ponad 50 komponentów, cztery tryby dostępności WCAG, jeden wspólny fundament wizualny.
Zobacz interaktywny system ↗
- Title
- Design System OTAGO365
- Industry
- B2B / Sektor publiczny
- Role
- UX Design, projektowanie design systemu, dokumentacja analityczna
- Tools
- Figma
- Date
- 2021–2025
Przegląd
Przez 4 lata projektowałam design system dla ekosystemu ponad 80 aplikacji webowych Asseco Data Systems obsługujących instytucje publiczne w Polsce. Efektem jest biblioteka 50+ komponentów w czterech trybach dostępności WCAG, z dokumentacją analityczną dla każdego z nich.
System nie wygląda jak design system z 2026 roku, bo powstawał między 2021 a 2025 rokiem dla instytucji, w których priorytetem jest dostępność, stabilność i spójność. Zostawiam go tu, bo praca przy rozbudowanym ekosystemie przez kilka lat to inna skala doświadczenia niż pojedyncze wdrożenie.
→Skala
Ponad 80 aplikacji webowych dla urzędów miast i gmin w całej Polsce: finanse publiczne, podatki i opłaty, świadczenia socjalne, kadry, windykacja, ewidencja nieruchomości.
→Problem
Komponenty istniały tylko jako kod Angulara, bez dokumentacji projektowej i reguł zachowania. Każda aplikacja wyglądała i działała inaczej.
→Dostępność
Instytucje publiczne wymagają zgodności z WCAG. Cztery tryby kolorystyczne projektowane od fundamentów, każdy komponent weryfikowany we wszystkich czterech wersjach.
→Wynik
Wspólna biblioteka 50+ komponentów i jeden punkt odniesienia dla całego ekosystemu. Aplikacje stały się jedną, rozpoznawalną rodziną.
Dla kogo
Urzędniczka pracująca w kilku aplikacjach naraz
Urzędniczka
użytkowniczka końcowa
„Mam otwartych kilka aplikacji naraz, a w każdej to samo wygląda i działa inaczej.”
Użytkowniczką systemu jest urzędniczka, która w ciągu dnia pracuje równolegle w kilku aplikacjach OTAGO. W jednej sprawdza dane mieszkańca, w drugiej księguje, w trzeciej prowadzi windykację. Pracuje z dużą ilością danych w listach, formularzach i zestawieniach, które trzeba przeszukać, uzupełnić i porównać. Zna swoją dziedzinę bardzo dobrze, ale nie jest osobą techniczną i oczekuje, że system nie będzie jej przeszkadzać. Część urzędniczek pracujących z systemem słabo widzi, więc kontrast i czytelność to dla nich realna potrzeba, a nie wymóg formalny.
Wcześniej każda z tych aplikacji wyglądała i zachowywała się inaczej. Przełączając się między nimi, użytkowniczka za każdym razem trafiała na inny układ, inne filtrowanie tabeli, inne miejsce przycisków. Mimo że to był jeden system, nie wyglądał jak jedna całość.
Problem
Stan przed
System obsługuje urzędy miast i gmin w całej Polsce: finanse publiczne, podatki i opłaty, świadczenia socjalne, zarządzanie kadrami, windykację i ewidencję nieruchomości. Każdy obszar funkcjonalny ma własną aplikację lub zestaw aplikacji, każda z własną logiką i wymaganiami.
Przed design systemem aplikacje w tym ekosystemie nie tworzyły spójnej całości. Komponenty istniały po stronie deweloperów jako kod Angularowy, bez dokumentacji projektowej i bez reguł zachowania. Każda aplikacja rozwijała się niezależnie, więc zmiana w jednej nie miała przełożenia na pozostałe.
Dla użytkowniczki oznaczało to codzienną niespójność: te same akcje i te same dane wyglądały inaczej w każdej aplikacji. Inne rozmieszczenie przycisków, inny sposób filtrowania list, inne formaty PESEL, kwot czy dat. Każda aplikacja wymagała przyzwyczajania się od nowa, mimo że była częścią jednego systemu.
Do tego dochodziło twarde wymaganie dostępności. Instytucje publiczne muszą spełniać WCAG, a dostępność dodawana na końcu projektu nigdy nie działa tak dobrze jak ta wbudowana w fundamenty.
Cel projektu
Doprowadzić ekosystem do stanu, w którym wszystkie aplikacje wyglądają i zachowują się jak jedna rodzina oparta na tych samych komponentach.
Nie chodziło o redukcję kosztów utrzymania, tylko o spójność widoczną dla użytkowniczki i o zgodność z WCAG na poziomie AA i AAA. Spójność miała być wbudowana w system, a nie pilnowana ręcznie przy każdej aplikacji. Dostępność miała wynikać z fundamentów, a nie być doklejana na końcu.
Kluczowe decyzje projektowe
Co najbardziej wpłynęło na to, jak system działa
Biblioteka liczy ponad 50 komponentów, od prostych przycisków i pól formularzy po złożone tabele, modale i nawigację. Poniżej decyzje, które najbardziej wpłynęły na to, jak system działa w praktyce.
Uporządkowanie kolorów: Primary przypisany do obszaru
Problem
Kolorów w ekosystemie było dużo i nie były uporządkowane. Wiele obszarów funkcjonalnych, w każdym kilka aplikacji, bez jasnej reguły, który kolor należy do czego.
Rozwiązanie
Uporządkowałam istniejącą kolorystykę, przypisując kolor Primary do obszaru funkcjonalnego, a nie do pojedynczej aplikacji, i definiując go jako styl Figma. Aplikacje z jednego obszaru stały się dzięki temu rozpoznawalne i spójne między sobą, a wszystkie razem korzystają z tych samych komponentów. Tożsamość obszaru niesie kolor, a nie osobny zestaw elementów.
Cztery tryby dostępności projektowane od fundamentów
Problem
Część urzędniczek słabo widzi, a instytucje publiczne mają twarde wymagania WCAG. Tryb wysokiego kontrastu doklejony na końcu nie rozwiązuje problemu czytelności.
Rozwiązanie
Cztery tryby kolorystyczne (standard, białe na czarnym, czarne na żółtym, żółte na czarnym) projektowane od fundamentów. Każdy kolor systemu ma zdefiniowany odpowiednik w każdym trybie, więc deweloper nie musi zgadywać, jak przełożyć kolor standardowy na kontrastowy. W trybach kontrastowych świadomie wyłączane jest semantyczne kodowanie kolorem, na przykład czerwień dla wartości ujemnych, ponieważ na czarnym czy żółtym tle traci ono znaczenie. Czytelność była tu ważniejsza niż estetyczne kodowanie.
Wspólne wzorce zachowań i formatów danych
Problem
Te same akcje i te same dane wyglądały inaczej w każdej aplikacji. Inne miejsce przycisków, inny sposób filtrowania, inne formaty PESEL, kwot i dat. Użytkowniczka przy każdym przełączeniu uczyła się systemu od nowa.
Rozwiązanie
Ujednolicone wzorce dla całego ekosystemu. Stałe miejsca akcji, wspólny sposób filtrowania i wyszukiwania, zdefiniowane maski i reguły wyrównania dla każdego typu danych. Kwoty wyrównane do prawej z separatorem tysięcy, identyfikatory o stałej długości, daty w jednym formacie. Raz przyswojony sposób pracy działa w każdej aplikacji.
Dokumentacja analityczna dla każdego komponentu
Problem
Komponenty istniały wcześniej tylko jako kod, bez opisu zachowań i stanów. Część wdrożeń realizował zespół, z którym nie dało się szybko komunikować, więc projekt nie mógł zostawiać miejsca na domysły.
Rozwiązanie
Każdy komponent dostał dokument analityczny z założeniami wizualnymi i funkcjonalnymi: warianty, stany, zachowanie w czterech trybach, reguły interakcji. Skala bywała duża, dokumentacja samej tabeli to dziesiątki stron specyfikacji, ale dzięki temu wdrożenie mogło przebiegać bez dopytywania.
Interaktywny design system
Przejrzyj system na żywo
Poniżej działa interaktywny podgląd systemu: komponenty, kolory obszarów i palety. Klikaj po zakładkach, żeby przejść między widokami.
Wdrożenie i przepływy UX
Nie tylko nowy wygląd, ale i lepszy proces
Wymiana komponentów w istniejących aplikacjach nie polegała tylko na podmianie warstwy wizualnej. Przy każdym wdrożeniu analizowałam przepływy UX wokół nowego komponentu i sprawdzałam, czy logika procesu wokół niego jest jeszcze aktualna. Tam, gdzie wzorzec nawarstwił się przez lata bez rewizji, proponowałam uproszczenie i uzgadniałam je z zespołem.
Ekran pozycji dokumentu księgowego
Przed: ten sam ekran w trzech formach
Ten sam ekran, dodawanie i edycja pozycji dokumentu księgowego, istniał w kilku aplikacjach w różnych formach. Inny układ, inne nazwy, inne rozmieszczenie pól i akcji. Urzędniczka, która przechodziła między aplikacjami, za każdym razem trafiała na inną wersję tej samej czynności.
Rozmowy z urzędniczkami
Zanim powstała nowa wersja, spotkałam się z urzędniczkami, które pracują na tym ekranie codziennie. Na wspólnych spotkaniach w sierpniu 2023 zbierałam konkretne problemy i pytania: jak nazwać ekran, gdzie spodziewają się przycisku, które pola są mylące, czego brakuje. Część zgłoszeń dotyczyła rzeczy, których nie widać z perspektywy projektanta:
- →przycisk „Powrót” miał trafić na belkę akcji, skrajnie z lewej, bo tam go szukały
- →„obiekt księgowy” miał być oznaczony kolorem innym niż czerwony, ponieważ to informacja, a nie błąd
- →pola Pobranie, Windykacja i Grupa miały zostać zgrupowane razem
- →kontrahenta trzeba było móc wpisać z ręki, nie tylko wybrać ze słownika
- →czcionka w tabeli szczegółów była za mała do codziennej pracy
Po: jedna spójna makieta
Powstała jedna makieta: po lewej tabela pozycji, po prawej formularz szczegółów, ze stałym układem akcji i rozdzieleniem trybu podglądu od edycji. Ten sam wzorzec mógł od tej pory działać w innych aplikacjach, w których wcześniej ekran wyglądał inaczej.
To pokazuje, co zmieniało się poza warstwą wizualną: kolejność i grupowanie pól, miejsce akcji, sposób wprowadzania danych, rozróżnienie informacji od błędu. Decyzje brały się z tego, jak urzędniczki faktycznie pracują, a nie z samego odświeżenia wyglądu.
Wydruki i paczki
Do nowego systemu trzeba było przenieść generowanie wydruków dla wybranych pracowników, a przy okazji przebudować cały komponent wydruków, tak żeby obsługiwał różne formaty (PDF, Excel, CSV, XML) i działał spójnie z resztą systemu. Rozwiązanie uzgadniałam z kierowniczką produktu i konsultowałam z programistą znającym starą aplikację.
Przed: proces w trzech krokach
W starym GRIP wydruk był przywiązany do listy pracowników na każdej kartotece, a proces przebiegał w trzech krokach: najpierw przygotowanie zestawienia, potem podgląd, dopiero na końcu zapis. Interfejs był gęsty i rozproszony.
Co zmieniłam
- →Oddzieliłam wydruki od listy pracowników i zebrałam je w jednym, przebudowanym komponencie, z zachowaniem grupowania w paczki.
- →W oknie dodawania wydruku można wskazać wydział przez multiselect albo konkretnych pracowników przez listę z polami wyboru. Obie listy są ograniczone zgodnie z uprawnieniami użytkownika.
- →Skróciłam proces. Wcześniej trzeba było przygotować zestawienie, podejrzeć je i dopiero zapisać. Teraz po zapisaniu wydruk od razu otwiera się do podglądu lub pobrania, a przycisk zapisu jest dostępny przez cały czas.
- →Dodałam nad tabelą podgląd wybranych pracowników i wydziałów, żeby było widać, czego dotyczy dany wydruk.
- →Usunęłam z tabeli paczek kolumny, które nie były już potrzebne.
Po: przebudowany komponent
Nowy przepływ w trzech krokach
To kolejna zmiana wykraczająca poza wygląd: inny przepływ pracy, wybór danych oparty na uprawnieniach i obsługa wielu formatów wydruku. Najgłębiej tego rodzaju pracę widać w projekcie Kadr i Płac, opisanym niżej.
Projekt Kadry i Płace
Migracja całej aplikacji z Forms na nowy design system
Osobnym i wymagającym zadaniem w ramach projektu była migracja aplikacji Kadry i Płace z systemu Forms na Angular, z pełnym przeprojektowaniem interfejsu w oparciu o nowy design system. Aplikacja obsługuje procesy kadrowo-płacowe dla instytucji publicznych: złożone przepływy danych, wielopoziomowe uprawnienia i skomplikowaną logikę biznesową.
Projekt realizowałam bez dedykowanego analityka, co oznaczało, że musiałam najpierw samodzielnie zrozumieć dziedzinę. Punktem wyjścia była analiza istniejącego systemu Forms, ekran po ekranie, z mapowaniem przepływów danych i punktów decyzyjnych. Rozmowy z osobami, które pracowały przy tym systemie i miały kontakt z urzędnikami, pozwoliły zrozumieć, gdzie procesy były uzasadnione, a gdzie nawarstwiły się przez lata bez rewizji. Każdą zmianę procesową uzgadniałam z kierownikiem projektu.
Przykład: ekran zmiany warunków zatrudnienia
W starym systemie ekran był przeładowany: dziesiątki pól, sekcji i kontrolek upchniętych na jednym widoku. Przez rozmowy z osobami znającymi system opisywałam każdy element: co jest ważne i zostaje, co można usunąć, a co przenieść lub zamienić na inny komponent. Powtarzalne pola z nazwami chowałam do tooltipów, oznaczenia osi czasu zamieniałam na ikonę, rozbudowane sekcje rozdzielałam na zakładki, a edytowalne komórki na komponent tabeli z przyciskiem dodawania. Każdą taką decyzję opisywałam w języku zrozumiałym dla deweloperów, którzy nie znali dziedziny kadrowo-płacowej.
Efektem był uporządkowany ekran rozłożony na zakładki: warunki zatrudnienia, struktura organizacyjna, składniki, oddelegowanie, kompetencje, zastępstwo. Zamiast jednego przeładowanego widoku powstał interfejs, w którym widać tylko to, czego użytkowniczka potrzebuje w danym momencie.
Przed: analiza ekranu Forms
Po: ekran rozłożony na zakładki
Pełny zakres migracji wymagał ponad 1000 makiet. Każdy ekran to była kompletna analiza procesu: stary widok z systemu Forms, nowy widok w design systemie, zmapowane komponenty oraz opisane stany i interakcje. Dokumentacja powstawała dla zespołu deweloperskiego w Hiszpanii, gdzie szybka komunikacja nie była możliwa, więc specyfikacja musiała być na tyle precyzyjna, żeby wdrożenie mogło przebiegać bez dodatkowych pytań.
Pomiar sukcesu
Sukces design systemu mierzy się adopcją i spójnością
Design system nie ma jednej metryki konwersji. Jego sukces widać w tym, ile aplikacji faktycznie z niego korzysta i jak spójne stały się dla użytkowniczki.
80+
aplikacji w ekosystemie
50+
komponentów w bibliotece
4
tryby dostępności WCAG
1000+
makiet w Kadrach i Płacach
40+
aplikacji wdrożonych
Do tego dochodzi dokumentacja analityczna dla każdego komponentu i jeden punkt odniesienia dla całego ekosystemu po stronie deweloperów. Dowód jakościowy: klienci pozytywnie oceniali nowy, spójny wygląd aplikacji. To nie jest liczba, ale w projekcie, którego celem była spójność i dostępność, jest to bezpośrednie potwierdzenie, że cel został osiągnięty.
Wnioski
Praca przy design systemie przez cztery lata różni się od pracy przy jednorazowym projekcie tym, że konsekwencje decyzji projektowych ujawniają się stopniowo, przy kolejnych aplikacjach i modułach. System musi działać w kontekstach, których jeszcze nie znasz w chwili projektowania.
Projektowanie czterech trybów kolorystycznych od fundamentów zmieniło moje podejście do decyzji o kolorze. Kiedy ten sam komponent musi działać poprawnie w standardowej palecie i w trybie kontrastowym jednocześnie, wyraźnie widać, które rozwiązania były architektoniczne.
Praca przy Kadrach i Płacach bez analityka pokazała, że zrozumienie dziedziny jest częścią pracy projektowej. Makiety są lepsze, gdy projektant rozumie logikę procesów, które projektuje.