Notatki z prezentacji Jake’a Albaugh i Chada Bergmana z Config 2025. Wszystkie przemyślenia, obserwacje i wnioski przedstawione w tekście pochodzą od prelegentów.

TL;DR

Design to coś więcej niż wygląd – sposób wnoszenia uwagi do produktu, jak podkreśla Jake Albaugh
Tarcie między designem a kodem jest naturalne – różne punkty wyjścia prowadzą jednak do tego samego celu końcowego
Wzorce to wspólna miłość projektantów i programistów – obie grupy budują abstrakcje dla łatwiejszej pracy
Systemy dojrzewają przez użycie – dotarcie do granic oznacza wzrost, nie porażkę
Wczesna współpraca jest kluczowa – włączanie programistów w proces projektowania odkrywa możliwości designu
Narzędzia mogą wspierać dopasowanie – Variables, Code Syntax i Make pomagają w synchronizacji
Najlepsza praca to wspólna praca – wspólne zrozumienie między zespołami stanowi fundament skutecznych systemów

Design jako głęboko ludzka praktyka

W czasach dynamicznych zmian technologicznych łatwo zagubić się w pytaniach o przyszłość. Jake Albaugh z Figmy rozpoczyna jednak prezentację od fundamentalnej i ponadczasowej prawdy: design zawsze będzie ważny.

„Design jest ważny dla projektantów, dla programistów i dla tych, którzy słysząc frazę „właściwości boolean” myślą: nie wiem, czy widziałem to wcześniej” – zauważa Albaugh. Mimo że brzmi to jak oczywistość na konferencji Figmy, w czasach gwałtownych zmian warto przypomnieć podstawy.

Design to znacznie więcej niż sposób, w jaki rzeczy wyglądają. To sposób wnoszenia uwagi do produktu. Wszyscy pragniemy być traktowani z uwagą, dlatego dobry design właśnie to robi – jest uważny. To głęboko ludzka potrzeba, która wykracza daleko poza samą estetykę.

Albaugh stawia kluczowe pytanie: kiedy zastanawiamy się, co powinno być zautomatyzowane, lepiej spytać „co powinno być pozostawione ludzkiemu dotykowi?” Dotyk to sposób, w jaki rozważamy doświadczenia tych, dla których projektujemy. To pytanie ciągle powraca w kontekście systemów projektowych – balansowanie między elastycznością a spójnością jest trudne i ostatecznie to kwestia ludzkiego dotyku.

Dzisiaj nigdy nie było łatwiej coś stworzyć, jednak stawianie rzeczy to łatwa część. Trudne jest tworzenie rzeczy znaczących. Co zachwyca użytkownika? Co przywiązuje go do naszych produktów? Ludzki dotyk czyni produkty znaczącymi.

Dlaczego design i kod się różnią (i dlaczego to dobrze)

Design jest prawdopodobnie ważniejszy teraz niż kiedykolwiek wcześniej, może być jednak bardzo nieefektywną częścią rozwoju produktu. Mimo swojej ważności, intencja projektowa może być trudna do przeniesienia do produkcji.

Chad Bergman wyjaśnia fundamentalną różnicę: projektowanie i budowanie to różne procesy. Projektowanie produktu wymaga ekspresji, odkrywania i iteracji. Znacznie łatwiej iterować w elastycznym stanie – narzędzia projektowe zapewniają właśnie tę elastyczność.

Z kolei kod produkcyjny to precyzja i wykonanie, nie eksploracja. Dwa różne środowiska są potrzebne, żeby stworzyć dobry produkt. Nowe narzędzia jak Figma Make pozwalają kodowi być też medium do odkrywania i zwiększają wierność doświadczenia. To jednak wciąż bardzo różne od kodu produkcyjnego.

Dlatego „idealny kod to często nie ten idealny pikselowo” – jak tłumaczy Albaugh. Idealny kod to taki, który jest dopasowany do intencji projektowej. Projekt, nie piksele.

Naturalna ewolucja wzorców w kodzie

Albaugh zwraca uwagę na ważne spostrzeżenie: zespoły we wczesnym etapie tworzą własne wzorce, czy tego chcemy czy nie. Jako ludzie od systemów projektowych możemy patrzeć na to jak na „systemy projektowe dla początkujących”, jest to jednak w rzeczywistości emblematyczne dla etapu wzrostu aplikacji.

