Poniższe notatki pochodzą z serii podcastów „Design Systems at Scale” z udziałem Brad Frost (frontend developer), Josh Clark (product director, Big Medium) i Dan Mahl (creative director, Super Friendly). Wszystkie przemyślenia, obserwacje i strategie przedstawione w artykule to doświadczenia i wiedza ekspertów z branży projektowania cyfrowego.

TL;DR

Prawo Galla – każdy działający złożony system powstał z prostego; nie buduj kompleksowego systemu od razu
Chaos projektowy – digital design ma teraz wszystkie problemy dużych organizacji; design systems rozwiązują duplikację pracy
Interface inventory – systematyczne dokumentowanie wzorców UI przez zespoły to fundament diagnozy problemu
Sprzedaż wartości – mów językiem stakeholdera (efektywność dla managerów, ROI dla boardu)
Najlepsze systemy są nudne – składają się z komponentów budowanych tysiące razy; to kuracja, nie inwencja
Piloty wymagają championów – design systems to przede wszystkim ludzie, nie kod
Współpraca ponad enforcement – żadna dyscyplina nie może używać systemu sama
Cyclical governance – najlepsze organizacje mają design systems, jednak system nie czyni organizacji najlepszą

Kiedy design staje się problemem organizacyjnym

Większość firm zaczyna swoją przygodę z prostej sytuacji – jeden zespół, jeden produkt, jedna marka. Według Josh Clark, w takich warunkach wszyscy znają system od podszewki. Trzech ludzi pracujących nad projektem ma pełną kontrolę nad tym, jak funkcjonuje.

Prawo Galla o systemach

Clark przytacza fundamentalne prawo John Galla (pediatrę!): „każdy złożony system, który działa, niezmiennie został stworzony z prostego systemu”. Z kolei każdy złożony system budowany od razu jako złożony zawsze się psuje i nie da się go naprawić.

Dlatego też dla design systems kluczowe jest rozpoczęcie od prostego fundamentu i stopniowe rozwijanie. Nie można od razu budować kompleksowego, wszystko-obejmującego systemu.

Zarządzanie złożonością

Problem pojawia się wraz ze skalą organizacji. Clark ma kluczowe spostrzeżenie o ewolucji designu: „Gdy digital design stał się częścią fabric of business i organizacji, design stał się tak złożony jak same organizacje”. To oznacza, że design teraz jest pełen dysfunction, problemów, wonder i joy każdej dużej organizacji.

Wyzwanie nie jest tylko techniczne – to organizacyjne, kulturowe i procesowe. Clark definiuje problem jako „heartache of design at scale”, szczególnie dla większych organizacji pracujących nad dużymi projektami czy seriami produktów.

Dan Mahl podkreśla, że zmienił się też charakter projektów. Dwadzieścia lat temu firmy prosiły o „jedną stronę internetową”. Dzisiaj jednak zarządzają kilkunastoma mikroserwisami, aplikacjami, intranetami i ekstranetami jednocześnie.

W rezultacie powstaje chaos – zespoły rozwiązują te same problemy wielokrotnie, tworząc podobne, ale nieidentyczne rozwiązania. To marnowanie energii, czasu i talentów.

Interface inventory – diagnoza problemu

Brad Frost proponuje konkretne narzędzie diagnozy: interface inventory. To systematyczne dokumentowanie wszystkich wzorców UI w organizacji.

Lista kontrolna: Interface Inventory w 5 krokach

1. Zbierz wszystkich

Designerzy, developerzy, product managerzy, testerzy QA
Wszyscy odpowiedzialni za sukces produktów cyfrowych
Różne dyscypliny często nie mówią tym samym językiem

2. Przygotuj narzędzia

Google Slides (zalecane) lub inne narzędzie do screenshotów
Wspólne miejsce do kategoryzowania wzorców
Szablon do segregacji według kategorii UI

3. Podziel zadania według kategorii

Jedna osoba = jedna kategoria (headers/footers, przyciski, formularze)
Dodatkowe kategorie: typografia, animacje, media, third-party widgets
Każdy wie dokładnie, czego szuka

4. Poluj na wzorce

Zagłębiaj się w „ciemne zakątki” produktów
Szukaj w każdym możliwym miejscu – tam kryją się niespójności
Rób screenshoty wszystkich unikalnych wzorców

