All language subtitles for Dlaczego Design Systemy są przyszłością UI - Michał Malewicz, HYPE4 | DesignWays Conf 2019

Witam was bardzo serdecznie w drugim dniu.

Sekunda,

kablem się.

Jesteśmy na ścieżce UI Design.

Jeszcze w kwestii organizacyjnych prelekcje

trwają 35 minut,

na koniec jest 10 minut na zadawanie pytań.

I co,

no nie przedłużając,

powiemy sobie o UI,

bo czego można się spodziewać na ścieżce UI Design.

Ale o UI w wydaniu design systemów.

Michał z Hype4 opowie trochę więcej,

dlaczego jest to przyszłością.

Dzień dobry.

Dobra,

od razu do rzeczy.

Najbliższe troszeczkę więcej niż 35 minut.

Zaczniemy od takich kilku rzeczy ogólnych związanych

z UI-em zanim przejdziemy do faktycznych design

systemów,

a potem w takiej formule odrobinę Pulp Fiction

poszatkowanej opowiemy sobie o design systemach

zupełnie nie po kolei,

czyli skupiając się najbardziej na bibliotekach

komponentów.

Dobra,

parę słów o mnie,

nazywam się Michał Malewicz,

bardzo dawno temu zacząłem projektować,

bo w 99 roku.

Jestem założycielem agencji Hype4,

która właśnie projektuje i koduje produkty

cyfrowe dla klientów z całego świata.

Poza tym udzielam się też w dwóch startupach,

STBits oraz Hypetask oraz piszę pierwszą polską

książkę o projektowaniu UI,

a w międzyczasie zajmuję się także zajęciami na SWPS,

warsztaty,

szkolenia,

w wolnych chwilach surfing i deskorolka.

Tak jak mówiłem,

zacząłem w 1999 roku.

To były takie czasy,

w których po internecie się jeszcze surfowało.

Teraz już się za bardzo tego określenia nie używa.

I nie było takich fajnych patentów.

a dodatkowo cały internet wtedy był bardzo dostępny,

dlatego że był tylko jeden sposób na zrobienie

klikalnego elementu,

po prostu wtedy niebieski lub fioletowy link.

Ale w tamtych latach mieliśmy dosyć toporne narzędzia.

I ja zaczynając moją pracę w 1999 roku jako

webdesigner dostałem informację,

że jeżeli jesteś designerem,

to musisz najpierw w Photoshopie poskładać layout,

a potem go zakodować w HTML-u.

i prawdziwym programistom przekazać pliki.

No i oczywiście w momencie kiedy zacząłem pierwszą

pracę kilka lat później w 2003 w firmie,

która się zajmowała już na szerszą skalę budowaniem

produktu cyfrowego,

jeden z takich pierwszych startupów tak naprawdę,

to troszeczkę mnie to przeraziło,

szczególnie,

że webdesignerów mieliśmy trzech,

prawdziwych programistów w cudzysłowie mieliśmy

znacznie więcej,

no i trzeba było jakoś zachować porządek pomiędzy

tymi grupami,

czyli trzeba było jakoś to uspójnić.

I my już wtedy zaczęliśmy stosować pewnego

rodzaju style guide'y,

pewnego rodzaju takie opisy,

które pozwalały nam tą strukturę zachować,

no ale oczywiście narzędzia były dosyć toporne,

więc nie było to proste.

W latach 2010-2017 w naszym trzyosobowym zespole

zbudowaliśmy kilkaset produktów.

I też taka ilość produktów dała nam dużo do myślenia,

w jaki sposób zapanować nad chaosem,

który się może pojawić w takich sytuacjach.

No i zdarzyło nam się też pracować nad produktami,

które miały tysiąc plus widoków.

I oczywiście tu nie chodzi o to,

że to były zupełnie różne widoki,

tylko bardziej o to,

że to były produkty np.

na wszystkie możliwe platformy łącznie z PlayStation.

I w takiej sytuacji,

kiedy mamy tak dużo widoków,

wyobraźmy sobie,

że zmienia się branding i nagle musimy wstawić

nowe logo albo nowy kolor na tysiąc ekranów ręcznie.

No i jest to trochę strata czasu i strata energii.

Dlatego właśnie już też wtedy zaczęliśmy myśleć o tym,

w jaki sposób tą pracę można systematyzować,

w jaki sposób ją można ogarniać.

No i można było powiedzieć,

że teraz wchodzi design system i wszystko naprawia,

ale w czasach,

kiedy to robiliśmy,

to nawet to określenie nie funkcjonowało jeszcze

aż tak mocno.

Więc zanim przejdziemy do design systemu,

zastanówmy się w jaki sposób UI może budować

zaufanie użytkownika jeszcze,

bo to jest coś,

co jest dla mnie dosyć istotne.

I taką podstawową kwestią w zadowolonym użytkowniku

jest połączenie kilku elementów.

Prawda jest taka,

że ten zysk,

czyli wartość lub potrzeba jest tak bardzo

najważniejsza z tego wszystkiego,

że nie ma znaczenia user experience.

Na zasadzie jeżeli zysk naszego produktu jest

tak wysoki,

że każdy będzie chciał go używać,

to przeskoczy przez każdy dark pattern,

przez każdy kiepsko zaprojektowany formularz

ze wszystkim sobie poradzi,

ale oczywiście na szczęście dla nas większość

produktów tego nie ma,

więc można się skupić na kilku pozostałych rzeczach.

No i wiadomo,

że jakaś łatwość użycia,

odpowiedni język,

ale też pewna jakość są istotne w tym,

żeby to zaufanie użytkownika zdobyć.

I teraz tak z naszych doświadczeń,

oczywiście może to wyglądać inaczej,

taki typowy proces projektowy obecnie wygląda tak,

że najpierw się planuje,

Potem robi się różne takie fajne gry i zabawy w salkach,

najczęściej bilowane za godzinę,

a kilka osób sobie siedzi parę miesięcy.

Potem się wymyśla swoich nowych przyjaciół,

tak jak persony.

Potem się robi makiety i jeżeli one są w takiej

formie dokładnej jak tutaj,

to i tak jest super,

bo bardzo często spotykaliśmy się z takimi nabazgranymi,

po prostu nabazgrołami,

z których nie da się zupełnie nic odczytać.

