Harmonizacja procesu projektowania z developmentem – design tokeny we współpracy UX/UI-Dev

Ponieważ design systemy (systemy projektowe) stają się gorącym tematem w branży, warto przyjrzeć się bliżej design tokenom (tokenom projektowym) – narzędziu, które wiele systemów projektowych, w tym najpopularniejszy na świecie Material Design lub MUI, wprowadziło w celu optymalizacji implementacji i zarządzania komponentami UI. Ponadto, jest to także modne hasło określające to, czego jako projektanci i deweloperzy możecie już używać w takiej czy innej formie.

Niezależnie od Twojej roli – projektanta, programisty lub menedżera poszukującego wiedzy, ten artykuł pomoże Ci zorientować się, czym są tokeny projektowe.

Pokrótce przedstawię ich historię, wyjaśnię koncepcję oraz jej zastosowanie w projektowaniu i kodzie, rolę, jaką odgrywają w usprawnianiu współpracy projektowo-programistycznej, a także w jaki sposób przekłada się to na organizacje zarządzające swoim brandingiem (identyfikacją wizualną) na dużą skalę.

Jeśli nadal nie masz pojęcia, o czym mówię, nie martw się, ten artykuł da Ci podstawy, aby zacząć. Gotowy/a? Zaczynajmy.

Ale po co w ogóle tokeny projektowe?

Jako projektanci staramy się odpowiadać na potrzeby użytkowników, a także realizować określone cele biznesowe. Dlatego, zanim przejdziemy do wyjaśnienia tematu artykułu, chciałabym najpierw skupić się na problemie biznesowym, który adresują tokeny projektowe.

Patrząc na światowe organizacje, możemy określić jedną wspólną cechę – branding. Rozwinięty na wyższym lub niższym poziomie, jest to język wizualny, który odróżnia jedną firmę od drugiej, umożliwiający komunikowanie się z docelowymi odbiorcami w określony sposób.

W dzisiejszych czasach, gdy branże opierają się na znacznie bardziej zróżnicowanych kanałach niż w przeszłości, biorąc pod uwagę nie tylko media drukowane, ale także niezliczone urządzenia wyświetlające treści na ekranach, systemy projektowe, czyli skodyfikowane języki marek, wspierają wszystkich zaangażowanych w proces tworzenia komunikacji, pomagając utrzymać spójność korzystania z identyfikacji wizualnej.

Można śmiało powiedzieć, że język wizualny organizacji jest filarem jej komunikacji i kluczowym czynnikiem w budowaniu zaufania odbiorców.

Przyjrzyjmy się tokenom na przykładzie

Jak zareagowałby ktoś na mailing lub stronę internetową instytucji, której powierza swoje środki, gdyby zobaczył przestarzałe logo lub kolory interfejsu niepasujące do wizualnego języka marki. Czy nie wydawałoby się to dziwne i raczej podejrzane?

Aby zilustrować znaczenie możliwości zastosowania decyzji projektowych na dużą skalę, posłużę się historią, której użył Louis Chenais.

Wyobraźmy sobie, że jesteś projektantem/-ką w dużej korporacji. Jako szef/-owa działu projektowego, masz proste zadanie odświeżenia wizerunku marki – zaktualizować jej główny kolor, zmieniając go na nowy.

Rebranding został sfinalizowany, a Ty musisz go „tylko” zaimplementować w interfejsach wszystkich produktów korporacji, które obejmują:

• stronę internetową firmy,
• aplikację internetową
• aplikację na Androida,
• aplikację na iOS.

„Nic wielkiego”, myślisz, podekscytowany/-a osiągnięciem celu i prosisz kierowników odpowiednich zespołów inżynieryjnych, odpowiedzialnych za każdy produkt, aby zaktualizowali kolor z X (stary) na Y (nowy), dostarczając im wartości RGB (przestrzeń kolorów).

W tym momencie zaczynają się schody. Napływają pytania o inne formaty kolorów, działające na różnych platformach, ludzie próbują ustalić, czy aktualizacja powinna mieć wpływ na wszystkie komponenty interfejsu użytkownika. Niektórzy menedżerowie są nieresponsywni, co sprawia, że wdrożenie aktualizacji w ich obszarach jest wątpliwe.

Zapewnienie prawidłowego zastosowania tej jednej zmiany okazuje się trudnym wyzwaniem bez wspólnego „języka projektowania”, którego mogliby używać zarówno projektanci, jak i programiści.

Jaki problem biznesowy rozwiązują zatem tokeny?

Kiedyś duże organizacje marnowały miesiące na wdrażanie zmian w identyfikacji wizualnej swoich produktów cyfrowych, co teraz, pod warunkiem, że produkty są oparte na tokenach projektowych, zajmuje kilka minut.

Jaki jest zatem problem biznesowy, który rozwiązują tokeny projektowe? Krótko mówiąc: wdrożenie tokenów projektowych oszczędza pieniądze Twojej organizacji, ponieważ nie potrzebujesz już miesięcy i często setek ludzi, aby wdrażać proste decyzje projektowe do kodu na różnych platformach. Nie ryzykujesz niespójności negatywnie wpływające na wizerunek Twojej marki.