5. Prezentuj wyniki

Każdy prezentuje swoje znaleziska zespołowi
Tu rodzi się wspólny słownik terminów
Stwórz jeden „Uber document” ze wszystkimi wzorcami

Efekt końcowy: Dokument pokazujący np. 70 różnych stylów przycisków. Jak zauważa Frost: „nie musisz być designerem, żeby zrozumieć, że 70 różnych stylów przycisków to zły pomysł”.

Korzyści design systems

Frost wymienia konkretne korzyści systemowego podejścia:

Spójność UI i kohezja – użytkownicy mogą wykonać to, co chcą
Szybsza produkcja – zespoły produkują wyższą jakość w krótszym czasie
Wspólny słownik między dyscyplinami i procesami
Łatwiejsze testowanie – tworzysz mocniejsze, bardziej odporne rozwiązania
Użyteczna referencja – stałe miejsce powrotu podczas projektowania
Future-friendly foundation – fundament do rozwoju w czasie

Co zawiera design system

Frost wyjaśnia, że design system to znacznie więcej niż komponenty:

Fundamenty:

Design principles i design tokens
High-level UX guidelines i development guidelines
Brand guidelines i voice and tone guidelines
Writing guidelines

Komponenty i wzorce:

UI patterns i page templates
User flows i common scenarios
Integration z design tools (Sketch libraries, InVision Studio)

Procesy i zasoby:

Deployment processes i contribution workflows
Internal/external resources i wiki links
Industry best practices i educational materials

Wszystkie te składniki współpracują, żeby opowiedzieć „canonical story” o tym, jak organizacja projektuje i buduje produkty.

Design system jako wzmacniacz jakości

Clark podkreśla nieoczywistą korzyść: „Wyraźną korzyścią jest improved consistency, improved quality, improved accessibility, którą dostajesz, zamiast ciągle wynajdować, constantly improving on them gradually, więc wszystkie twoje produkty dostają te benefity”.

Gdy przestajesz ciągle wynajdować od nowa, a zamiast tego stopniowo ulepszasz istniejące rozwiązania, wszystkie produkty automatycznie dostają te ulepszenia. Dotyczy to szczególnie accessibility – raz dobrze zrobione, wszędzie dostępne.

Future-friendly foundation

Frost podkreśla długoterminowe korzyści: design system „provides a future friendly foundation to grow and evolve the system over time”. To nie tylko o dzisiejszych produktach, ale o przygotowaniu na przyszłość.

Design system to zatem platforma do ewolucji. Gdy pojawią się nowe wymagania, nowe technologie, nowe sposoby interakcji, masz fundament, na którym można budować.

Najlepsze design systems są nudne

Josh Clark ma kluczowe spostrzeżenie: „Myślę, że najciekawsze design systems są nudne. Nie mam na myśli, że tworzą nudne produkty. Mam na myśli, że składają się ze wszystkich nudnych komponentów, które wszyscy budowali już tysiąc razy”.

To nie czas na tworzenie czegoś nowego, ale na zebranie najlepszej pracy z całej organizacji. Design system to kuracja, nie wynalazek.

UI kit to nie design system

Mahl podkreśla częsty błąd: „Pracujemy z wieloma designerami i zespołami projektowymi, a ich pierwszy instynkt co do tego, czym jest design system, to UI kit. I to nie jest design system”.

UI kit może być częścią design system, ale sam w sobie nie jest design system. Główne problemy z UI kit jako design system:

To tylko jedno narzędzie, z którego mogą korzystać tylko designerzy
Jest zamknięty w konkretnym narzędziu (Sketch, Photoshop)
Nie jest dostępny dla wszystkich w zespole
Dobry design system to narzędzie, z którego może korzystać każdy w zespole

Mahl dodaje niebezpieczeństwo: UI kit wzmacnia to, co designerzy robią zawsze – zostają w swojej strefie komfortu. Dobry design system wyciąga wszystkich trochę poza strefę komfortu, żeby lepiej ze sobą współpracować.

Sprzedawanie wartości design system

Przekonanie organizacji do inwestycji w design system to często najtrudniejsza część. Mahl podkreśla kluczową zasadę: musisz mówić językiem osoby, do której się zwracasz.

Różne poziomy, różne argumenty

