AuraPura - projekt design systemu
- UI Design
- Design system
- Web
- E-commerce
Project overview
Wstęp
AuraPura to projekt stworzony w ramach kursu Design system intro. Punktem wyjścia był brief marki, zapis wywiadu z klientem i zestaw assetów. Na tej podstawie miałam samodzielnie zbudować kompletny design system i doprowadzić go do finalnych widoków na trzech wielkościach ekranu.
Cel
Przejście przez cały proces tworzenia design systemu od podstaw. Od zdefiniowania core tokenów (kolory, typografia, spacing itd.) przez budowę komponentów i ich dokumentację, aż po ich zastosowanie w konkretnych layoutach. Chciałam przejść przez każdy etap tego procesu, żeby lepiej zrozumieć jak decyzje na poziomie fundamentów wpływają na cały system.
Proces
Pracę zaczęłam od analizy briefu i assetów marki, z których wyciągnęłam paletę kolorów, styl typografii i ogólny kierunek wizualny. Następnie zbudowałam system od fundamentów, opierając go na podziale między core tokenami (surowe wartości, np. konkretne odcienie kolorów) a alias tokenami (znaczenie w kontekście interfejsu, np. background-primary, text-error). Ten podział pozwala zmieniać wartości na poziomie core, nie ruszając logiki komponentów, które odwołują się tylko do aliasów. Na tokenach zbudowałam komponenty wielokrotnego użytku.
Kluczowym elementem projektu było wykorzystanie Figma variables w dwóch rolach:
- Do obsługi themingu (np. warianty kolorystyczne),
- Do dostosowania komponentów do różnych breakpointów.
Dzięki temu komponenty automatycznie adaptowały się do widoku mobile, tablet i desktop bez konieczności tworzenia osobnych wersji.
Czego się nauczyłam?
Przede wszystkim tego, jak dużo pracy kryje się za design systemem. Samodzielne przejście przez cały proces, od tokenów do gotowych ekranów, uświadomiło mi, jak ważna jest spójność na każdym poziomie i jak decyzje podjęte na samym początku wpływają na kolejne działania. Cały projekt pozwolił mi lepiej zrozumieć podstawy budowania systemów projektowych i ich wartość dla całego zespołu.
Drugą kluczową lekcją było wykorzystanie Figma variables do zarządzania zarówno motywem, jak i responsywnością komponentów. To podejście pozwoliło mi budować system, który skaluje się bez chaosu, a ewentualne zmiany można wprowadzać globalnie bez potrzeby kontrolowania poszczególnych komponentów.
Co zrobiłabym dalej?
Projekt kursowy pozwolił mi przejść przez fundament budowania design systemu. Ale design system to nie tylko ładna biblioteka komponentów - to produkt, który wymaga strategii, procesów i ciągłego utrzymania. Gdybym rozwijała Aurapurę jako realny system, skupiłabym się na kilku kluczowych obszarach
Zasady współpracy z systemem
Ustaliłabym kto i jak może dodawać nowe komponenty, jak wygląda zgłaszanie potrzeb i kto zatwierdza zmiany. Czy system prowadzi jeden zespół, czy każdy zespół produktowy może dorzucać swoje komponenty. To ma ogromne znaczenie dla tego, jak system się skaluje i działa.
Dokumentacja komponentów
Każdy komponent opisałabym tak, żeby nowa osoba w zespole wiedziała do czego służy, jakie ma warianty, kiedy go użyć, a kiedy lepiej sięgnąć po coś innego. Do tego wytyczne dostępności oraz konkretne przykłady dobrych i złych zastosowań. Osobno dla designerów, osobno dla developerów.
Uzupełnienie brakujących komponentów
Wykonałabym audyt dzięki któremu ustaliłabym jakich elementów brakuje, które powtarzają się najczęściej w produkcie, i od nich bym zaczęła. Nie budując wszystkiego na raz, tylko priorytetyzując po realnych potrzebach zespołu.
Wersjonowanie i informowanie o zmianach
Wprowadziłabym numerowanie wersji i listę zmian przy każdym uaktualnieniu, żeby zespoły wiedziały co się zmieniło i czy update coś im zepsuje. Plus synchronizacja wersji między Figmą a kodem.
Mierzenie czy system działa
Samo zbudowanie DS nie wystarczy - trzeba wiedzieć, czy ludzie z niego korzystają. Śledziłabym ile UI jest pokryte systemem, jak często ktoś odłącza komponent w Figmie zamiast go użyć i jak szybko nowe osoby się wdrażają.
Spójność między designem a kodem
Zadbałabym o to, żeby nazwy tokenów w Figmie odpowiadały zmiennym w kodzie 1:1. Dzięki temu designer i developer mówią tym samym językiem, a zmiany w tokenach przechodzą płynnie z designu do implementacji.