Design system dla holdingu mediowo-technologicznego

Przegląd

O kliencie

Wirtualna Polska to jeden z największych holdingów mediowo-technologicznych w Europie Środkowej i Wschodniej. Prowadzi ponad 50 serwisów i aplikacji, w tym 40 portali mediowych, docierając do 23 milionów unikalnych użytkowników miesięcznie. Przez 25 lat rozwijała wiele wewnętrznych systemów i przejęła ponad kilkanaście zewnętrznych firm wraz z ich własnymi procesami redakcyjnymi i systemami back-office.

O projekcie

Wirtualna Polska zaprosiła nas do przebudowy swojego systemu back-office i stworzenia nowej, ogólnofirmowej aplikacji do edycji treści. Już we wczesnych etapach naszego procesu odkrycia zdaliśmy sobie sprawę, że do zbudowania tej aplikacji potrzebujemy design systemu.

Klient dysponował już kilkoma rozwiązaniami projektowymi przejętymi wraz z aplikacjami na przestrzeni lat. Zaproponowaliśmy zastąpienie ich jednym design systemem, który zunifikuje ponad 20 serwisów i zapewni spójną obecność marki. To była najlepsza i najbardziej logiczna odpowiedź na problemy z nieuporządkowanymi stylami i niespójnym doświadczeniem użytkownika.

Wyzwanie

Czym właściwie jest design system?

(Pomiń tę część, jeśli już wiesz — przewiń do sekcji "Nasza praca")

Design system to kompleksowy zbiór standardów, narzędzi, komponentów i stylów zapewniających spójność projektowania i doświadczeń użytkownika na różnych platformach. Obejmuje elementy UI, zasady typografii, palety kolorów oraz wytyczne dotyczące interakcji i użyteczności. To również zestaw reguł określających, jak te elementy powinny być stosowane i łączone.

To coś więcej niż UI kit, style guide czy biblioteka komponentów — to cały system, którego idea polega na tym, by stworzyć go raz i używać wielokrotnie. Z natury nigdy nie jest produktem skończonym: ewoluuje w czasie i wymaga stałej dbałości.

Korzyści z design systemu

Właściwie wdrożony i stosowany design system przynosi wiele korzyści, między innymi:

• Większą efektywność czasową i kosztową przy budowaniu nowych produktów,
• Spójny branding aplikacji w ramach ekosystemu,
• Niższe koszty utrzymania istniejących aplikacji,
• Lepsze doświadczenia użytkownika,
• Zoptymalizowaną kontrolę nad rolami i uprawnieniami.

Jeśli chcesz dowiedzieć się więcej, przeczytaj nasz przewodnik po design systemach, lub odpowiedz na te 10 pytań dotyczących wprowadzenia design systemu do Twojej organizacji.

Polecamy również osobne case study poświęcone redesignowi systemu back-office dla Wirtualnej Polski.

Nasza praca

Role i odpowiedzialności

Jako Autentika stworzyliśmy zespół design systemu w pełni odpowiedzialny za jego tworzenie i rozwój. Oto podział ról, który przyjęliśmy.

Projektant UX

• Inwentaryzacja aplikacji — procesy i ekrany
• Kwalifikowanie komponentów do biblioteki
• Tworzenie dokumentacji

Projektant UI

• Wsparcie pracy projektanta UX
• Tworzenie biblioteki komponentów i style guide

Front-end developer

• Budowa biblioteki komponentów, np. w React
• Wsparcie przy tworzeniu dokumentacji
• Przejęcie dokumentacji od projektantów
• Wdrożenie DS wśród pozostałych developerów

Zespół klienta

Po stronie WP w projekt zaangażowanych było kilkadziesiąt osób. Uczestniczyły one w rozwijaniu aplikacji i tworzeniu nowych produktów opartych na rodzącym się design systemie. Były pierwszymi użytkownikami DS i na bieżąco zgłaszały potrzeby, błędy i sugestie usprawnień w miarę rozwijania systemu.

Metodologia