No i potem jeszcze oczywiście wchodzą statystyki,

które tak jak w tym przypadku mówią nam,

że konwersja wzrosła o 5%,

czyli chyba użytkownicy są zadowoleni,

a cele biznesowe są spełnione.

A potem trafiamy na tego typu przycisk,

tak,

bo spędzamy całą masę czasu na procesach,

a jednocześnie nie przywiązujemy wagi do tego

elementu końcowego.

I ten przycisk z napisem twoje konto,

to nie jest fake.

To znaczy zmieniłem kolor,

żeby się nie obraził autor,

dlatego że ten ich kolor jest na tyle specyficzny,

że każdy by od razu wiedział o jaki produkt chodzi.

I trochę zmieniłem napis,

ale generalnie tego typu przycisk ozdabiał

jedną z najpopularniejszych polskich aplikacji

mobilnych przez ostatnie cztery lata.

Ostatnio trochę to naprawili.

No i może jest to jakiś rodzaj designu,

o którym nie mam pojęcia,

ale generalnie tak.

No i teraz jakość interfejsów,

to jest coś,

o czym ja mówię od bardzo dawna i to jest coś,

na co staram się zwracać uwagę wszystkich,

dlatego że jest z tym faktycznie problem.

I to jest taki mój przykład ulubiony,

który pokazuję na prawie każdej prezentacji,

nawet jeżeli ona jest zupełnie nie na temat

UI-ów i UX-ów.

Na górze mamy przerysowanego iPhone'a 6 tam

sprzed kilku lat,

poniżej mamy odpowiadający mu telefon Samsunga.

Oczywiście wszystkie megapiksele,

wszystkie super rozdzielczościowe wyświetlacze,

wszystko to oba te telefony mają i to są topowe

smartfony ze swojego okresu.

I też oczywiście o wiele łatwiej jest poukładać

elementy w takim telefonie wewnątrz,

tak jak pasują do tego te komponenty.

O wiele trudniej jest przerobić te wewnętrzne

komponenty tak,

żeby one się ułożyły w jednej linii,

żeby to było równe,

symetryczne i przyjemne.

No i można było powiedzieć,

że jakie to ma znaczenie,

skoro to jest dół telefonu,

kto patrzy na dół telefonu,

liczą się megapiksele,

ewentualnie cena.

No więc ja patrzę,

a ten sam przykład można przenieść do

najpopularniejszego moim zdaniem problemu z UI-em,

jaki w ogóle istnieje,

czyli krzywego tekstu na przyciskach.

I można też pomyśleć,

no ale jakie to ma znaczenie,

o ile ten tekst jest czytalny,

to można go sobie kliknąć.

Znaczenie ma takie,

że taki użytkownik,

nawet jeżeli świadomie nie widzi,

że ten tekst jest nierówno,

to on przeczuwa,

że tutaj coś został lekko zrobiony w konia,

że tu jest jakiś taki niedobór jakości.

I to jest bardzo,

bardzo podstawowy problem.

No i to taka śmiała,

odważna teza,

że największy obecnie problem user experience

leży w niskiej jakości UI.

Oczywiście zakładamy tutaj,

że produkt został najpierw przebadany pod kątem tego,

czy w ogóle ma sens.

Bo wiemy bardzo dużo,

z racji tego,

że bardzo wiele podobnych produktów do naszego

już powstało,

wiemy bardzo dużo,

jak dobierać język,

jak zrobić logowanie,

jak zrobić sensownego chatbota albo użyć już gotowego.

Onboarding,

powiadomienia,

nawigacja,

mamy całą masę patentów,

co stosować,

czego nie stosować,

dlaczego hamburger menu z trzema opcjami nie

ma sensu itd.

Więc wiemy bardzo dużo,

a jednocześnie problemów z UI mamy całą masę.

I od razu mówię,

że dla mnie te przykłady,

które zaraz pokażę,

są dosyć drastyczne,

ale wszystkie zostały przez nas przekolorowane,

żeby się ktoś nie obraził,

bo raz pokazałem prawdziwy przykład i jakaś

pani potem do mnie podeszła i powiedziała,

że no ale ta aplikacja wygrała całą masę nagród,

więc pan na pewno nie ma racji.

No to z takimi argumentami nie ma co dyskutować,

prawda?

No to jest ten,

który już widzieliśmy.

Jeden z najpopularniejszych.

Nie dość,

że tekst prawie wychodzi poza przycisk,

to jeszcze jest na nim osadzony krzywo.

To jest drugi mój ulubiony z gatunku.

Developer powiedział,

wyświetla się,

to jest okej.

i nie ma znaczenia,

że pierwsze 2-3 piksele tekstu się po prostu

ucinają za ekranem.

Jeżeli zaczynamy od dużej litery i to po prostu

jej nie mamy już wtedy.

To jest kolejny fajny przykład z prawdziwej aplikacji,

która ciągle tak działa,

w której proces zakupowy raz na jakiś czas

zasłaniany jest reklamą,

którą ciężko jest zamknąć i jest to tyle zabawne,

że podejrzewam,

że ktoś tam przeanalizował statystyki i mówi

wzrost wpływów z reklamy,

zajebisty user experience.

Kolejny przykład wielokrotnie nagradzanej aplikacji,

która nie była w stanie swojego własnego logo

osadzić na nawbarze równo.

I generalnie już odchodząc nawet od tego,

że tego logo w ogóle nie powinno być na każdym

ekranie aplikacji,

no to jak już jest,

to chociaż mogą być wysierotkowane.

I kolejny bardzo częsty przykład.

Tak bardzo wiele formularzy wygląda.

Wyświetla się,

to jest okej.

Z grubsza ktoś tam to rozumie,

to jest okej.

I ostatni przykład,

to jest ten sam produkt,

oczywiście przekolorowany,

normalnie ma nieco inną paletę barw,

może kojarzycie,

bardzo popularna aplikacja,

w której logowanie i rejestracja wygląda zupełnie

inaczej.

Przełączając się pomiędzy jedną a drugą zakładką

na samym starcie onboardingu tej aplikacji,

trafiamy na zupełnie inny formularz.

Ja miałem wrażenie,

że to jest jakiś phishing,

że to jest jakiś skam po prostu i że mnie wywaliło

z tej aplikacji,

żeby gdzieś moje dane po prostu zebrać.