Jeśli sprzedajesz szefowi zespołu designu, mów o efektywności. Jednak jeśli trafiasz do boardu, potrzebujesz twardych danych o ROI.

Mahl przytacza przykład z Seventh Day Adventist Church. Menedżer web wydrukował wszystkie strony internetowe zrobione w ciągu roku na karteczkach 3×3 cale. Następnie kilkaset kartek przymocował do czarnych tablic i przyniósł do szefa. Jego przesłanie: „oto ile pieniędzy marnujemy”. W rezultacie wyszedł z budżetem na design system.

Konkretne metryki i case studies

Clark podaje twarde liczby z projektów:

Duży retailer tworzy produkty 10 razy szybciej z zespołami 4 razy mniejszymi
ExxonMobil zbudował 50 nowych aplikacji w ciągu pierwszych 10 miesięcy po wdrożeniu Unity design system

Kluczowe argumenty biznesowe:

Oszczędność kosztów (teams can do more with same budget)
Przyspieszenie produkcji (konkretne metryki 10x)
Lepsza jakość produktów przez konsystencję
Większa dostępność (accessibility) automatycznie wbudowana
Możliwość przeniesienia zasobów na inne projekty

Strategia „asking forgiveness, not permission”

Frost proponuje praktyczne podejście, gdy nie możesz przekonać kierownictwa. „Jestem wielkim fanem proszenia o wybaczenie, nie o pozwolenie”.

Zespoły mają zadanie zbudować produkt. Mimo to, jak to zrobią, jest drugorzędne. Możesz po cichu zastosować systematyczne podejście, użyć reusable components, stworzyć solid foundation.

Po sukcesie produktu powiedz: „Chodź, pokażę ci, co faktycznie zrobiliśmy, żeby to stworzyć”. Pokazujesz robust, flexible, accessible komponenty używane wielokrotnie. Teraz masz case study, nie tylko pomysł.

Grassroots vs top-down approaches

Mahl podkreśla znaczenie kultury organizacyjnej. Design systems mogą powstawać:

Grassroots – garstka designerów/developerów tworzy standardy i narzędzia, system rośnie oddolnie

Top-down – CEO/VP mówi „używamy tego design system, wszyscy muszą teraz”, ludzie się trochę denerwują

Kluczowe jest dopasowanie podejścia do kultury organizacji. Nie ma uniwersalnego rozwiązania.

Unikaj zakochania się w narzędziu

Mahl ostrzega przed jednym błędem: nie sprzedawaj design system tym, którzy się nim nie przejmują. Jak w powiedzeniu o wiertarce – nikt nie chce wiertarki, wszyscy chcą dziurę w ścianie. A właściwie – powiesić obrazek.

Dlatego też zamiast mówić „potrzebujemy design system”, mów „pomożemy wam zbudować ten produkt szybciej i lepiej”.

Atomic Design – metodologia strukturyzacji

Brad Frost stworzył metodologię Atomic Design, inspirowaną tym, jak zbudowany jest naturalny świat. Wszystko – nasze ciała, podłoga, gwiazdy – składa się z tych samych podstawowych elementów.

Pięć poziomów hierarchii

Atomy Podstawowe elementy interfejsu: przyciski, pola formularzy, obrazki, nagłówki. Nie da się ich podzielić bardziej bez utraty funkcjonalności.

Molekuły Grupa atomów tworzących prostą funkcjonalność. Etykieta + pole input + przycisk = formularz wyszukiwania lub newsletter signup.

Organizmy Złożone komponenty składające się z molekuł i atomów. Header może zawierać logo (atom), nawigację (molekułę) i formularz wyszukiwania (molekułę).

Szablony Organizmy układają się w pełne ekrany, jednak bez konkretnej treści. To „szkielet” interfejsu.

Strony Szablon wypełniony prawdziwą treścią. To widzi użytkownik końcowy.

Frost podkreśla, że myślenie atomowe pomaga budować dla wielokrotnego użytku. Gdy tworzysz prawdziwy produkt używając tych samych komponentów, naturalnie sięgasz po istniejące elementy zamiast tworzyć nowe.

Wybór projektu pilotażowego

Mahl porównuje piloty design system do pilotów seriali TV. Nie robisz całego sezonu – testujesz koncept na jednym odcinku.

Karta oceny projektów pilotażowych (oceń każdy projekt 1-10)