„To w rzeczywistości emblematyczne dla aplikacji i etapu wzrostu aplikacji, gdzie rozważasz użytkownika, iterujesz, uczysz się dokładnie tego, co budujesz. Myślę, że to w rzeczywistości zdrowa rzecz, gdy znajdziesz się w tym rodzaju stanu” – tłumaczy Jake.

W rezultacie mamy naturalny etap, w którym zespół uczy się tego, co buduje.

Przykład z kolumnami

Albaugh pokazuje prosty przykład czterech kolumn. Wizualnie można je opisać jako wypełnienie kontenera, 400 pikseli, 1/4 czy 25%. W kodzie również istnieje wiele sposobów – flexbox, kalkulacje z uwzględnieniem odstępów między kolumnami.

Jednak te ćwiartki mogą stać się tercjami na innych urządzeniach. Nagle ładne, okrągłe wartości stają się skomplikowane w kodzie. Dlatego trzeba abstrakcji.

„Projekt i kod są optymalizowane różnie” – podsumowuje Albaugh. To nie problem, lecz dobra rzecz. Podchodzimy do tego samego celu z różnych punktów wyjścia.

Wspólna miłość do wzorców

Mimo różnic, projektanci i programiści dzielą jedno: miłość do wzorców. Nie ma nic gorszego niż spędzenie czasu na tworzeniu czegoś, zmiana zdania i manualne aktualizowanie w wielu miejscach.

Wzorce rozwiązują ten problem. Robimy abstrakcje, żeby ułatwić budowanie – wzorce behawioralne, wzorce typograficzne, struktury plików, konwencje nazewnictwa czy architekturę informacji.

Chad Bergman zauważa: „wzorce tworzą efektywność”. Wynikają z dopasowanych, powtarzalnych decyzji. Kiedy możemy coś powtarzać, stajemy się szybsi i mniej sfrustrowani.

Wzorce działają również dla użytkowników końcowych. To dążenie skoncentrowane na człowieku. W kontekście systemów projektowych myślimy o przyszłym utrzymaniu tego, co tworzymy – ktoś będzie musiał to obsługiwać.

Jak systemy dojrzewają

Bergman przypomina: twój system projektowy, w jakim stanie by nie był, jest rzeczywisty i odpowiada na obecne potrzeby. To ważne spostrzeżenie. Rozwiązujemy potrzeby dzisiejsze, nie budujemy skomplikowanych systemów w oczekiwaniu na hipotetyczne przyszłe przypadki użycia.

Zespoły produktowe zwykle poruszają się szybciej niż zespoły systemów projektowych. W rezultacie przyszłe potrzeby można adresować, gdy się pojawią.

Kiedy systemy rosną

Z czasem każdy system napotka nowe przypadki użycia i będzie musiał rosnąć. Rzeczy zaczynają się dziać jedna po drugiej – dodajemy zmienne do biblioteki, tworzymy nowe komponenty, niebieskie przyciski nagle mają osiem wariantów, skalę rozmiarów T-shirt trzeba rozszerzyć między średni a duży.

„Dotarcie do granicy może być znakiem wzrostu” – tłumaczy Bergman. System nie jest zepsuty – dojrzewa.

Nie używamy już tylko kolorów czy komponentów, lecz budujemy większe, bardziej połączone, komponowalne wzorce. Karty z różnymi wariantami, okna modalne z różnymi zachowaniami, powiadomienia z kontekstowymi ikonami.

Wyzwania złożoności

Gdy systemy ewoluują, współpraca i dopasowanie stają się jeszcze bardziej kluczowe. Jedna zmiana zmiennej może dotknąć pięć innych miejsc. Prosta aktualizacja może zepsuć wzorzec, a nowy wariant musi działać w trybie jasnym, ciemnym, wysokim kontraście, niskim kontraście, czterech różnych gęstościach i spełniać standardy dostępności.

Case study: VHS Vault w praktyce

Albaugh i Bergman pokazują praktyczny przykład – VHS Vault, firmę do wypożyczania kaset VHS przez pocztę. Mają stronę główną, stronę produktu, proces zakupu i konto użytkownika.

Ewolucja od stylów do Variables

Na początku mieli proste style kolorów z nazewnictwem jak „Green 300”. Gdy na stronie deweloperskiej wprowadzili tryb ciemny i tokeny projektowe, projektanci zdecydowali się na wprowadzenie Variables dla zachowania równości.