No ale ostatecznie wypełniłem ten formularz,

trwało to dobre 5 minut,

bo było bardzo dużo później pól,

a potem się okazało,

że niestety rejestrację można zrobić online,

tylko jeżeli najpierw się zgłosiłem do ich placówki.

Więc tak,

jak to wszystko naprawić?

Wiadomo,

że naprawić to można na wiele sposobów,

niekoniecznie design systemem,

bo można po prostu radykalnie zmienić podejście do UI,

czyli o wiele bardziej szkolić typowych UX-owców

lub szczególnie makeciarzy w rysowaniu czegoś

jednak bardziej wizualnie.

Dobre QA,

które strasznie kuleje,

bo też jest bardzo często takie przyświadczenie,

że jak już oddałem projekt graficzny do programistów,

to już on nie jest mój,

już się nie muszę tym przejmować.

No albo design system.

I teraz tak,

czym jest design system?

Generalnie w najprostszych słowach jest to zbiór zasad,

które pomagają nam zachować spójność i porządek

w naszym produkcie.

I to jest taki przykład pokazujący,

jak to często wygląda.

Mamy sobie kilka osób,

które pracują w sketchu nad produktem.

Każdy ma swój własny plik sketcha i generalnie

mają pewne określone zasady firmowe,

tak jak z brandbooka,

na przykład kolor firmowy,

jakiego fontu używają,

Brandon Grotesk,

bardzo fajny,

polecam.

I w pewnym momencie okazuje się,

że na przykład Adam sobie stwierdza,

że takie zaokrąglone przyciski mu się nie podobają,

że tak sobie zrobi trochę inaczej.

Marta stwierdza sobie,

że z kolei te Adama są za mało zaokrąglone,

więc są za mało przyjazne,

więc ona sobie zrobi znowu trochę inaczej.

I dochodzimy do takiego momentu,

w którym nam się zaczynają mnożyć komponenty

do naszego produktu

w kompletnie chaotyczny,

niezorganizowany sposób.

Drugą rzeczą,

którą jest design system to źródło prawdy o

naszych decyzjach projektowych i czym jest

źródło prawdy?

Jest to miejsce,

do którego zaglądamy,

żeby się dowiedzieć jaka jest prawda.

To jest taka najprostsza definicja,

ale źródła prawdy trzeba pilnować,

dlatego że jeżeli nie będziemy go pilnować,

to metodą głuchego telefonu nam się zamieni

w coś podobnego,

ale trochę innego.

więc trzeba tym zarządzać i takie źródło prawdy

w naszym przypadku wyglądałoby tak,

że byłoby pomiędzy tymi projektantami,

a tym ich efektem końcowym,

czyli oni by korzystali z tego źródła prawdy

do pobierania wszystkich możliwych definicji i rzeczy,

które potrzebują i dzięki temu nie byłoby takich

rozbieżności.

No i druga rzecz,

trzecia w zasadzie,

którą taki design system pomaga zrobić,

to jest ułatwienie wdrożenia nowych osób,

dlatego że w momencie,

kiedy przychodzi nowa osoba i ma kompletnie rozpisane,

udokumentowane wszystkie decyzje projektowe,

każdy przycisk,

każdy radiobaton,

każdy formularz ma już zaprojektowany tak naprawdę,

wizualnie,

łącznie z marginesami i paddingami,

no to wtedy układa go sobie tak naprawdę jak

z klocków Lego i zastanawia się już głównie

nad funkcjonalnością.

Więc tak,

może to wyglądać oczywiście w ten sposób,

nie musi.

Bardzo często tak niestety nie wygląda,

ale generalnie takie typowe wdrożenie właśnie

powinno wyglądać bardziej tak,

że się uczy tą osobę design systemu,

niż że się uczy bardzo tak high levelowo opowiadając

o tym,

z czego się składa produkt firmy.

Ale wszystko sprowadza się nawet nie tyle do

design systemu,

co ogólnie do systemowego podejścia do projektowania.

Dlatego,

że w tym 99 roku zwrot design systemu nie był

jeszcze powszechnie stosowany,

ale jakiś rodzaj systemowego podejścia musieliśmy

już wtedy wprowadzić,

inaczej byśmy popadli w totalny chaos.

Szczególnie,

że tam część tych projektantów webdesignerów,

która ze mną pracowała,

miała też takie swoje bardzo zabawne przypadłości,

czyli nie sprawdzali CSS-a zanim go napisali,

tylko tak jak im się wydawało,

więc były takie rzeczy jak teksty dekoracjone,

bo jeden chłopak kiedyś we Włoszech dużo mieszkał

i generalnie to nam robiło bardzo dużo rozbieżności

w tym systemie i musieliśmy wprowadzić sobie

na to jakieś rozwiązanie.

No i my wtedy zrobiliśmy coś w rodzaju wiki,

które dokumentowało ten proces z racji tego,

że projektując w Photoshopie i tak nie mogliśmy

zrobić sensownych bibliotek.

Ale ogólnie zasada takiego systemowego podejścia

do projektowania jest taka,

że każdą decyzję projektową dokumentujemy.

Potem jeżeli ją testujemy i wychodzi nam z tego testu,

że jest nie do końca właściwa,

to dokumentujemy ją ponownie zaraz po przeprojektowaniu.

co prowadzi do tego,

że każdy,

nawet najprostszy taki system,

czyli najprostszy zestaw reguł,

który stosujemy jest krokiem w dobrą stronę.

Ale design system ma dosyć otwartą definicję,

dlatego to jest w ogóle świetny temat,

żeby o nim mówić,

bo w zasadzie czego bym nie powiedział,

no to może być tak,

że akurat w mojej firmie to tak działa i po

prostu jest ok.

Dlatego,

że jeżeli ty nazywasz coś design systemem,

dlatego,

że to ułatwia pracę w twojej organizacji,

czy w twoim procesie projektowym,

to najprawdopodobniej to jest design system.

Nie ma takiego zbioru reguł,

zestawu,

że design system musi lub nie musi coś mieć.

Jeżeli coś wprowadza porządek i ułatwia,

no to jest to design system.

Takie szybkie przykłady,

oczywiście jest ich o wiele więcej od trzech

największych.

Design system Apple'a,

design system Microsoft'u i material design,

leciutko się przyciął.

To są systemy,