Okej, tokeny projektowe… czyli?

Cofnijmy się o krok do narodzin koncepcji tokenów projektowych w Salesforce około 2015 roku. Jina Anne w zespole ds. systemów projektowych, w towarzystwie Jona Levine’a po stronie inżynieryjnej, koordynowała koncepcyjne, agnostyczne rozwiązanie – definicję projektową zlokalizowaną w jednym miejscu („Jedno źródło prawdy”) propagowaną na wszystkie platformy – tworząc termin „tokeny projektowe”.

Tokeny projektowe są nazwami używanymi w charakterze nośników decyzji projektowych, takich jak:

• kolor,
• ikonografia,
• krój lub rozmiar pisma,

w języku projektowym organizacji. Aby były używane i rozumiane przez wszystkich, nazwy te powinny być wynikiem wspólnych decyzji podejmowanych przez projektantów i programistów z uwzględnieniem przebiegu pracy zespołów.

Tokeny projektowe możemy opisać jako:

(…) wizualne atomy systemu projektowego – w szczególności są to nazwane jednostki, które przechowują atrybuty projektu wizualnego

Salesforce Lightning Design System

Jeśli nie jesteś zaznajomiony/-a z Metodologią Atomic Design, poniższa ilustracja przedstawia koncepcję na przykładzie fragmentu interfejsu Instagrama, rozbitego z całej strony na rzeczywiste atomy, umieszczając tokeny projektowe jako cząstki subatomowe, czyli wartości, z których składają się atomy.

Tokeny projektowe są językiem służącym do przekazywania intencji między różnymi częściami systemu.

Ethan Marcotte, „Design-ish systems„

A jaśniej?

Aby lepiej zilustrować tę koncepcję, posłużę się metaforą. Wyobraź sobie, że masz psa. Twój pies ma na imię „Charlie”, ale w zależności od okoliczności nazywasz go również „Małym Łobuzem” (ang. Little Rascal) i „Muffinką” (ang. Muffin).

Niezależnie od tego, jak nazwiesz swojego psa, to wciąż ten sam zwierzak (wbrew temu, co możesz myśleć, gdy właśnie zniszczył twój ulubiony mebel). Tokeny projektowe działają tak samo. Zamiast używać na stałe zakodowanych wartości – takich jak hex dla koloru, piksele dla odstępu itp. – wartości te możesz nazwać. To jak nadawanie pseudonimów decyzjom projektowym. Spójrzmy na poniższą analogię na przykładzie kolorów.

Tokeny projektowe są przeznaczone do wykorzystania w systemie projektowym oraz w przekroju Twoich produktów. Aby to umożliwić, musisz przekształcić je do użytku na różnych platformach (Web, iOS lub Android) przez różne zespoły.

W3C Design Tokens Standard

Jeśli chcemy zapewnić pomyślną adaptację tokenów projektowych w wielu aplikacjach, potrzebujemy standardu zapewniającego spójność. Konsorcjum World Wide Web (W3C), kierowane przez Tima Bernersa-Lee i Jeffreya Jaffe, we współpracy z wieloma organizacjami i pojedynczymi osobami, pracuje nad zapewnieniem standardu „W3C Design Tokens Standard”.

Pozwoliłoby to różnym narzędziom komunikować się w tym samym „języku”, na przykład umożliwiając pobieranie tokenów z Figmy i używanie ich w Adobe Illustrator. Wyobraź sobie, jak przyspieszyłoby to przepływ pracy między działami marketingu i projektowania produktu!

Aby dowiedzieć się więcej na temat standardu, zapoznaj się z oficjalną grupą Społeczności Design Tokens Community Group oraz W3C Design Tokens Community Group.

Jak budujemy za pomocą tokenów projektowych?

Teraz, gdy omówiłam absolutne podstawy koncepcji tokenów projektowych, pójdźmy dalej i zagłębmy się nieco bardziej w różne rodzaje tokenów i sposób, w jaki służą nam one do tworzenia projektów.

Każdy produkt cyfrowy jest strukturą funkcji, które składają się z interfejsów. Każdy interfejs jest zbudowany z komponentów, skomponowanych z tokenów projektowych.

Rozłóżmy na części komponent przycisku. Możesz zobaczyć wszystkie elementy, które przetłumaczylibyśmy na tokeny projektowe.

Przykłady tokenów

Oto kilka przykładów typowych tokenów projektowych używanych w standardowych systemach projektowych, z którymi można się spotkać:

•  Tokeny kolorów
  • Kolor wiodący – używany do głównych elementów marki i wezwań do działania.
  • Kolor dodatkowy – kolor uzupełniający dla akcentów i elementów drugorzędnych.
  • Kolory neutralne – odcienie szarości używane do tła, obramowania elementów i tekstu.
  • Kolory błędów/ostrzeżeń – wyraźne kolory wskazujące błędy lub ostrzeżenia w interfejsie użytkownika.