Problem? Te same kolory reprezentowane w wielu miejscach. Rozwiązanie: zmienne o ograniczonym zasięgu, żeby projektanci widzieli tylko potrzebne im kolory w danym momencie. Na przykład przy edycji obramowania widoczne były tylko tokeny przeznaczone dla obramowań – taka drobna zmiana znacząco poprawia doświadczenie projektanta.

Code Syntax – ulubiona funkcja Jake’a

W bazie kodu używają prefiksów (RW dla Rewind) do organizacji zmiennych. Figma tego nie wie, ma jednak Code Syntax – funkcję do manualnego dodawania składni dla różnych platform.

Albaugh napisał skrypt, który automatycznie ustawia Code Syntax dla wszystkich zmiennych przez konsolę JavaScript. Rezultat? Kod generowany w Figmie ma kontekst rzeczywistej bazy kodu.

Typografia jako tokeny złożone

Bergman wyjaśnia, dlaczego wciąż używają stylów dla typografii: style działają jak tokeny złożone. Można łączyć wiele zmiennych razem i dystrybuować przez jeden styl.

W kodzie typografia jest aplikowana inaczej – przez nazwy klas CSS. H1 ma semantyczne znaczenie dla hierarchii i dostępności, może jednak mieć różne style wizualne w zależności od kontekstu.

Komponenty: przyciski, powiadomienia i złożoność

Przycisk z ikoną

W kodzie przycisk z ikoną ma inny padding po lewej dla optycznego wyrównania. Programista myśli prosto: domyślny padding to zmienna button-padding-x, z ikoną – kalkulacja, która dzieli przez dwa.

Na stronie projektu to bardziej skomplikowane. Można tworzyć warianty, ale przycisk z trzema kolorami i opcją ikony to już 16 wariantów. Z ikoną na końcu? 32 warianty. Z obiema opcjami? 64.

Rozwiązanie: podejście przez właściwości, bardziej dopasowane do kodu. System automatycznie obsługuje przesunięcie ikony w ramce.

Komponent powiadomień – złożoność świata rzeczywistego

Bergman pokazuje prawdziwy problem: programista stworzył powiadomienie z niestandardowym kolorem, używając niestandardowych właściwości CSS do nadpisania wewnętrznego stylu. Technicznie zrobił to, co było zaprojektowane, wykorzystał jednak „lukę” w komponencie.

W systemie była dziwna „ziemia niczyja” – brak koloru tła, ale możliwość niestandardowej ikony. Programista zorientował się, że bez nacisku może podać niestandardową ikonę.

Rozwiązanie: utworzenie nowego wariantu dla niestandardowych powiadomień z odrębną ikoną i tekstem, ale w kontrolowany sposób.

Figma Make jako narzędzie eksploracji

Bergman testuje Make do generowania inspiracji dla galerii obrazów. Prompt: dostępna karuzela obrazów dla maksymalnie 8 obrazów z wybranym obrazem w formacie 16:9.

Albaugh podkreśla kluczową zasadę: „jedną z najlepszych rzeczy, które możesz zrobić, to wcześnie włączyć programistę” przy projektowaniu czegoś nowego. To odkrywa możliwości projektowe i potencjalne ograniczenia.

Make może pomóc w tym samym celu – wczesne odkrywanie możliwości projektowych. Może pokazać interakcje klawiatury, przyciski do przełączania, zagadnienia dostępności czy rzeczy, których można nie uwzględnić w pierwszym podejściu.

Narzędzia dla dopasowania

Zmienne i Code Connect

System VHS Vault używa zmiennych połączonych z Code Connect. W trybie deweloperskim projektanci widzą rzeczywisty CSS z kontekstem bazy kodu, nie tylko abstrakcje Figmy.

Automatyzacja Plugin API

Albaugh napisał skrypty, które eksportują wszystkie zmienne jako JSON, analizują JSON i tworzą pliki CSS oraz automatycznie ustawiają Code Syntax dla wszystkich zmiennych.

„To sposób, w jaki współpraca między projektowaniem a programowaniem może pomóc tworzyć niektóre z tych wzorców po stronie kodu” – wyjaśnia Albaugh.

Dopasowanie jako ciągły proces

Bergman podkreśla kluczowe spostrzeżenie: dopasowanie to nie jednorazowa rzecz. To niezbędne, żeby mieć dopasowanie przed tym, jak zaczynamy projektować czy budować, podczas procesu i nawet po jego zakończeniu.