1. Powszechność użycia – czy komponenty będą używane w wielu produktach?
2. Wysokowartościowe komponenty – czy element jest czasochłonny do budowania?
3. Wykonalność techniczna – czy projekt wymaga dużego refaktoringu?
4. Dostępny champion – kto będzie promował sukces w organizacji?

Kluczowe: Design systems to nie tylko komponenty, patterns i principles. To przede wszystkim ludzie – ludzie, którzy mogą być championami tych rzeczy. Dobry projekt pilotażowy ma dobrego championa, który po zakończeniu będzie mógł pokazać resztę firmy i powiedzieć: „zobacz, jak zrobiliśmy świetną rzecz” i być ewangelistą.

5. Zakres – czy da się zrobić w kilka tygodni?
6. Niezależność techniczna – czy można zrobić bez przepisywania całego systemu?
7. Potencjał marketingowy – czy wszyscy będą patrzeć i mówić „my też chcemy”?

Jak użyć: Oceń każdy potencjalny projekt w skali 1-10 dla każdego kryterium. Następnie wybierz 3 projekty z najwyższymi wynikami.

Style guide website – warsztat i wystawa

Clark używa analogii do warsztatu i wystawy swojej żony – jubilerki.

W warsztacie może być bałagan, eksperymentuje, próbuje, pali, tnie. To miejsce tworzenia. Z kolei wystawa to uporządkowane miejsce prezentacji gotowych dzieł z informacjami dla klientów.

Workshop vs storefront

Workshop – środowisko dla twórców design system: miejsce na prototypowanie, testowanie odporności komponentów, iteracje i eksperymenty.

Storefront – style guide website: prezentacja gotowych komponentów, dokumentacja użycia, instrukcje dla różnych zespołów, przykłady kodu.

Clark podkreśla, że style guide website to „single source of truth” – miejsce, gdzie każdy znajdzie aktualne informacje o tym, jak organizacja tworzy produkty.

Technology agnostic approach

Frost zauważa kluczowy problem: frameworki przychodzą i odchodzą jak letnia moda. Jeśli zwiążesz design system z konkretną technologią, za rok może się okazać nieobyty.

Rozwiązanie: HTML/CSS/JavaScript jako fundament

Kanoniczny design system bazuje na technologiach webowych – HTML, CSS, JavaScript. To wysyłane do przeglądarki, to widzi użytkownik.

Na tym fundamencie budowane są „technologiczne smaki”:

React flavor design system
Angular flavor design system
Drupal flavor design system

Design tokens działają jak klej – to niezależne od implementacji właściwości projektowe (zmienne jak color-brand-red czy border-radius-standard). InVision Design System Manager pozwala designerom definiować tokeny w znanych narzędziach, a developerom – pobierać je do swojego workflow’u.

Transformacja ról i procesów

Design system fundamentalnie zmienia sposób pracy zespołów. Clark opisuje swoją ewolucję: przestał robić wireframe’y, zastąpił je prostą listą tekstową.

Różne interfejsy do design system

Clark podkreśla ważny aspekt: „Design system ma kilka różnych interfejsów. Najbardziej publiczny to style guide czy reference site – strona, która wszystko łączy w jednym miejscu”.

Jednak są też individual tool interfaces:

Jeśli jestem designerem w InVision Studio czy Sketch, jak design system poprzez design tokens dociera do mojego narzędzia?
Jeśli jestem developerem, jak SASS variables automatycznie pobierają design system?

Kluczowe: Właściwa rzecz do zrobienia to easy thing to do. To część mojego workflow’u, nie muszę iść gdzie indziej. Nie muszę ściągać 2-letniego PDF-a, który może już nie być zsynchronizowany.

Praca równoległa designer vs developer

Mahl opisuje nowy model współpracy: „Często gdy pracujemy razem, Brad, ty jako developer mówisz: 'Ustawię ci placeholder, ale nie muszę przejmować się tym, jaki to konkretnie hex code’. To coś, co dla mnie jako designera jest ważne i powinienem móc tweakować do woli”.

Zamiast art directora siedzącego nad ramieniem developera („czy możesz zmienić ten hex color?”) czy wysyłania red lines, designer może tweakować tokens w swoim środowisku, a zmiany automatycznie się propagują.

Efekt: Oba zespoły mogą pracować równolegle. Designer pomaga developerowi, developer pomaga designerowi. To kolejny przykład tej współpracy.