•  Tokeny typografii
  • Krój pisma – podstawowe i drugorzędne kroje pisma używane w nagłówkach i tekście głównym.
  • Rozmiar tekstu – różne rozmiary dla nagłówków, podtytułów, tekstu głównego itp.
  • Grubość tekstu – różne grubości tekstu dla wyróżnienia i zbudowania hierarchii.
  • Wysokość linii – spójne odstępy między wierszami tekstu dla czytelności.
•  Tokeny odstępów
  • Padding – standardowe wartości odstępu między zawartością elementu a jego obramowaniem dla elementów takich jak przyciski, karty i kontenery.
  • Margines – standardowe wartości marginesów dla odstępów między elementami.
  • Grid Spacing – odstępy między kolumnami i wierszami w układzie siatki.
• Tokeny obramowania
  • Promień obramowania – standardowe wartości promienia obramowania dla zaokrąglonych narożników elementów.
  • Szerokość obramowania – grubość obramowania wokół elementów.
  • Kolor obramowania – standardowe kolory obramowań wokół elementów.
• Tokeny cienia
  • Cień ramki – standardowe wartości cienia dodające głębi i przestrzenności elementom.
  • Cień tekstu – wartości cienia zwiększające czytelność i kontrast tekstu.
• Tokeny ikon
  • Rozmiar ikony – standardowe rozmiary ikon używanych w interfejsie użytkownika.
  • Kolor ikony – domyślny kolor ikony lub odmiany dla różnych stanów (aktywny, nieaktywny itp.).
•  Tokeny animacji
  • Czas trwania przejścia – czas trwania przejść między różnymi stanami lub interakcjami.
  • Funkcja czasu animacji – funkcje rozpędzenia i zwolnienia dla płynnych efektów animacji.
  • Klatki kluczowe animacji – klatki kluczowe dla bardziej złożonych sekwencji animacji.
•  Tokeny dostępności
  • Współczynnik kontrastu – minimalny współczynnik kontrastu między tekstem a kolorami tła zapewniający czytelność.
  • Wskaźnik fokusu – style wskazujące fokus na interaktywnych elementach do nawigacji za pomocą klawiatury.
  • Tekst dla czytników ekranu – ukryty tekst dla czytników ekranu w celu przekazania informacji użytkownikom z zaburzeniami narządu wzroku.

Kategorie tokenów

Tokeny dzielimy na trzy kategorie (typy). Każdy typ tokena oznacza poziom przypisanego kontekstu.

Tokeny globalne

Tokeny poziomu 1 (globalne) – wartości prymitywne – są podstawowymi, bezkontekstowymi jednostkami systemu tokenów projektowych.

Niezależnie od tego, czy zajmujesz się projektowaniem, programowaniem, czy kierujesz projektem, prawdopodobnie pracujesz z kolorami marki swojej organizacji. Istnieje duże prawdopodobieństwo, że w komunikacji posługujesz się wartościami hex (szesnastkowymi) lub innymi, odpowiadającymi tym kolorom.

Dlaczego nie jest to najwygodniejsze rozwiązanie? Zobaczmy:

• Dopóki nie znasz hexów na pamięć (i bądźmy szczerzy – możesz być jedyną osobą w organizacji z taką wiedzą), kod hex nie odzwierciedla dla Ciebie rzeczywistego koloru, czyniąc go trudno rozpoznawalnym.
• Nie daje żadnych informacji o decyzji projektowej stojącej za tym kolorem (gdzie ma być użyty itp.)
• Łatwo jest błędnie wpisać kod hex, co prowadzi do niespójności wizualnych w produkcie.

Globalne tokeny to nazwy nadawane na przykład wartościom hex, aby zapewnić bazowy, spójny i pozbawiony kontekstu opis tych wartości, który byłby zrozumiały dla każdego, kto z nimi pracuje. Pozwala to na uniknięcie sytuacji „pięćdziesięciu odcieni szarości” – przypadkowego używania kilku odcieni danego koloru Twojej marki, występującego w produkcie.

Zgodnie z powyższym schematem, nazwanie wartości hex „color.blue.600” zamiast użycia wartości hex, przynosi korzyści na kilka sposobów:

• Kolor jest teraz łatwo rozpoznawalny.
• Wartość przetłumaczona na token jest teraz zdefiniowana w kodzie jako zmienna, więc każda pomyłka w pisowni będzie sygnalizowana jako błąd kodu.

Pomimo oczywistych zalet korzystania z tokenów globalnych, nadal nie jest to idealne rozwiązanie i poleganie tylko na tego typu tokenach nie przekazuje informacji o zamierzonych wariantach użycia koloru, ani nie pozwala na zautomatyzowane, wybiórcze zmiany kolorów, wpływające tylko na określone grupy komponentów. Celem tego zespół programistów musiałby szukać odpowiednich przypadków użycia i ręcznie zmieniać kolor. Co za strata czasu, prawda?