Na początku budowaliśmy design system zgodnie z koncepcją Atomic Design. Ta metoda projektowania interfejsów użytkownika dzieli je na pięć hierarchicznych poziomów: atomy, molekuły, organizmy, szablony i strony. Atomy to najmniejsze elementy interfejsu, takie jak przyciski czy etykiety. Molekuły to grupy atomów tworzące jednostki funkcjonalne, a organizmy — złożone zestawy molekuł. Szablony i strony to struktury powierzchniowe i gotowe produkty wypełnione treścią.

Szybko jednak zauważyliśmy wady tego rozwiązania. Granice między poziomami często wydawały się niejasne i trudno było określić, czy dany komponent to atom, molekuła czy organizm. Co więcej, podział ten nie zawsze odzwierciedlał rzeczywistość kodowania.

Opracowaliśmy własne metody, oparte na Atomic Design i idei modularnej budowy komponentów, ale bez sztywnego trzymania się sztucznych podziałów. Zaczęliśmy grupować komponenty nie według złożoności, lecz według funkcji, zastosowania i rodzin komponentów.

Jak pracowaliśmy

Oto jak podeszliśmy do wyzwania i jakie kroki podjęliśmy w tym procesie:

1) Inwentaryzacja aplikacji

Najpierw przeanalizowaliśmy istniejący system aplikacji WP i sporządziliśmy szczegółową inwentaryzację wszystkich aplikacji. Pogrupowaliśmy je według typów i różnic, a następnie zbadaliśmy wymagania (technologia, mobile vs desktop, back office czy front office).

Po przeanalizowaniu aplikacji i uchwyceniu pełnego zakresu systemu wybraliśmy główną aplikację — edytor treści — jako podstawę do stworzenia design systemu. Następnie przeprowadziliśmy szczegółową inwentaryzację i przegląd komponentów edytora treści, wyselekcjonowaliśmy prototypy projektowe, wzorce i możliwe komponenty do design systemu.

2) Rozwój

To była kluczowa faza projektu, podczas której zespół projektowy skupił się na tworzeniu i dostosowywaniu podstawowych komponentów, a developerzy przede wszystkim wdrażali komponenty UI/UX.

Oto jak wyglądała nasza praca w szczegółach:

Nadszedł czas, by zastanowić się, które elementy powinny znaleźć się w design systemie. Zaczęliśmy projektować komponent, eksplorując wszystkie możliwe warianty i uwzględniając stany, jakie będą potrzebne w aplikacjach. Gdy projektant opublikował komponent w bibliotece, czas był na development. Projektant przekazywał wtedy deweloperowi zarówno komponent, jak i całą związaną z nim wiedzę.

Razem omawiali, jak komponent powinien działać, i wymieniali się informacją zwrotną — wszystko po to, by stworzyć jak najlepszą wersję przed dodaniem jej do biblioteki komponentów w kodzie.

Ten proces powtarzaliśmy wielokrotnie dla każdego komponentu.

3) Dokumentacja

W świecie wytwarzania produktów dokumentacja bywa pisana na końcu projektu. W przypadku design systemów kluczowe jest jednak rozpoczęcie dokumentowania od razu, gdy komponent jest gotowy do dodania do biblioteki — równolegle z procesem tworzenia.

W przypadku Wirtualnej Polski spędziliśmy dużo czasu na omawianiu i analizowaniu wszystkich komponentów, aby dokumentacja zawierała wszystkie niezbędne informacje dla zespołów projektowych i developerskich oraz zapewniała prawidłowe korzystanie z systemu.

Zebraliśmy szczegółowe informacje o wszystkich dostępnych w systemie komponentach interfejsu użytkownika (UI). Komponenty są w pełni opisane — zawierają informacje o tym, jak i kiedy ich używać, jakie mają właściwości, zależności oraz jak można je zmieniać lub rozszerzać.

Oto przykłady tego, jak wygląda dokumentacja:

Przykład dokumentacji design systemu — strona główna dokumentacji

Przykład dokumentacji design systemu — banner

Dla każdego komponentu udostępnione są przykłady kodu, dzięki czemu developerzy mogą łatwo zrozumieć, jak z niego korzystać. W naszym systemie opartym na komponentach React przykłady zawierają fragmenty kodu JavaScript/TypeScript.

Przygotowaliśmy dwa rodzaje dokumentacji:

Dla developerów: technologia użyta w procesie, gotowe do użycia snippety komponentów, właściwości komponentów, przykłady zastosowań, reguły i wytyczne. Dokumentacja pełni rolę instrukcji dla developera dotyczącej implementacji i konfiguracji każdego komponentu w aplikacji.

Dokumentacja powstała w Storybooku.

Dla projektantów: zasady i wytyczne dla każdego komponentu, fundamenty DS (kolory, odstępy, typografia, ikonografia) i wzorce użycia. Dokumentacja pomaga projektantom poznać zasady projektowania i tworzyć nowe elementy, zachowując spójność i jakość interfejsów użytkownika.

Dokumentacja powstała w Figmie.

Stworzyliśmy też przewodnik wprowadzający do design systemu, z filtrami ułatwiającymi wyszukiwanie komponentów.

4) Utrzymanie

Design systemy nie są statycznymi, skończonymi produktami — to projekty, które rosną i ewoluują. W miarę dojrzewania systemu i aplikacji uwaga naturalnie przesuwa się z tworzenia nowych komponentów na optymalizację i udoskonalanie już istniejących.

W tej ewolucji rola projektanta przeszła w pozycję doradczą — projektant wspierał głównie zespół deweloperski w efektywnym korzystaniu z design systemu. Developerzy z kolei przejmowali odpowiedzialność za tworzenie nowych komponentów, czerpiąc ze swojego doświadczenia.

Te zmiany są naturalne i oczekiwane, gdy design system staje się integralną częścią codziennej pracy klienta.

Jeśli interesujesz się design systemami, posłuchaj tego odcinka naszego podcastu, w którym Dominika Kiszkiel szczegółowo opisuje cały proces.

Co dostarczyliśmy

1) Skalowalność i spójność: od prostych do złożonych elementów

Jak wspomnieliśmy, stosowaliśmy podstawowe zasady metodologii Atomic Design, budując design system od najmniejszych do największych jednostek. Takie podejście pozwoliło nam zagwarantować spójność, łatwość utrzymania i skalowalność systemu.

Zaczęliśmy od najprostszych komponentów (atomów), które są podstawowymi jednostkami systemu: przyciskami, polami tekstowymi, ikonami, etykietami itp.

Gdy te podstawowe elementy zostały zdefiniowane i stworzone, łączyliśmy je w większe, bardziej złożone całości.

2) Wymienność: zamiana komponentów bez zaburzania systemu

Komponenty naszego systemu są zaprojektowane tak, by były łatwo wymienne z innymi podobnymi komponentami bez zaburzania spójności systemu. Wszystkie komponenty są ustandaryzowane, aby zapewnić jednolitość. Zaprojektowaliśmy odstępy, rozmiary i ikony tak, by można było tworzyć mniejsze warianty komponentów bez uszczerbku dla spójności projektowej.

3) Niezależność i modularna struktura: komponenty jako klocki do budowania aplikacji

Każdy komponent jest niezależny i zawiera wszystko, czego potrzebuje do prawidłowego działania: kod JS, style i strukturę HTML. Każda część systemu jest zaprojektowana tak, aby być jak najbardziej samowystarczalną — umożliwiając łatwe tworzenie, rozszerzanie i aktualizację komponentów. Pozwala to na efektywniejsze zarządzanie systemem i ułatwia development.

W ten sposób, jeśli chcemy zmienić wygląd komponentu "przycisk" używanego w wielu miejscach, wystarczy zaktualizować ten jeden komponent. Zmiana będzie widoczna wszędzie tam, gdzie komponent jest używany.

4) Adaptowalność: system dostosowuje się do wymiany komponentów

Nasze komponenty są zaprojektowane elastycznie, by dostosowywać się do różnych sytuacji. Na przykład jeśli zastąpimy jeden komponent innym, system potrafi się zaadaptować, zachowując spójność i stabilność projektu.

5) Ponowne użycie: korzystamy z tego, co zaprojektowaliśmy

Tworzyliśmy komponenty z myślą o ich ponownym użyciu w różnych częściach systemu, a nawet w różnych projektach. Tworząc nowe komponenty, nie wynajdujemy koła od nowa — korzystamy z tego, co już zaprojektowaliśmy w design systemie.