które faktycznie powstały po to,

żeby uspójnić pracę nad bardzo dużą grupą produktów.

Oczywiście są też popularne design systemy,

jeżeli chcecie sobie doczytać,

Atlassiana oraz IBMa Carbon Design System,

które są jednymi z lepszych przykładów na to,

jak to się powinno robić.

Dobra,

i teraz trochę faktów i mitów,

a w zasadzie jeden fakt i mit,

dlatego że bardzo często to widzę,

że Style Guide w Sketchu to nie jest design system.

No to Sketchowi trochę smutno z tego powodu.

Tylko tyle,

że jeżeli skonfrontujemy sobie to z poprzednim

stwierdzeniem,

że każdy zbiór zasad,

które pomagają nam wprowadzić porządek i spójność,

to jest design system,

no to w zasadzie wygląda na to,

że StyleGate w Sketchu też wprowadza jakiś

rodzaj spójności i jakiś rodzaj porządku w

naszym produkcie,

czyli można jak najbardziej założyć,

że jednak jest to design system,

tylko dosyć prosty.

I teraz tak,

takie typowe budowanie produktu w bardzo dużym

uproszczeniu wygląda tak,

że mamy projektanta,

mamy dewelopera i oni sobie ze sobą rozmawiają

i oczywiście w idealnym świecie ta rozmowa

przebiega przez jakiś taki oficjalny kanał,

Trello,

Jire czy cokolwiek z czego firma korzysta do

tworzenia procesów.

Ale wiadomo też,

że ludzie są ludźmi i część tych rozmów siłą

rzeczy przebiega też na lunchu,

na kawie,

w windzie,

po dziesięciu piwach,

na imprezie firmowej.

I gdzieś te rzeczy są między sobą komunikowane,

troszkę tych rzeczy się gubi,

troszkę tych rzeczy jest opacznie zrozumiane

i nie wszystkie są gdzieś tam w tym naszym systemie.

W momencie,

w którym zaczynamy dodawać więcej osób do zespołu,

część tej komunikacji pobocznej zaczyna wykraczać

nam już kompletnie i pomijać niektóre osoby.

Co powoduje jeszcze większy chaos.

Już czasem nie wiemy,

skąd się coś wzięło i po co powstało.

Co z kolei powoduje częste rozjazdy czy w wizjach

wszystkich zaangażowanych stron.

Więc taki design system jest tak naprawdę takim

bufferem,

takim przejściem pomiędzy tymi grupami,

czyli oni nie pytają się siebie o to jak coś zrobić,

tylko sprawdzają w tej dokumentacji.

I generalnie rozwój takiego design systemu

zawsze musi działać w pewnym zespole i musimy

go potraktować jako produkt naszej firmy.

Jeżeli nawet mamy już produkt,

czyli nasz startup,

czyli naszą aplikację,

nasz SaaS,

to taki design system jest takim wewnętrznym

produktem dla tego produktu,

dlatego powinien mieć swój własny zespół.

I zawsze powinien być to jeden projektant i

jeden developer przynajmniej,

plus jeden product owner,

który też będzie wpływał na niektóre decyzje biznesowe.

U nas bardzo często rozmawiamy sobie tak na

łonie natury o takich rzeczach,

pokazujemy sobie różne rzeczy,

jest dużo śmiechu,

ale te spotkania projektowe są faktycznie po to,

żeby te decyzje nie były podejmowane w odseparowaniu

od reszty osób.

I generalnie zawsze te decyzje są konsultowane,

dlatego że w sytuacji,

w której dwóm osobom z takiego przykładowego

trzyosobowego zespołu coś się wydaje,

zawsze ta trzecia osoba może powiedzieć nie,

nie,

panowie,

tak nie robimy.

A swoją drogą jest nas tutaj trzech,

a na stole stoją cztery napoje.

No dobrze.

Tak,

elementy design systemu.

Zaczniemy od tych dwóch ostatnich dlatego,

że o tym pierwszym chcę troszeczkę więcej powiedzieć,

czyli dokumentacja i fragmenty kodu.

Dokumentacja,

czyli wiki jest miejscem,

w którym zbieramy te wszystkie decyzje projektowe

i to co my odkryliśmy to jest to,

że bardzo dobrze jest nie robić do niej CMS-a.

Dlatego,

że na początku zrobiliśmy CMS-a i w produkt

i w design system było włączone też kilka osób

od strony klienta i w momencie kiedy był CMS

no to każdy junior brand manager mógł sobie

coś tam do tego dodać,

potem nie konsultując z całą resztą,

gdzieś tam to zmodyfikować.

I wiadomo,

że można przyznać uprawnienia,

tylko jak się przyzna uprawnienia,

to ktoś wtedy powie,

no a czemu ja nie mam tych uprawnień,

bo chcę coś teraz zmienić.

W momencie,

kiedy tylko deweloper tak naprawdę może to zmienić,

czyli zmiany wprowadzamy w kodzie,

to potrzebne jest spotkanie,

na którym ten deweloper też będzie obecny.

On będzie w stanie też od razu powiedzieć,

czy ta zmiana w ogóle ma sens z perspektywy

kodu i dopiero ją wprowadzić przy wszystkich

tak naprawdę wspólnie na spotkaniu.

Oczywiście on sobie to może jakoś ułatwić,

ale chodzi o to,

żeby to nie był taki po prostu prosty CMS,

do którego się logujemy i robimy modyfikacje,

kiedy nam się to tylko podoba.

Każdy komponent w tym design systemie jakoś opisujemy.

Na pewno warto napisać,

gdzie ten element występuje,

ile razy go można stosować i w jakich formach.

Natomiast wszystkie elementy,

które się da,

warto definiować jako tokeny.

i to jest taka wartość nadrzędna,

która znajduje się przed tym wiki i przed elementami

kodu i jak pluginy pozwolą,

to także przed plikami z projektem.

Która polega na tym,

że jeżeli definiujemy sobie spacing2 jako 32 punkty,

to w każdym miejscu,

w którym wpiszemy spacing2 w naszej dokumentacji

czy w naszym kodzie,

on się pobierze jako ta wartość.

W momencie kiedy zmieniamy sobie tą wartość,

ona się zmieni jednocześnie we wszystkich tych

miejscach.

Tak samo z gradientami,

fontami i tak dalej.