Tokeny aliasowe

Oto zatem kolejny typ tokena projektowego. Tokeny typu drugiego (aliasowe lub systemowe) – nazwy specyficzne dla kontekstu, odnoszące się do decyzji projektowych stojących za wartościami (co one „robią”).

#0E6EE0, teraz określany jako „color.blue.600”, będzie również istniał w systemie pod różnymi aliasami, przedstawiającymi przypadki użycia. Na przykład jako „color.interactive.primary.background”, co oznaczałoby, że ten kolor ma być używany jako tło pierwszorzędnych, interaktywnych elementów interfejsu użytkownika.

Jak widać na powyższym przykładzie, w przypadku jakiejkolwiek zmiany koloru, operacja ta pozwoliłaby wpłynąć tylko na tła głównych interaktywnych elementów interfejsu, wykluczając te bez niebieskiego tła.

Wprowadzenie tokenów systemowych do kodu wpływa pozytywnie na:

• Eliminację ewentualnych błędów podczas kopiowania wartości do kodu (podobnie jak tokeny globalne, tokeny aliasowe również są zmiennymi w kodzie).
• Uczynienie przeznaczenia tokena jasnym zarówno dla zespołów projektowych, jak i programistycznych.
• Znaczne przyspieszenie procesu aktualizacji, umożliwiając programistom łatwą korektę właściwości komponentów na dużą skalę.
• Wzmocnienie pozycji programistów i projektantów, umożliwiając wykrywanie potencjalnego nieprawidłowego użycia właściwości (takich jak kolor tekstu zastosowany do ikon) oraz korygowanie takich błędów przez programistów samodzielnie lub w porozumieniu z projektantami.
• Skłonienie projektantów do ponownego przemyślenia faktycznej potrzeby stosowania dodatkowych wartości, na przykład kolorów, w systemie projektowym, ograniczając tym samym potencjalny bałagan i niepotrzebne skomplikowanie systemu.

Kiedy zatem sięgnąć po tokeny systemowe?

• Jeśli na tokeny został przetłumaczony każdy kolor w systemie projektowym, co zaowocowało gigantycznym zestawem globalnych tokenów do utrzymania.
• Jeśli globalne tokeny mają zastosowanie do tekstu, ikony, tła lub obramowania na wielu stronach.
• Jeśli system projektowy obsługuje wiele różnych marek i produktów, tematów i trybów.

Przykład:

Oczywiście, korzystanie z tokenów systemowych wiąże się z odpowiedzialnością za utrzymanie większego zestawu kolorów i wymaga dokładnego, przemyślanego planowania systemu, jednak w dłuższej perspektywie korzyści okazują się warte dodatkowego wysiłku.

Zdarzają się przypadki, w których nie zaleca się polegania na tokenach systemowych – na przykład, jeśli istnieje kolor, którego potrzebujesz użyć w swoim produkcie, ale nie jest on częścią języka wizualnego marki lub zostanie użyty tylko raz lub dla jednego konkretnego elementu interfejsu użytkownika, na który nie powinny mieć wpływu globalne zmiany decyzji projektowych.

Tokeny specyficzne dla komponentów

Do unikalnych elementów interfejsu użytkownika należałoby użyć tokenów trzeciego typu (specyficznych dla komponentów) – dedykowanych odrębnym komponentom i ich właściwościom.

Wszystkie powyższe nazwy (tokeny projektowe) oznaczają tę samą wartość szesnastkową, ale w innym kontekście lub w odniesieniu do innego komponentu systemu projektowego – gdy zastosujesz tokeny specyficzne dla komponentu, wszelkie możliwe zmiany decyzji projektowych (np.: aktualizacje kolorów) będą miały wpływ tylko na ten komponent i właściwość, do której odnosi się token. W naszym przypadku będzie to tylko kolor tła przycisku głównego w stanie domyślnym.

Poniższy diagram, gdzie zamieniam kolor niebieski na różowy, pokazuje, w jaki sposób tokeny pozwalają na sprecyzowanie zakresu modyfikacji decyzji projektowych. Możesz zastosować konkretną zmianę (np.: koloru) do wybranych tokenów, wpływając tylko na określone elementy interfejsu użytkownika.

No dobrze, ale jak wymyślamy nazwy tokenów?

Nie powiem Ci dokładnie, jaka jest zalecana konwencja nazewnictwa podczas tworzenia systemu tokenów dla Twojego produktu, ponieważ powinna być ona dostosowana do specyfiki produktu i preferencji zespołu. Ustalanie nazewnictwa wymaga czasu, ponieważ zespoły muszą zaangażować się w znalezienie idealnej logiki, która im odpowiada. Chociaż dobrze jest szukać inspiracji w otwartych systemach projektowych, należy pamiętać, że to, co działa dla jednego produktu, niekoniecznie musi być idealnym rozwiązaniem dla drugiego.