Design system to praca zespołowa

Mahl podkreśla fundamentalną prawdę: „Design system to rzecz, której jedna dyscyplina nie mogłaby używać sama. Jeśli developer może używać design system sam, bez nikogo innego, może nie jest tak collaborative, jak powinien być. Jeśli designer może używać design system sam, może nie jest tak collaborative, jak powinien być”.

Każdy dobry design system będzie potrzebował wszystkich, żeby mogli wykonywać swoją najlepszą pracę. To nie narzędzie dla jednej grupy, ale platforma współpracy.

Nowy workflow interaction designera

Zamiast detaliowych wireframe’ów z adnotacjami, Clark pisze:

Jaki jest cel tej strony?
Jakie zadania musi wykonać dla biznesu?
Jakie zadania musi wykonać dla użytkownika?
Które komponenty z design system spełnią te cele?

Zmiana roli designera

Mahl zauważa, że często designer nie jest już potrzebny w procesie. Interaction designer i developer mogą pracować bezpośrednio, używając gotowych komponentów.

Brzmi strasznie? Wręcz przeciwnie. Designer dostaje lepszą pracę: motion design dla komponentów, custom ilustracje, art direction i sesje fotograficzne, krytyka końcowych rezultatów, rozwiązywanie nowych problemów projektowych.

To jest właśnie to, czego designerzy chcą – robić nowe rzeczy zamiast powtarzać stare.

Od pomysłu do prototypu w jednym spotkaniu

Clark przytacza konkretny przykład z ExxonMobil: „Inżynier powiedział nam: byłem na sesji przy tablicy, ustalaliśmy, co powinna robić aplikacja. Podczas tej sesji użyłem design system, żeby stworzyć działający prototyp. Normalnie to byłby początek 3-tygodniowego procesu, a tutaj przeszliśmy od pomysłu do prototypu w tym samym spotkaniu”.

To pokazuje transformacyjną moc design systems – nie chodzi tylko o konsystencję, ale o fundamentalną zmianę prędkości i sposobu pracy.

Design system nie jest panaceum

Frost przypomina ważną rzecz: „Design system nie jest panaceum, którą po prostu podłączamy i magicznie wszystko staje się perfekcyjne, nikt nie musi już myśleć”.

Getting first draft into browser pozwala zrozumieć, co każdy musi zrobić, żeby doprowadzić design do końca. Byproduct tego myślenia może być przekazany z powrotem do systemu. Każde użycie systemu to okazja do jego wzmocnienia i ulepszenia.

Skalowanie – co wchodzi do systemu

Gdy design system rośnie, pojawia się fundamentalne pytanie: czy każdy komponent w każdym projekcie musi być w systemie?

Frost proponuje praktyczne rozwiązanie: audytuj i zarządzaj, jednak pozwól na one-off components. Niektóre rzeczy – jak mortgage calculator – ma sens robić tylko dla jednego produktu.

Kluczowe zasady:

Jeśli modyfikujesz istniejący komponent (zmiana paddingu, bold labels) – to czerwona flaga
Jeśli tworzysz coś unikalnego dla produktu – może być one-off
Wszystkie one-offs umieszczaj w folderze „one-offs”
Regularnie audituj – może inne zespoły potrzebują podobnych rzeczy?

Workflow evolution: Użyj komponenty „as-is” w prawdziwym projekcie, sprawdź jak się sprawdza, jeśli brakuje behavior/style – stwórz variation (np. .data-table--striped), jednak nie modyfikuj core component.

Wielomarkowe i wieloplatformowe systemy

Clark przytacza przykład wydawcy z kilkoma tytułami – eleganckim magazynem mody i czasopismem politycznym. Na pierwszy rzut oka nie mają nic wspólnego, jednak funkcjonalnie to te same produkty – doświadczenia czytelnicze z podobnymi modelami nawigacji.

Funkcjonalność jest wspólna, różni się branding.

Mahl proponuje myślenie o markach jak o rodzinie. Mogą być rodzeństwem lub kuzynami, jednak powinny być rozpoznawalne jako część tej samej familii.

Wieloplatformowe rozwiązanie

Większe wyzwanie to spójność między webem, iOS i Androidem. Frost proponuje hierarchię:

Najwyżej: marka i visual language
Środek: platform-specific conventions
Najniżej: technologiczne implementacje

Design tokens pomagają utrzymać spójność właściwości subatomowych – kolorów, fontów, border-radius – między platformami.

Design principles – kompas decyzyjny

Clark podkreśla znaczenie design principles jako narzędzi decyzyjnych. Principles to połączenie celów biznesowych z obietnicami dla użytkowników.

Dobre vs złe design principles

Zły przykład: „Clean and simple” – nikt nie chce „messy and complicated”, więc taka zasada nie pomaga w podejmowaniu decyzji.

Dobre principles: Pomagają wybrać kierunek, gdy rozumna osoba mogłaby pójść w jedną lub drugą stronę. To rallying cries i przypomnienia o tym, co jest na naszej ścieżce.

Principles służą do podejmowania decyzji gdy masz dwie viable opcje. Mają być konkretne i praktyczne, nie uniwersalne oczywistości.

Governance – długoterminowe zarządzanie

Frost ostrzega przed najczęstszym problemem: design system powstaje z wielkim entuzjazmem, jednak szybko staje się nieaktualny i nikt go nie używa. Widział organizacje z „cmentarzyskami design systems” – kilkoma nieudanymi próbami z ostatniej dekady.

Cykl życia: produkty karmią system

Mahl podkreśla kluczową zasadę: „Jeśli pilot projects doprowadziły cię do design system, może pilot projects utrzymają ten design system przy życiu”.

Design system służy produktom i ma być produktem, który pomaga robić produkty. Więc keep making products, jednak nie w izolacji. Rób produkty z perspektywą: jak to wpływa na nasz design system?

Praktyczne checkpointy:

W środku projektu: czy używamy wszystkich rzeczy, których potrzebujemy z design system?
Na końcu projektu: co możemy zebrać z tego produktu z powrotem do design system?

To virtuous cycle – system i produkty ewoluują razem. Jak mówi Mahl: „myśl o tym jak o single system, gdzie budujesz produkt i wyciągasz użyteczne rzeczy do wielokrotnego użytku”.

Modele zarządzania

Single person model: Jedna osoba opiekuje się wszystkim. Dobry start, jednak nieskalowalny.

Centralized team model: Dedykowany zespół produktowy. Korzyść: systems thinking. Jednak ryzyko: utrata perspektywy zespołów produktowych.

Federated team model: Reprezentanci różnych zespołów. Korzyść: „on the ground” perspektywa. Jednak ryzyko: roadmapy produktowe zawsze wygrywają.

Cyclical model (Salesforce) – ZALECANY: Kombinacja centralized i federated. Centralny zespół + federated members w bliskiej współpracy.

Etsy committee model

Frost przytacza przykład committee’a spotykającego się raz w miesiącu: lider + właściciele produktów + reprezentanci platform + subject matter experts (accessibility, performance, responsive design). To daje przekrój stakeholderów i ekspertów dedykowanych rozwojowi systemu.

Najlepsze organizacje mają design systems

Clark zauważa istotny pattern: „Naprawdę wysokoperformancowe organizacje, które mogą konsekwentnie tworzyć nowe produkty i nową pracę, prawie wszystkie mają design system w jakiejś formie”.

Jednak uwaga na causation vs correlation: „Design system nie zrobi z was najlepszej organizacji. Część powodu, dla którego te design systems działają w tych organizacjach, to że są naturalnie do nich przystosowane”.

Mają kulturę, gdzie design system może zakorzenić się i procesy, gdzie mogą być używane. Dlatego przygotowanie do design system to nie tylko znalezienie funding, ale znalezienie sojuszników i przygotowanie nowego sposobu pracy.

Kultura otwartej współpracy

Clark podkreśla znaczenie kultury. Najlepsze organizacje mają naturalną skłonność do współpracy, dlatego design systems u nich działają.

Mahl zauważa, że nie każda organizacja może „przełączyć przełącznik” i stać się open source overnight. Można jednak budować stopniowo:

Praktyczne kroki:

Dedykowany Slack channel lub adres email
Regularne „State of the Union” meetings
Miesięczne newslettery z update’ami
Wyróżnianie MVP contributors
Transparent roadmap updates

Wspólny słownik jako jedna z supermocy