Ale oczywiście taki design system,

jeżeli już zostanie zbudowany,

to nie będzie stał w miejscu.

Musimy go jakoś rozwijać,

jakoś rozbudowywać,

dopisywać rzeczy nowe do tej naszej dokumentacji.

No więc jak działamy ze zmianami i testami?

My działamy w taki sposób,

że każda strona,

każdego komponentu czy każdego elementu jest

wersjonowana.

Jest wersjonowana dniem,

dlatego że nie przewidujemy,

żeby jednego dnia powstawała więcej niż jedna

nadrzędna decyzja.

Jeżeli by tak było,

to tak naprawdę to też powoduje jeszcze większy

chaos i zdecydowanie warto tego unikać.

I skoro jest to jeden dzień,

to pomiędzy tym pierwszym dniem,

a drugim jeszcze warto jakieś uzasadnienie

tej zmiany wstawić.

Na przykład,

to też taki przykład prawdziwy.

Robiliśmy badanie klikalności elementów i radiobaton

wyszedł nam,

że bardzo dużo osób nie trafiało w ten radiobaton,

nawet z całym jego dużym obszarem aktywnym.

Dlatego w tym teście,

w którym go powiększyliśmy,

okazało się,

że tych trafień jest znacznie więcej i została

wprowadzona ta zmiana.

Mamy wersję z 10 września pierwotną,

potem badanie z 15 września

i potem wersję z 4 listopada,

która weszła.

I w momencie,

kiedy pojawia się w zespole nowa osoba,

która mówi,

że ale wiecie,

teraz modniej jest robić trochę mniejsze te radiobatony,

bo mimo wszystko tam teraz taki jest trend

w designie na driblu,

to my możemy powiedzieć,

że no tak,

ale my to już kiedyś tak zrobiliśmy i mamy

tutaj całą historię tych zmian,

która pokazuje dlaczego to się tak wydarzyło

i dlaczego w tym momencie są większe.

Drugą,

w zasadzie teraz,

a w zasadzie normalnie trzecią rzeczą są definicje

w kodzie.

My stosujemy Reacta,

oczywiście są też inne frameworki,

ale zawsze obok Reakta robimy też wersję w

czystym CSS-ie.

Wynika to z tego,

że w czystym CSS-ie łatwo się komunikować także

z zespołami,

które nie pracują w Reakcie,

bo nawet jeżeli ktoś nie działa w CSS-ie,

to najprawdopodobniej go zna,

a jednocześnie jest to też zapis,

który jest potencjalnie łatwo zrozumiały dla

projektantów,

czyli każdy projektant jest w stanie się łatwo

tego CSS-a nauczyć i łatwo się komunikować,

no i dodatkowo prawie każde narzędzie projektowe

po prawym kliku na obiekcie jest w stanie ten

CSS od razu skopiować.

My korzystamy też z Netlify,

gdzie mamy najpierw zdefiniowane tokeny w pliku JSON,

robimy deployment na Bitbucketa,

z którego odpala się to wiki na Netlify i przy

okazji niektórych pluginów udaje nam się też

modyfikować częściowo bibliotekę.

Częściowo jest to niestety wymagane ręcznie,

ale w sytuacji kiedy musimy to robić ręcznie,

no po prostu robimy to na spotkaniu projektowym.

I taki przykład kodu,

w którym są te tokeny zastosowane.

Tutaj jak widać tokeny są do prawie wszystkiego,

ale to nie jest całość definicji przycisku.

Wszystkie te wartości,

czyli primary,

button,

background itd.

są zapisane w kompletnie oddzielnym pliku.

Jeżeli to zmodyfikujemy to zmieni się to i tutaj,

oczywiście ten kod trzeba będzie odpalić jeszcze raz,

ale zmieni się to też od razu w naszej dokumentacji.

I teraz ostatni,

najprzyjemniejszy element,

czyli biblioteka komponentów.

I tak jak powiedziałem wcześniej,

jeżeli macie tylko bibliotekę komponentów,

to i tak jest super,

bo to jest więcej niż większość produktów posiada

i to pozwala bardzo dużo zaoszczędzić czasu

i frustracji.

Przykładowy fragment naszej biblioteki komponentów

w Sketch'u to jest strona z symbolami wyciągnięta

z kilku osobnych plików.

Wszystkie te elementy są ze sobą nawzajem powiązane,

zaraz powiem w jaki sposób.

Generalnie wszystkie są też opisane i my dodatkowo

stosujemy mamy opisy w samym pliku Sketch'a,

to znaczy w momencie kiedy mamy jakiś przycisk,

to obok sobie poza artboardami piszemy też co on znaczy,

dlatego że w ten sposób jest łatwiej wdrażać

też nowego projektanta,

on nie zawsze musi od razu przez wiki przechodzić,

prawie zawsze najpierw obejrzy ten plik Sketch'a,

więc będzie w stanie już z niego coś wyciągnąć,

pewne podstawowe informacje.

Struktura takiej biblioteki tak naprawdę składa

się z kilku bibliotek.

Zaczynamy od tego,

że w zupełnie oddzielnym pliku,

który jest biblioteką skeczową,

mamy tylko i wyłącznie kolory.

W oddzielnym pliku mamy typografię.

I w oddzielnym pliku mamy ikony i elementy graficzne,

dekoracyjne,

czyli różnego rodzaju trochę większe ikony.

Polega to na tym,

że kolory można jako maskę zastosować na przykład

w pliku z ikonami,

czyli de facto z pliku z kolorami pobieramy

do pliku z ikonami,

z którego pobieramy do kolejnych plików i w

ten sposób tworzymy sobie strukturę,

w której mamy kilka nadrzędnych elementów definiujących

tam cały projekt.

Następnie dzielimy to na takie uniwersalne komponenty,

które wyglądają tak samo niezależnie od platformy.

Mogą się różnić oczywiście szerokością,

responsywnością.

Inne komponenty specyficzne,

czyli różnice między iPhone'em,

Androidem,

różnice między wersją weba,

aplikacją mobilną.

I z tych dwóch grup komponentów dopiero składamy

faktyczne widoki.

I taką typową definicją,

od której zaczynamy tworząc taki design system,

jest definiowanie kolorów.

Jeżeli mamy gradient,

tak jak w naszym przypadku,