Nie zamierzam zbytnio rozwodzić się nad nazewnictwem tokenów, ponieważ jest to obszerny temat, warty dogłębnej eksploracji po rozpoczęciu przygody z budowaniem systemu tokenów projektowych. Pozwolę sobie jednak podzielić się kilkoma ogólnymi dobrymi praktykami do rozważenia podczas opracowywania systemu nazewnictwa tokenów projektowych, który służyłby organizacji.

Nazywanie tokenów – dobre praktyki

Nazwy tokenów powinny przede wszystkim być:

• jak najkrótsze – aby nie komplikować nadmiernie systemu,
• znaczące – aby jasno komunikować decyzje projektowe,
• łatwe do zrozumienia – dla łatwej orientacji i potencjalnego wdrożenia do systemu,
• modułowe – dla uproszczenia budowy systemu,
• spójne – w celu właściwego odzwierciedlenia systemu projektowego i ułatwienia zrozumienia konwencji nazewnictwa.

Podczas ustalania konwencji nazewnictwa dla tokenów systemowych dobrym początkiem będzie budowanie nazw w odniesieniu do:

• kategorii – atrybutu, do którego odnosi się token, np.: kolor, typografia, odstęp, cień, promień obramowania itp.,
• koncepcji – sytuacji, którą opisuje token, np.: informacja, ostrzeżenie, sukces itp.,
• celu (właściwości) – gdzie w interfejsie użytkownika zostanie użyty token, np.: tekst, ikona, tło, obramowanie, nagłówek, treść itp.,
• wariantu – potencjalnych wariantów tokena, np.: stany (aktywny, nieaktywny, wyłączony), rozmiary (XL, L, M, S) itp,
• komponentu (należy unikać, chyba że jest to nieodzowne) – komponent, na który będzie miał wpływ token, np. przycisk, pole wyboru, łącze itp.

Nazywanie tokenów – przykłady

Taka konwencja mogłaby wyglądać następująco:

kategoria.cel.wariant

Na przykład:

kolor.tło.aktywny

(opisując decyzję projektową podjętą w celu przypisania określonego koloru do tła aktywnych elementów interfejsu użytkownika)

Następnie należy skupić się na dostarczeniu jak najszerszego kontekstu. Mimo, że dobrze jest utrzymywać jak najkrótsze nazwy tokenów, jeśli nazwa dobrze odzwierciedla decyzję projektową, warto ją nieco wydłużyć.

W końcu tokeny projektowe nie są elementami interfejsu użytkownika, które widzieliby użytkownicy końcowi, ale informacjami tekstowymi przechowywanymi w kodzie, na których operują programiści. Dlatego im więcej kontekstu przekazują, tym lepiej.

Konwencje nazewnictwa tokenów projektowych, szczególnie w przypadku systemów projektowych obsługujących jednocześnie wiele marek, które wymagają wielu motywów (wersji języka wizualnego, np.: określonych kolorów marki, typografii, ikonografii itp.), mogą zawierać wiele poziomów nazewnictwa.

Na przykład, jeśli konieczne jest rozróżnienie tokenów między markami w Twoim systemie projektowym, może być konieczne wprowadzenie skrótów nazw ich produktów, które mogą wyglądać następująco:

marka.produkt.kolor.informacja.tło

Skróty nazw marek lub produktów umożliwiają programistom rozróżnianie tokenów w kodzie i wygodniejsze operowanie na nich.

Mamy już system – jak nim teraz zarządzać?

Gdy znasz już podstawy koncepcji tokenów projektowych i konwencje nazewnictwa tokenów, nadszedł czas, aby zaprezentować, w jaki sposób korzystanie z nich faktycznie usprawnia współpracę projektowo-developerską.

Dla porównania przedstawię proces oddawania projektów do wdrożenia w jego klasycznej formie, bez użycia tokenów projektowych.

Klasyczne wdrożenie projektów

Zazwyczaj wykonujemy następujące kroki:

1. Projektant dostarcza projekt interfejsu użytkownika w programie Figma (najpopularniejszym narzędziu do kolaboratywnego projektowania interfejsów).
2. Projektant przygotowuje specyfikację interfejsu użytkownika (dokumentację projektową z notatkami dla dewelopera).
3. Projektant przekazuje plik projektu i przeprowadza rozmowę z deweloperem/zespołem programistycznym, który będzie wdrażał projekt, aby omówić szczegóły.
4. Programiści sprawdzają plik i rozpoczynają kodowanie.

Na tym poziomie wydaje się to dość proste, biorąc pod uwagę, że projekt nigdy się nie zmieni. Projektowanie produktu polega jednak na jego ewolucji, a zmiany w projekcie są nieuniknione. Dlatego powyższy proces nie kończy się na czwartym kroku.

Z czasem, w miarę rozwoju marki, pojawia się więcej kroków:

• Powiedzmy, że wiodący kolor marki uległ zmianie i projektant musi zaktualizować projekt oraz poinformować o tym programistów, aby mogli odpowiednio skorygować kod.
• Zdarzają się również sytuacje, w których programiści muszą zmienić coś w kodzie, więc muszą poinformować o tym projektanta, aby zmiany te zostały również odzwierciedlone w projekcie.