„Nasze dopasowanie musi być ciągłe, szczególnie z perspektywy systemów, ponieważ nasze dopasowane decyzje to właśnie to, co staje się naszymi wzorcami” – wyjaśnia Chad.

Oparcie się na wzorcach pomaga poruszać się szybciej, z mniejszym tarciem i większą pewnością siebie. To właśnie wzorce pomagają sprawić, żeby następna rzecz była łatwiejsza do zbudowania niż poprzednia.

Wszystko, co robisz dzisiaj, żeby ułatwić ludziom korzystanie z twojego systemu, będzie pomocne także dla każdych narzędzi, których będziesz używać w przyszłości.

Simple Design System jako przykład dopasowanych systemów

Jake promuje Simple Design System jako przykład doskonałego dopasowania między projektowaniem a kodem. „Louie i ja zbudowaliśmy to razem, zarówno projektując kod na zeszłoroczną konferencję” – wyjaśnia, wskazując na podejście współpracy.

„To świetny przykład wielu integracji dopasowanych do wielu zmiennych, które są dopasowane między projektowaniem a kodem, komponentów, które są idealnie dopasowane między projektowaniem a kodem” – opisuje Jake. To aspiracyjny stan dla większości zespołów, „coś jak nasza mała piaskownica-ciężarówka w wersji systemu projektowego”.

Zasoby dostępne na GitHub.com/figmasds zawierają kod Plugin API i przykłady integracji REST API – praktyczne narzędzia dla zespołów chcących testować podobne podejścia.

Wzorce jako fundament

Chad Bergman podsumowuje kluczowe spostrzeżenie: „nasze dopasowane decyzje to właśnie to, co staje się naszymi wzorcami”. Oparcie się na wzorcach pomaga poruszać się szybciej, z mniejszym tarciem i większą pewnością siebie.

Systemy projektowe pomagają uczynić intencję projektową rzeczywistą na skalę. Nie tylko przez namacalne zasoby, lecz przez wspieranie kultury wspólnego zrozumienia.

Jake Albaugh dodaje perspektywę: w czasach, gdy tak wiele się zmienia w sposobie pracy, ważne jest zaczynanie od tego, co zawsze zostanie takie samo. Projekt jest ważny. Systemy projektowe to abstrakcje, które pomagają ten projekt urzeczywistnić.

Wspólne zrozumienie jako klucz

Ostateczna obserwacja dotyczy całego rozwoju produktu: wspólne zrozumienie jest kluczowe nie tylko dla systemów projektowych, lecz dla całego procesu tworzenia produktu.

„Jest to zorientowane na rozważanie doświadczeń ludzi, czy to projektantów, programistów, czy tych, którzy słysząc o operacji Boolean myślą: och, wow, tej jeszcze nie widziałem” – mówi Bergman.

„Koniec jest taki, że nasza najlepsza praca jest wykonywana razem” – jak podsumowują eksperci Figmy.

Praktyczny przewodnik współpracy

Jake i Chad napisali artykuł „lepsze współdziałanie razem” – taktyczny przewodnik dla projektantów i programistów przez cały proces przekazania. Artykuł omawia częste pułapki, praktyczne wskazówki dla współpracy i wskazówki na temat tego, kiedy polegać na ekspertyzie drugiej strony.

To praktyczne uzupełnienie filozoficznych rozważań z prezentacji – konkretne narzędzia do implementacji wspólnego zrozumienia w codziennej pracy.

Prompty AI dla systemów projektowych – praktyczne zastosowania

Chad Bergman pokazał w prezentacji konkretny przykład użycia Figma Make. Prelegenci używają narzędzi AI nie do tworzenia finalnych projektów, lecz do eksploracji wymagań na wczesnym etapie. Oto prompt i kontekst jego zastosowania:

Prompt: Eksploracja galerii obrazów

„Daj mi kilka nowych sposobów podejścia do tego z dostępną karuzelą obrazów, która może mieć do 8 obrazów i pokazuje wybrany obraz w formacie 16 na 9″

Kiedy i dlaczego stosować takie prompty:

Do szybkiej eksploracji i inspiracji – gdy zespół utknie przy jednym pomyśle, AI może w kilka sekund wygenerować alternatywne układy
Do odkrywania ukrytych wymagań – wygenerowane propozycje, nawet niedoskonałe, zmuszają do zadawania dalszych pytań o nawigację, liczniki czy dostępność
Jako punkt wyjścia do rozmowy z programistą – zamiast prezentować jeden dopracowany projekt, można pokazać kilka koncepcji do wspólnego omówienia