to najpierw definiujemy te dwa kolory,

z których on się składa oraz ten kąt,

pod jakim ten gradient najczęściej występuje.

Ale oczywiście warto też to zastosować w taki sposób,

żeby on był w kodzie już łatwo przenaszalny dalej.

Czyli te nasze kolory definiujemy sobie jako

MałpaBlue3 i MałpaPink3.

To są oczywiście nazwy,

które umożliwiają stworzenie z nich tokenów później.

I generalnie dzięki temu taki nasz kod wygląda tak,

że najpierw mamy pure CSS,

czyli taką wersję,

która najprościej na górze tutaj pokazuje,

że jest to gradient od takiego koloru do takiego.

A następnie mamy tutaj wersję z LES-a,

która już stosuje te tokeny,

jeżeli mamy pure CSS.

I też pure CSS jest dlatego ważny,

że czasem jest tak,

że nawet jak mamy super fajny produkt w reakcie

to musimy zrobić banery w HTMLu.

I wiadomo,

że nie będziemy robić banerów reklamowych w reakcie,

ani jakichś takich prostych pop upów marketingowych

jeżeli w ogóle są potrzebne,

tylko można je zrobić w czystym CSS,

w czystym HTMLu no i dzięki temu mamy tutaj

też tą spójność komponentów zachowaną.

Ikonki mamy jako SVG i w naszym przypadku działa

to w ten sposób,

że te ikonki są kształtem bazowym,

który występuje zawsze w takim kolorze jak

ten tutaj po lewej.

Natomiast z pliku z kolorami pobierają nam

się dostępne maski,

które można nałożyć na ten obiekt i to definiuje

od razu,

że ten obiekt może występować tylko w takich

trzech wersjach kolorystycznych.

Oczywiście te maski możemy tworzyć w kilku wielkościach,

żeby potem Sketch się nie pomylił i nie pozwolił

nam na wybranie dowolnych kolorów,

ale dzięki temu zachowujemy spójność i zachowujemy

właśnie taką możliwość,

że ktoś nowy przychodzi,

wstawia sobie uśmiechniętą buźkę,

to nie wstawi jej nagle w zupełnie niepasującym

kolorze lub w kolorze,

który nie jest zdefiniowany,

tylko w tych naszych dozwolonych.

I to jest coś,

co my wymyśliliśmy dosyć niedawno.

Jest to bardzo fajny patent,

żeby takie nowe komponenty,

czy taki nowy design system przetestować,

dlatego że oczywiście można go testować na

samym produkcie,

ale w momencie,

kiedy go zaczynamy budować,

powstaje produkt,

ale jest jeszcze bardzo dużo czasu developmentu

i jest jeszcze bardzo dużo czasu pracy przed nami.

Wpadliśmy na pomysł,

żeby wziąć design system istniejący,

który teraz robimy dla klienta,

przekolorować go i zbudować z niego,

z racji tego,

że jest to aplikacja społecznościowa,

inne aplikacje społecznościowe.

W związku z czym,

oczywiście tutaj nie chodzi o to,

żeby to było funkcjonalne,

bardziej chodzi o to,

jak te komponenty można względem siebie ułożyć,

jak one grają ze sobą po przekolorowaniu.

I generalnie to wygląda tak,

że to jest zbudowane jedną z istniejącego design

systemu jest to przeróbka.

Ta przeróbka powstała też od razu po przekolorowaniu

dla Facebooka i Twittera,

co pokazuje,

że ten design system spełnia się w prawie każdym

typie produktu.

I takie przekolorowanie zaczęliśmy od tego,

że zdefiniowaliśmy sobie główny kolor i główny gradient,

potem zdefiniowaliśmy sobie wszystkie odcienie szarości,

które były od jedynki do piątki,

ale tutaj użyjemy tylko pierwszego i trzeciego i biały.

Definicja komponentów,

czyli np.

karty użytkownika jest rozpisana na kolor overlaya

na zdjęciu,

żeby tekst był czytelny,

na background samego kontainera zanim to zdjęcie

się wczyta,

a nawet na wyrenderowanie cienia,

żeby zobaczyć jak on faktycznie będzie wyglądał

na jakim typie tła.

Przenosząc to już na konkretne komponenty,

mamy te nasze trzy style graficzne do tych

trzech aplikacji.

tutaj co prawda kolory się odrobinę przekłamały,

więc musicie mi uwierzyć na słowo,

że dwójka to Facebooka,

trójka to Twitter.

Mamy definicję tego,

jakie mamy typy przycisków,

ile unitów odstępu na przycisku jest do na

przykład labela,

czy nawet do kontejnera z bezpiecznym obszarem

tego labela,

jak wygląda jego tło i tak samo jak wygląda jego cień.

No i teraz oczywiście takie ćwiczenia są o

tyle też fajne,

że to pozwala na po pierwsze dodać coś na dribla

wiadomo,

ale też pozwala to na pewną dozę kreatywności

w produkcie,

który być może nas już trochę znudził po dłuższym

działaniu z nim.

Pozwala sprawdzić jak z tych komponentów można

coś jeszcze zbudować,

a przy okazji wracając z tym do produktu dochodzimy

do punktu,

w którym klient stwierdza,

że może taką funkcję podobną na przykład dodać,

tylko lekko zmodyfikowaną,

co też po prostu daje nowe pomysły i nowe rozwiązania.

Przy okazji sprawdzamy w jakich warunkach ten

design system się faktycznie sprawdza,

w jakich się nie sprawdza.

Podstawowe zalety,

taka najbardziej podstawowa zaleta jest taka,

że jest więcej czasu na innowacje,

bo się nie musimy zastanawiać jak zrobić dany komponent,

tylko po prostu już go najczęściej mamy zbudowanego.

Szybsze wdrożenia,

ale oczywiście po pewnym czasie,

bo na początku nie są szybsze.

Spójność i czytelność oczywiście totalnie podstawowa

rzecz,

dlatego że to wpływa na to zaufanie użytkownika,

na to poczucie jego,

przez niego jakości tego naszego UI-a.

No i jedna z moich ulubionych rzeczy,

że można planować nowe funkcjonalności kompletnie

pomijając szare makiety.

Dlatego,

że w momencie kiedy możemy każdy komponent

naszego systemu drag and dropować,

to układamy to jak z klocków Lego.