Im więcej kroków i iteracji, tym więcej miejsca na błędy i – bądźmy szczerzy – ogólnie, taka ilość komunikacji tam i z powrotem dla jednej aktualizacji koloru to dużo, biorąc pod uwagę codzienne obciążenie pracą.

Chcemy, aby ten proces był tak prosty i zautomatyzowany, jak to tylko możliwe (jak na poniższym diagramie), aby zaoszczędzić cenny czas zarówno zespołów projektowych, jak i programistycznych.

Wprowadzenie tokenów projektowych

Właśnie dlatego wprowadzenie tokenów projektowych do procesu projektowo-programistycznego jest przełomem. Pozwól, że przeprowadzę Cię przez zarządzanie tokenami i to, jak może wyglądać proces przekazania projektu do inżynierów z ich wykorzystaniem.

Załóżmy, że przeprowadziliśmy już burzę mózgów z programistami i wymyśliliśmy najlepszą konwencję nazewnictwa, która służy nam wszystkim, a system projektowy został stokenizowany (decyzje projektowe, takie jak użycie kolorów do określonych celów, zostały przetłumaczone na tokeny), utrzymujemy teraz tokeny projektowe i zarządzamy nimi w jednym miejscu (naszym pojedynczym źródle prawdy).

Można to zrobić za pomocą różnych narzędzi i technologii, jednak ważne jest, aby wybrać te najlepiej pasujące do cyklu pracy zespołu oraz wymagań i ograniczeń platformy docelowej.

Ponieważ Figma jest naszym głównym narzędziem pracy, a projekty przekazujemy programistom również w postaci plików w Figmie, kluczowe dla optymalnego procesu pracy jest to, że działamy na tokenach projektowych w naszym rodzimym środowisku i że tokeny używane w kodzie znajdują również odzwierciedlenie w projektach, które trafiają do programistów.

Tokeny w Figmie

W kwietniu 2024  w Figmie możemy korzystać z tokenów na dwa sposoby.

Pierwszym z nich jest skorzystanie z wtyczki Tokens Studio for Figma, która została stworzona jako narzędzie wypełniające lukę między Figmą a kodem, będąc centralnym miejscem dla projektantów do utrzymywania biblioteki tokenów dla wielu marek/trybów/tematów, a także płynną synchronizację między projektem a kodem.

Projektanci mogą tam łatwo budować, przechowywać i zarządzać swoimi systemami projektowymi. Wtyczka umożliwia aplikacje tokenów do elementów projektu, zapewniając synchronizację między wtyczką a bibliotekami stylów w Figmie. Jesteśmy również w stanie synchronizować się ze zdalnym repozytorium, co usprawnia współpracę z deweloperami, ponieważ nie musimy nawet opuszczać Figmy, aby przekazać wszelkie zmiany systemowe do zespołu programistów w celu aktualizacji kodu.

Oczywiście nie jest to idealne rozwiązanie z punktu widzenia projektowania, ponieważ musimy polegać na wtyczce, zamiast móc stosować tokeny projektowe bezpośrednio za pośrednictwem interfejsu Figmy.

Będąc dynamicznie rozwijanym i aktualizowanym oprogramowaniem, w 2023 roku na swojej corocznej konferencji produktowej Figma po raz pierwszy zaprezentowała zmienne, zapewniając projektantom możliwość tworzenia systemów projektowych bezpośrednio w aplikacji.

Figma nie obsługuje jeszcze w pełni tokenów związanych z typografią i tekstem w zmiennych, jednak jesteśmy w stanie przechowywać te tokeny jako style i efekty bezpośrednio w aplikacji (nadal używając tego samego nazewnictwa, co programiści w kodzie). Spodziewamy się, że opcja pracy na zmiennych w tym obszarze również zostanie wkrótce wprowadzona.

W zależności od rodzaju licencji oprogramowania jesteśmy w stanie eksportować tokeny bezpośrednio z Figmy za pomocą dodatkowej dedykowanej wtyczki do eksportu pliku .json (który może być importowany do innych plików Figma i używany przez deweloperów) lub synchronizować bezpośrednio między plikami w Figmie (opcja dostępna w najbardziej zaawansowanych planach licencyjnych).

Po ustaleniu przepływu pracy z użyciem tokenów projektowych na poziomie samej Figmy, aby propagować je na platformy organizacji, konieczne będzie ich przekształcenie, na przykład za pomocą najpopularniejszego transformatora – Style Dictionary (firmy Amazon), który umożliwia konwersję tokenów projektowych na zmienne CSS.

Dla lepszego zrozumienia, przyjrzyjmy się bliżej procesowi adaptacji tokenów projektowych do postaci możliwej do wykorzystania przez kolejne aplikacje.