Clark podkreśla nieoczywistą korzyść: „Niesamowite jest to, że gdy masz design system, masz wspólny zestaw komponentów, które wszyscy rozumieją – designerzy, developerzy, UX designerzy – i wspólny zestaw nazw”.

Gdy wszyscy pracują razem, możesz po prostu nazwać rzeczy po imieniu: „potrzebujemy tutaj carousel, tam slideshow, tutaj card list”. Bez względu na nazwy, które wymyśliliście, możecie się do nich odwoływać.

Clark widzi przyszłość, gdzie tworzymy skrót do systemów projektowych. Zamiast długich opisów, możesz powiedzieć na głos lub nawet sfotografować wireframe, a machiny mogą zacząć tłumaczyć to na komponenty projektowe.

Airbnb eksperymentuje z machine learning, które bierze rysunki wireframe i mapuje je na design komponenty, które można umieścić na stronie. To pokazuje znaczenie fluency w wielu platformach projektowych.

Pokora jako fundament

Clark podkreśla znaczenie pokory: „Design system to nie 'mówimy wam, jak robić’, ale 'jesteśmy tu, żeby was wspierać. Czego potrzebujecie, żeby robić swoją pracę tak, jak chcecie?'”

Biggest way żeby ludzie czuli się invested w system to pozwolić im inwestować w niego. Sygnalizować „jesteśmy otwarci na ulepszenia”. Humility jest kluczową częścią tworzenia design system.

Przyszłość – voice i emerging technologies

Clark podkreśla, że „design system składa się z więcej niż tylko UI kit, pattern library i code library. To także wszystkie różne sposoby komunikacji i interakcji z klientami”.

Writing style guides i voice & tone

Design system powinien zawierać:

Writing style guide – jak organizacja pisze
Voice and tone guidelines – jaka jest osobowość komunikacji
Bot personality – jeśli masz chatboty, jaki mają charakter?
Standardowe frazy – jak robimy potwierdzenia, błędy, sukces

Voice interfaces i speechicons

Alexa ma „speechicons” – dźwiękowe odpowiedniki ikon. Design system może zawierać bibliotekę takich elementów, tak jak obecnie zawiera ikony graficzne.

Przykład: Alexa wie, jak powiedzieć „Bing!” – to speechicon. Możesz budować kolekcję takich flourish jako library, tak jak masz kolekcję ikon.

Emerging channels

Każdy nowy kanał komunikacji (speech, AR, VR) powinien mieć swoje guidelines i konwencje. Design system to miejsce, gdzie te konwencje żyją – jak najbliżej kodu.

Clark podkreśla: „Jako branża dopiero to odkrywamy, jednak twoja firma potrzebuje point of view, a design system powinien mieć ten point of view też”.

Kluczowy insight

Właściwe = najłatwiejsze

Standardowo myślimy: Design system to o zmuszaniu ludzi do używania standardów i egzekwowaniu compliance.

W praktyce okazuje się, że: Najlepsze design systems działają, gdy robią właściwą rzecz najłatwiejszą opcją do wyboru. Jak mówi Mahl: „Sposób, w jaki design system działa najlepiej i najlepiej się przyjmuje, to gdy budujesz go w sposób, gdzie właściwa rzecz do zrobienia jest także najłatwiejszą rzeczą do zrobienia.”

Dlaczego to jest istotne: Gdy właściwe działanie wymaga więcej wysiłku niż alternatywa, ludzie będą omijać system. Enforcement nie działa – convenience działa.

Test na jutro: Następnym razem gdy wprowadzasz jakiś standard w zespole, zamiast tworzyć reguły i egzekwować je, zastanów się jak zrobić właściwe działanie łatwiejszym niż wszystkie alternatywy i sprawdź czy adopcja jest naturalnie wyższa.

Ten wpis to notatki z serii podcastów „Design Systems at Scale” z udziałem Brad Frost, Josh Clark i Dan Mahl. Wszystkie przedstawione strategie i obserwacje pochodzą od ekspertów z branży projektowania cyfrowego.

Materiały źródłowe: https://www.youtube.com/watch?v=-5h05poX9CA&list=PLg3PPWk_HxdYoSs-vGEyNyVWwYv0rg-zm

Tag: Systemy Projektowe

Figma MCP to Storybook in Minutes: Webinar Notes with Banks & Petrie #EN348

Design Systems na dużą skalę – kompletny przewodnik #EN179