Jeżeli robimy to z komponentami,

które mają zdefiniowane bezpieczne obszary,

to nawet możemy je ułożyć od razu w takiej odległości,

która wynika z naszego gridu po prostu je drag

and dropując,

bo ten bezpieczny obszar nie pozwoli przesunąć

czegoś bliżej czy dalej.

Dzięki czemu możemy mieć makietę Hi-Fi zrobioną

szybciej niż tą Low-Fi.

Ale oczywiście są też wady.

Po pierwsze zajmują dużo czasu,

bo trzeba mieć dedykowany zespół,

ten zespół musi siedzieć,

musi to wdrażać,

musi tego pilnować,

może się to też rozjechać.

Zwrot z inwestycji jest po dłuższym czasie

i też nie zawsze faktycznie jest,

bo trzeba pamiętać,

że nie każda firma potrzebuje design systemu.

tak jak każdy produkt w zasadzie potrzebuje

systemowego podejścia do projektowania to to

design system dla niektórych firm może być

już odrobinę za daleko,

więc pytanie czy ja tego potrzebuję zadawane

przez stakeholderów i tak dalej może być zasadne.

Designerzy artyści mówią też,

że zabijają kreatywność dlatego,

że wymuszają szablonowe myślenie,

ale to też nie jest do końca tak,

dlatego,

że jeżeli robimy jakiś komponent czy jakiś ekran,

który zawiera zupełnie nowy element czy nawet

nowy sposób przedstawiania tych elementów,

to zawsze możemy go zgłosić,

możemy go zaproponować.

Bardziej chodzi o to,

żeby robiąc formularz nie robić tego za każdym

razem od nowa,

czy robiąc takie podstawowe rzeczy.

Więc to nie zabija kreatywności,

tylko raczej narzuca pewne odgórne reguły,

które pozwalają tą spójność zachować.

Generalnie są faktycznie trudne w utrzymaniu,

szczególnie jeżeli nam odchodzą,

przychodzą nowe osoby,

bo trzeba bardzo pilnować tego źródła prawdy.

ale docelowo czy design system,

czy systemowe podejście zawsze się opłacają,

dlatego że małe problemy lubią się nawarstwiać.

Na większości moich slajdów była taka kreska

po lewej stronie,

tutaj się zresztą bardzo ładnie ten gradient wyświetla.

Na każdym slajdzie przesuwanie o jeden piksel w dół.

No i jesteśmy tutaj te trzydzieści parę minut później

i jak widać tej spójności nie ma.

I wiadomo,

że to nie jest aż tak ważne,

dopóki te slajdy są czytelne,

można je rozczytać,

ale jednocześnie,

jeżeli byśmy mieli pierwszy i ostatni slajd obok siebie,

to większość osób podświadomie wyczuje,

że coś tutaj nie gra.

Więc wpływa to na to poczucie jakości,

na właśnie takie pilnowanie tego,

żeby chociaż dół tego telefonu nam się wyrównał.

I dlatego warto podchodzić do projektowania systemowo,

to nie jest sztuka,

to jest rzemiosło i w ten sposób powinniśmy

to traktować.

Dziękuję.

Dzięki wielkie.

I tradycyjnie tak jak wczoraj,

jeśli ktoś ma jakieś pytania,

dłoń w górę,

my dajemy pieczątki.

Tutaj już widzę pierwsze.

Mam takie pytanie,

czy pracowaliście z wykorzystaniem Atomic Designu

również przy tworzeniu bibliotek?

Tak,

ale jednocześnie nie.

I już mówię dlaczego.

Jeżeli chodzi o design systemy,

to oczywiście wszyscy wiedzą,

że Brad Frost napisał to najdokładniej i faktycznie

ten jego opis jest sensowny.

Natomiast Atomic Design ma ten minus jako główne

takie założenie,

że jeżeli zaczynamy mówić o molekułach,

atomach i tak dalej,

to bardzo wielu stakeholderów w firmach,

szczególnie tych mniej technicznych nie rozumie

o co chodzi i mówi zaraz,

my jesteśmy firmą technologiczną,

a nie biologiczną.

Więc my stosujemy zasadę upraszczania języka

przede wszystkim i generalnie nazywamy te rzeczy

jak najbardziej po imieniu.

Zresztą bardzo często współpracujemy nawet z osobami,

dla których już user experience jest niezbyt

zrozumiały jako zwrot.

Czy mi nie chodziło konkretnie o nomenklaturę,

bo każdy może sobie przyjąć własną,

tylko jakby sam system budowania komponentów,

troszeczkę to co pokazałeś tak na to wskazuje,

czy że zagnieżdżacie jedne elementy w drugie.

Tak,

tak to zagnieżdżanie jak najbardziej działa

i to zagnieżdżanie jest i na etapie bibliotek

sketchowych i na etapie komponentów w kodzie.

Ok,

dzięki.

Dzięki,

kolejne pytanie.

Ja chciałam się zapytać czy masz jakieś rady dla firmy,

która powiedzmy ma już jakąś stosunkowo nową stronę,

ale że już jest trochę widoków i tak dalej,

a dopiero teraz planujemy wprowadzić design

system i to wszystko jest strasznie rozwalone,

ale zacznijmy od tego,

że gradienty są pod różnym kątem i czy masz

jakąś radę jak zacząć w ogóle?

Na pewno dobrze,

że już coś macie,

dlatego że budowanie design systemu zanim powstaną

widoki też nie do końca ma sens,

dlatego że najpierw musimy sobie coś wyobrazić,

jak to faktycznie wygląda całościowo,

a potem dopiero zacząć te rzeczy uspójniać.

Więc przede wszystkim to,

co musicie zrobić,

to zacząć od podstaw,

czyli na przykład od kolorów i gradientów,

wyciągnąć je z tego waszego gotowego projektu

i wypisać każdy przykład wykorzystania,

czyli jeżeli macie gradient pod różnym kątem,

to każdy z tych przykładów oddzielnie wypiszcie

i zastanówcie się,

który jest faktycznie pod jakim kątem potrzebny.

Potem resztę się eliminuje i warto to też w

formie już takiego wiki stworzyć jako historię zmian,

czyli tą pierwszą wersję,

którą opisujecie,

opiszcie obecną.

Nawet opiszcie,

że macie tego samego gradientu pod różnym kątem