Tokeny projektowe są eksportowane przez Tokens Studio w strukturze pliku .json. Wspomniałam już, że wtyczka Tokens Studio jest w stanie łączyć się bezpośrednio ze zdalnym repozytorium (na przykład GitHub), co oznacza, że projektant może wprowadzać zmiany i pobierać je z repozytorium głównego. Odgrywa to znaczącą rolę w zwiększaniu płynności pracy, ponieważ nie musimy ręcznie eksportować pliku .json i przekazywać go do zespołu programistów w celu przesłania do repozytorium, co wymagałoby dodatkowej komunikacji i czasu.

Mając działającą strukturę JSON, Style Dictionary jest w stanie w pełni odpowiedzieć na Twoje wymagania. Kiedy już przetłumaczy surowe dane JSON na format specyficzny dla platformy, może generować różne formaty wyjściowe.

Dla przykładu, możesz użyć Style Dictionary do przetłumaczenia wartości z RGB w .css dla stron internetowych na RGBA w .json dla iOS lub na 8-jednostkowy hex (aarrggbb) – dla platform Android. Aby uzyskać jeszcze większą spójność, zespoły często decydują się nie tylko na przechowywanie komponentów w Figmie, ale także na korzystanie z narzędzia Storybook.

Storybook to otwarte narzędzie frontendowe (interfejsowe) do tworzenia komponentów interfejsu użytkownika i stron w izolacji. Jest to biblioteka, która przechowuje system projektowy, w tym język wizualny marki, komponenty i wzorce. Ponieważ działa poza główną aplikacją, może służyć jako „plac zabaw”, umożliwiając budowanie komponentów autonomicznie względem zależności bądź wymagań aplikacji.

Wiele czołowych firm i systemów projektowych, takich jak IBM Carbon, Shopify Polaris itp. korzysta ze środowiska Storybook, czerpiąc korzyści z jego licznych zalet:

• dostarczanie zmiennych dla popularnych preprocesorów CSS,
• format XML dla Androida,
• JSON dla iOS (nie można uzyskać tego konkretnego formatu, eksportując tylko z wtyczki Tokens Studio),
• jedno źródło prawdy, odzwierciedlające projekt w faktycznie zakodowanych komponentach,
• usprawnienie dokumentacji, ponieważ nie musisz być ekspertem od kodu, aby go współtworzyć i być w stanie utrzymywać aktualną dokumentację bez wysiłku; co więcej, programiści są w stanie zapewnić kontekst dla komponentów – dostarczyć opis i przykłady najlepszego wykorzystania i możliwych ograniczeń przed wdrożeniem komponentu,
• umożliwienie współpracy w czasie rzeczywistym między projektantami i programistami oraz świadomość tego czy komponent jest aktywny, czy w budowie dzięki wtyczce stanu wskazującej jego status,
• ułatwienie komunikacji między projektantami i programistami.

Taki przepływ pracy, umożliwiający tłumaczenie języka projektu na style sformatowane w celu dopasowania do konkretnych wymagań platformy, okazuje się skalowalnym, niezależnym od technologii rozwiązaniem, które jest wystarczająco elastyczne, aby dostosować się do wszelkich przyszłych zmian w organizacji lub produkcie.

Na czym polegają usprawnienia?

W jaki sposób początkowy klasyczny przepływ pracy zostałby usprawniony przy użyciu tokenów projektowych?

1. Projektant kończy projekt interfejsu w programie Figma.
2. Wszystkie informacje są już zawarte w tokenach projektowych, więc projektant nie musi dostarczać skomplikowanej dokumentacji specyfikacji interfejsu użytkownika, obejmującej odstępy, kolory dla poszczególnych stanów przycisków itp.
3. Spotkania w związku z oddaniem projektu są krótsze lub w ogóle niepotrzebne, ponieważ decyzje projektowe dotyczące stylizacji są już przetłumaczone na tokeny i przechowywane w Storybook, dzięki czemu są łatwo dostępne dla wszystkich.
4. Zespół programistów może sprawdzić plik i płynnie wdrożyć projekt.

A co, jeśli zaistnieje potrzeba jakiejkolwiek zmiany w projekcie – na przykład paleta kolorów marki wymaga aktualizacji? To proste – projektant lub inżynier UX aktualizuje system tokenów w źródle, eksportując plik .json lub przesyłając zmiany bezpośrednio do repozytorium. Programiści przejmują i automatycznie propagują aktualizacje do kodu.

Co ostatecznie dają nam tokeny projektowe?

Podsumowując, podkreślę kilka generalnych kluczowych korzyści, jakie korzystanie z tokenów projektowych przynosi Tobie i Twojemu zespołowi.

Solidne fundamenty

Stabilny system projektowy, w którym decyzje są dobrze przemyślane i spójne. Wdrożenie tokenów projektowych wymaga dostosowania systemu projektowego do prawidłowego funkcjonowania – musisz zapewnić odpowiednią organizację systemu i architekturę elementów interfejsu użytkownika. Co więcej, jasny i zrozumiały język wizualny ma ogromną wartość dla marki, aby mogła dobrze się komunikować i budować zaufanie.

Komunikacja w tym samym języku