Dzięki temu system jest wszechstronny, kompletny, efektywny i optymalnie zaprojektowany. Nie stosujemy komponentów jednorazowych, lecz staramy się używać istniejących. W efekcie 90% projektów nowych aplikacji opiera się na komponentach z design systemu.

6) Zasady i najlepsze praktyki

Nie tylko projektowaliśmy komponenty, ale też ustalaliśmy zasady ich stosowania w konkretnych kontekstach. Przewidywaliśmy, które komponenty mogą występować razem, a które nie — na przykład tworzyliśmy reguły dotyczące umieszczania przycisków w sytuacjach, gdy chcemy ustawić różne warianty przycisków obok siebie.

W ramach bonusu zaprojektowaliśmy też naszą maskotkę — psa Corgi, który już znalazł swoje miejsce na koszulkach całego zespołu!

Czego się nauczyliśmy

Trafiliśmy na kilka ślepych zaułków i musieliśmy przeprowadzić kilka refaktoryzacji. Oto najważniejsze wnioski.

1) Skalowalność i elastyczność systemu

System powinien być skalowalny, z łatwo modyfikowalnymi i ponownie używalnymi komponentami, dzięki czemu nie musimy budować wszystkiego od podstaw. Właściwe planowanie i zarządzanie projektem są kluczowe dla zapewnienia łatwości utrzymania — w tym dokumentacji kodu, regularnych przeglądów kodu, testowania i dbałości o jakość kodu.

2) Złożoność a szybkość tworzenia nowych funkcji

W miarę jak projekt systemu staje się bardziej złożony, utrzymanie, rozbudowa i tworzenie nowych funkcji mogą stawać się trudniejsze ze względu na rosnącą złożoność i dług technologiczny.

Dobrze zaprojektowany system pozwala jednak na szybszy i łatwiejszy rozwój nowych aplikacji dzięki wykorzystaniu istniejących rozwiązań i narzędzi. Stopniowe rozszerzanie i udoskonalanie biblioteki zmniejsza potrzebę zaczynania od zera za każdym razem.

3) Warstwa wizualna bez logiki

Priorytetem jest dla nas oddzielenie zbędnej logiki od komponentów design systemu, aby uprościć development i utrzymanie. Dbając o równowagę między uniwersalnością a specyfiką, skupiamy się na prezentacji komponentu i interfejsie użytkownika, zamiast wbudowywać złożoną logikę. Takie podejście zwiększa elastyczność, użyteczność i możliwości dostosowania dla developerów, którzy mogą dodawać konkretną logikę zgodnie z potrzebami swoich implementacji.

Skupiamy się na ciągłym rozwoju i doskonaleniu, traktując każdą przeszkodę jako okazję do nauki i odkrywania nowych możliwości. Stosujemy filozofię uczenia się na małych błędach, by unikać większych w przyszłości.

Informacje dodatkowe

Komunikacja

Komunikacja odgrywa kluczową rolę w tworzeniu design systemu, przede wszystkim z następujących powodów:

Rozumienie potrzeb: Niwelowanie przepaści między developerami a projektantami UI/UX zapewnia wspólne rozumienie celów i wymagań systemu oraz zbliżenie ich perspektyw.

Spójność: Komunikacja sprzyja spójności — projektanci mogą wyjaśniać swoje intencje i decyzje, a developerzy omawiać możliwości technologiczne i wyzwania.

Informacja zwrotna: Design system ewoluuje poprzez regularne przeglądy, aktualizacje i iteracje, co wymaga ciągłej komunikacji i współpracy między zespołami.

Dokumentacja: Wspólne wysiłki są kluczowe przy tworzeniu przejrzystych i zrozumiałych instrukcji oraz wytycznych dotyczących efektywnego korzystania z design systemu.

Rozumienie ograniczeń: Projektanci muszą rozumieć ograniczenia techniczne, z jakimi mierzą się developerzy podczas implementacji, a developerzy powinni rozumieć cele projektowe i oczekiwania użytkowników.

Stos technologiczny i narzędzia

Front-End:

React, Next, NX, TypeScript, Styled-components oraz Storybook

Versioning, Changelog.

Testy jednostkowe z Jest.js + React Testing Library

UI i dokumentacja:

Figma — aktualnie, wcześniej Sketch i Invision, Storybook + Notion (szkice) — dokumentacja