10 instancji,

a potem w wersji,

w której zrobiliście eliminację,

opisujecie już tą jedną,

którą stosujecie dalej.

I tak samo typografia,

tak samo wszystkie kolejne elementy po prostu po kolei.

Nawet jeżeli na początku zmienicie tylko kolory,

to też już jest to design system,

jest to już jakieś uspójnienie.

Dobra,

dzięki.

Cześć,

wspomniałeś o tym,

że masz jakby zespół,

który zajmuje się tym i chciałam podpytać ile

osób jest w tym zespole i czy to jest tak,

że to jest praca na 100% i oni zajmują się

tylko utrzymaniem design systemu czy jakoś

to dzielicie między sobą?

Zwykle jak tworzymy takie zespoły to to są

zespoły trzyosobowe z czego jedna osoba jest

po stronie klienta i dwie po naszej stronie.

Natomiast jest to bardzo różnie,

bo też tak jak mówiłem najpierw mamy swoje dwa startupy,

w których też mamy design systemy I w nich,

z racji tego,

że są relatywnie prostymi produktami,

te design systemy nie muszą być utrzymywane

na full time,

tylko bardziej utrzymywane na zasadzie pilnowania

właśnie tej historii wersji i wersjonowania

wszystkich zmian.

W momencie,

kiedy projekt jest duży,

tak jak na przykład ten projekt z tysiącem ekranów,

który był też na PlayStation,

na telewizory i tak dalej,

tam faktycznie było potrzebne dwie osoby do

takiego total full time utrzymania,

dlatego,

że były też bardzo duże zespoły deweloperów

w różnych technologiach i jeżeli byśmy tego

nie pilnowali,

to ktoś by zaczął od tego odbiegać powoli.

Czyli to zależy dużo od skali projektu tak naprawdę.

Ok,

to jeszcze dopytam o tą skalę,

czy jako UI designera traktujecie też

osobę,

która ma kompetencje front-endowe,

czy po prostu robicie parę na zasadzie UI designer

i front-end developer,

którzy wspólnie utrzymują bibliotekę?

Tak,

to znaczy robimy parę UI designer,

który zna przynajmniej CSS i front-end developer,

który zna Sketch'a.

Mówiłeś o bibliotece komponentów w Sketch'u,

a jak od tej strony kodu,

czy też stosujecie jakby gotową bibliotekę

komponentów reaktowych i jak to się komunikuje?

Tak,

stosujemy bibliotekę komponentów reaktowych,

która jest normalnie na repozytorium i generalnie

mamy tam dodany taki element,

który z pliku json z wartościami bazowymi pobiera

te wartości bazowe do kodu.

Czyli generalnie on definiuje nam i wiki i

te fragmenty kodu.

Tutaj oczywiście o wiele bardziej technicznie

nasi programiści pewnie by mogli na to odpowiedzieć,

ale zajęło nam to trochę szczególnie,

że te połączenia też nie zawsze działały sensownie

i nie zawsze były sprawdzalne.

Wiadomo,

że ten kod trzeba wygenerować,

czyli on się nie zmieni automatycznie,

tylko trzeba sobie to odpalić ponownie już

z tymi nowymi wartościami,

ale doszliśmy do momentu,

który właśnie Netlify to bardzo dobrze umożliwia,

bo to jest taka platforma właśnie oparta o

repozytorium gitowe,

więc dzięki temu pobierając z pliku JSON wartości

one nam się wrzucają do kodu,

one nam się wrzucają do wiki i w bardzo szczątkowej

formie nawet do plików sketcha,

ale to jest takie na wpółgręcznie jeszcze.

Figma umożliwia takie rzeczy troszeczkę lepiej,

ale nie jesteśmy fanami.

Jeszcze jakieś pytanie?

Ja chciałem dotknąć tematu wdrożeń design systemów,

w szczególności w dużych,

rozległych produktach,

gdzie jest cała masa legacy kodu,

a czy masz jakieś strategie,

o których mógłbyś nam opowiedzieć?

Tak,

ale jednocześnie jest to dosyć obszerny temat,

to znaczy jak robiliśmy ten produkt,

do którego nawiążę po raz kolejny,

czyli ten na bardzo wiele platform,

no to siłą rzeczy było tam wiele kodu robionego

przez nawet już nieistniejące zespoły.

Było tam wiele kodów w bardzo różnych technologiach.

Generalnie polegało to na tym,

żeby każdy główny programista z każdego podproduktu,

tego głównego produktu też uczestniczył w tym procesie,

więc tam zespół design systemowy był po prostu

o wiele większy.

Ale w momencie,

kiedy my przekazaliśmy tym developerom,

że de facto całe to działanie jest po to,

żeby im tą pracę usprawnić,

i im te problemy rozwiązać,

to większość była bardzo pozytywnie nastawiona

do tego i większość była bardzo zadowolona

z takich działań.

Oni oczywiście robili te zmiany właśnie w kodzie

czy te naprawianie tych legacy problemów już

samodzielnie,

ale bazując na zasadach,

które wspólnie wypracowywaliśmy.

Odpowiedziane?

Dobra.

I tu jeszcze była ostatnia dłoń w górze przedtem,

więc żeby być fair.

Cześć.

Takie pytanie odnośnie na przykład frameworków

jak Bootstrap czy coś.

Jak wygląda tworzenie design patternów pod

takie framework'i?

Czy lecieć z dokumentacją załóżmy Bootstrap'a,

czy że tak powiem kolokwialnie olać to i robić

to co uważam za najważniejsze?

To też dużo zależy od produktu.

My nie jesteśmy fanami Bootstrap'a dlatego,

że to narzuca od razu bardzo dużo takich elementów,

które sprawią,

że produkt będzie wyglądał jak prawie każdy

inny produkt online.

Dlatego Bootstrap generalnie jeżeli już wprowadzamy

to warto jest po prostu iść zanim troszeczkę

go zmodyfikować.

Natomiast Bootstrap jest dobrym punktem wyjścia

żeby pomyśleć o zupełnie własnym design systemie,

bo bardzo wielu deweloperów go zna więc oni

zaczynają rozumieć,

że jeżeli mamy zbudować coś jak własny Bootstrap

to tak naprawdę tworzymy design system.

Czas nas goni.

Wielkie brawa dla Michała.