Wyobraź sobie ponownie, że jesteś szefem/-ową działu projektowego i musisz przeprowadzić aktualizację kolorów w swoim produkcie, funkcjonującym na różnych platformach. Nie musisz już używać kilku różnych wartości (HEX, RGB, RGBA itp.). Nie ryzykujesz żadnych błędów podczas propagowania wartości kolorów do kodu. W komunikacji między projektantami i programistami polegasz na wspólnej konwencji nazewnictwa, która jest zrozumiała dla wszystkich i usprawnia codzienną pracę.

Łatwe utrzymanie systemu

W przypadku jakichkolwiek zmian decyzji projektowych nie trzeba nanosić ich oddzielnie w każdym pakiecie wyjściowym danych lub pliku związanym z systemem projektowym. Edytujesz w jednym miejscu i wszystko jest jednocześnie bezpiecznie aktualizowane. Zarządzanie systemem jest teraz łatwe i masz pełną kontrolę nad skalą wprowadzanych zmian.

Jedno źródło prawdy

Dzięki systemowi tokenów projektowych wszystkie pliki i repozytoria są zsynchronizowane. Potencjalne zmiany nie wymagają już komunikowania ich każdemu menedżerowi produktu osobno. Zamiast tego Ty (lub inżynier UX odpowiedzialny za to zadanie) aktualizujesz tokeny w systemie, przesyłasz zmianę do repozytorium i pozwalasz programistom zająć się nią od tego momentu, upewniając się, że mają dokładne informacje.

Jakość Twoich projektów nie ucierpi z powodu potencjalnego niepoprawnego wdrożenia efektów Twojej pracy przez programistów ani nie wystąpią niespójności na różnych platformach, na których funkcjonuje Twoja marka.

Właściwa metodologia współpracy między zespołami

Zespoły projektowe i programistyczne uzgadniają konwencję nazewnictwa, zestaw narzędzi najbardziej odpowiedni dla przepływu pracy i charakterystyki produktu, a także zasady utrzymania systemu, których należy przestrzegać. Pozwala to na automatyzację procesów i znacznie usprawnia współpracę między projektantami i programistami.

Podsumowując…

Tokeny projektowe są potężnym narzędziem, pozwalającym na lepszą współpracę zespołów produktowych, a także zapewniającym spójność marki na rozmaitych platformach. Z pewnością nie jest to jednoroczny trend i o tej technologii będziemy słyszeć coraz częściej.

Warto pomyśleć o wprowadzeniu tokenów projektowych do swojego produktu, gdy:

• jako projektant/-ka nie chcesz już obserwować swojej pracy wdrożonej niepoprawnie i chcesz zarządzać decyzją projektową kompleksowo – od decyzji do wdrożenia – widząc spójny język wizualny na wszystkich platformach, dla których projektujesz,
• jako programista/-ka, jesteś zmęczony/-a ręcznym wprowadzaniem zmian w projekcie i aktualizacją wartości oraz chcesz ulepszyć sposób, w jaki zarządzasz stylami,
• jako menedżer/-ka, masz dość tych wszystkich zgłaszanych błędów ostylowania komponentów i chcesz, aby projektanci i programiści współpracowali na wspólnej płaszczyźnie na dużą skalę.

Dla mnie osobiście niezwykle ekscytujące było wyruszenie w podróż po świecie tokenów projektowych wraz z inżynierką UX i zespołem programistów, z którymi pracuję na co dzień. Już teraz widać, jak nasza współpraca ewoluowała za sprawą poszukiwania wspólnej płaszczyzny realizowania zadań.

Jeśli uważasz, że przedmiot artykułu jest interesujący, zachęcam do dalszej eksploracji z pomocą „The Ultimate Design Systems Resources List”.

Bibliografia

• „WTF are Design Tokens” – wartościowy materiał wideo autorstwa Jiny Anne
• Wspaniały, prosty film o tokenach projektowych autorstwa Hiro Matsui
• “Living Design System” autorstwa Sönke Rohde
• Artykuł Adriána Guerreroo tokenach projektowych
• “Supercharge your Design System with Design Tokens” autorstwa UX Collective Jishnu Hari
• “Evolution of design tokens and component styling, part 1” autorstwa Briana Hestona
• “Design Tokens 101” autorstwa Rominy Kavcic
• “What Are Design Tokens?” na platformie STUDIO od UXPin
• “Design tokens” publikacji The Design System Guide
• “Design tokens for dummies” autorstwa Louisa Chenaisa
• “Brief History: Design Tokens” autorstwa Maxwella White’a
• Introduction to design tokens by Louis Chenais
• “Piping Design Tokens from Figma” autorstwa Tylera Mathesa
• “Converting Design Tokens to CSS Variables using Style Dictionary” Anny Popovej
• The Design System Guide
• “Spotify’s rebranding journey, based on design tokens” – Shaun Bent, Marina Posniak, Gerrit Kaiser
• Materiały na temat zmiennych publikowane przez Figmę
• Przewodnik Figmy po różnicach między zmiennymi a stylami