Dlaczego to działa: Jak wyjaśnia Jake: „Make może pomóc w tym samym celu – wczesne odkrywanie możliwości projektowych”. AI może pokazać interakcje klawiatury, przyciski przełączania, funkcje dostępności, które można przegapić w pierwszym podejściu.

Ważne zastrzeżenie: Chad i Jake podkreślają, że używają AI do inspiracji i eksploracji, nie jako ostatecznego rozwiązania. Ostatecznie aplikują „dotyk naszego systemu”, żeby wszystko było spójne.

Najlepsze praktyki dla AI w systemach projektowych:

Używaj AI do wczesnego odkrywania, nie końcowego projektu
Traktuj wynik jako punkt wyjścia do dyskusji z programistami
Zawsze aplikuj wytyczne marki i systemu do sugestii AI
Wykorzystuj spostrzeżenia AI do odkrywania przypadków granicznych
Włącz programistę wcześnie – AI może pokazać, co potrzebujesz omówić z zespołem technicznym

Kluczowy insight

Niestandardowe rozwiązania są mapą drogową

Standardowo myślimy: Gdy ktoś „łamie” system lub tworzy niestandardowe obejścia, jest to błąd, który trzeba jak najszybciej naprawić.

W praktyce okazuje się, że: Te obejścia i nieprzewidziane zastosowania to najcenniejsza informacja zwrotna. Są to bowiem realne potrzeby produktowe, które próbują się zamanifestować, pokazując, w którym kierunku system powinien ewoluować.

Dlaczego to jest istotne: Zmienia to relację z użytkownikami systemu z konfrontacyjnej (egzekwowanie zasad) na partnerską (uczenie się od nich). System przestaje być twierdzą, a staje się żywym organizmem.

Test na jutro: Następnym razem, gdy odkryjesz, że ktoś w zespole użył komponentu w nieprzewidziany sposób, zamiast go po prostu poprawiać, zadaj pytanie: „Jaki problem próbowałeś rozwiązać?”. Potraktuj odpowiedź jako specyfikację dla następnej iteracji tego komponentu.

Lista kontrolna: na co zwrócić uwagę przy budowaniu systemów

Zakres i odpowiedzialność

Kto podejmuje ostateczne decyzje? Co w systemie ma być sztywne, a co elastyczne?
Właścicielstwo wzorców – czy dany element powinien trafić do głównego systemu, czy na razie pozostać po stronie zespołu produktowego?
Planowanie kaskadowych zmian – jak minimalizować ryzyko wprowadzenia zmian łamiących kompatybilność?

Ograniczenia i przypadki brzegowe

Ocena wpływu – czy przeanalizowano wpływ planowanych zmian na resztę systemu?
Niewidoczne stany – jak system obsłuży treści dodawane przez użytkowników? Czy uwzględniono wszystkie stany formularzy, ładowania czy błędów?
Elementy kluczowe w kodzie – czy projekt uwzględnia stany skupienia, kolejność tabulacji, etykiety i role ARIA?
Zachowanie responsywne – jakie rozwiązania techniczne (Flexbox vs Grid) będą najlepsze?

Narzędzia i automatyzacja

Zakres zmiennych – ograniczyć widoczność tylko do potrzebnych kolorów w danym kontekście
Konfiguracja Code Syntax – mapować zmienne Figmy na rzeczywiste konwencje bazy kodu
Dokumentacja – udokumentować nazwy klas CSS i właściwości komponentów
Automatyzacja procesów – rozważyć skrypty eksportujące zmienne i inne procesy

Współpraca projektant-programista

Wczesne włączanie programistów – odkrywanie możliwości projektowych i ograniczeń technicznych
Wspólne zrozumienie – wspólne rozumienie wzorców i ich celów
Dotyk vs automatyzacja – świadome decyzje co automatyzować, a co zostawić ludzkiemu dotykowi
Przyszłościowość – rozwiązywać dzisiejsze problemy, nie hipotetyczne przyszłe

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Config 2025: Building design systems together with Jake Albaugh & Chad Bergman | Figma

Tag: Dev Experience

Design systems: jak designer i developer mogą budować razem #EN221