Figma Autolayout i Atomic Design: Wdrożenie design systemu - część II

0:00Chciałbym Cię również przestrzec przed

0:01kilkoma takimi bardzo podstawowymi błędami, jakie bardzo łatwo możemy

0:06popełnić przy wdrażaniu czy korzystaniu z design systemów.

0:09Pierwszym błędem jest skupienie się na pracy nad projektem, bo wiadomo

0:15metodologia metodologią, a deadline deadline'em.

0:18Czasami jest tak, że właśnie dopinamy produkt, wprowadzamy bardzo dużo poprawek,

0:23zmian, skupiamy się na tym, żeby dowieźć to, co jest do zrobienia, a design

0:28system gdzieś tam sobie leży i czeka, że może kiedyś do niego wrócimy.

0:32To jest bardzo złe podejście.

0:34Wszystko powinno wychodzić z design systemu do produktu, na każdym etapie.

0:39Kolejnym błędem są tzw. małe poprawki.

0:43Takie drobne rzeczy, które poprawimy sobie już bezpośrednio w aplikacji.

0:48Nikt tego nie będzie w żaden sposób odnotowywał.

0:51Tak nie może być.

0:52Niech to będzie taka drobna poprawka, gdzie np.

0:55wyszło nam w testach accessibility, że

0:57kolor pewnych elementów słabo kontrastował, więc lekko rozjaśniamy czy

1:02przyciemniamy jakiś element i zrobiliśmy to w aplikacji.

1:05Nie ma o tym śladów w design systemie.

1:09I teraz jeżeli to zostało wyłapane np. w jednej aplikacji, to możemy się

1:12spodziewać, że jeżeli z tego design systemu korzystają też inne podmioty,

1:17ten błąd występuje pewnie też tam.

1:19Warto zaktualizować design system, tak aby

1:23wszyscy interesariusze dowiedzieli się, że taka poprawka miała miejsce.

1:27Bo może być też tak, że np.

1:28ktoś zacznie analizować design system i

1:30wyłapie to na poziomie design systemu i podniesie larum:

1:34o to wyłapałem błąd,

1:36tutaj mamy złe kontrasty i zacznie się grzebanie, jakby

1:41całe sprawdzanie okaże się, że np. ta zmiana już w aplikacji została dawno wprowadzona.

1:46Więc ta spójność musi być.

1:48I jeszcze większym błędem jest dodawanie

1:50całych atomów, molekuł czy wręcz organizmów do bezpośrednio do produktu,

1:56bez jakiegokolwiek śladu po nich w design systemie.

1:59I tu znowu powtórzę wszystko zawsze wychodzi z design systemu.

2:04Jeżeli jest potrzebne dodatkowa ikona, dodatkowy odcień koloru, dodatkowa wartość

2:10stopnia pisma, to wszystko wychodzi z design systemu.

2:15Jeżeli to dotyczy małych elementów, to tym

2:17bardziej dotyczy to większych elementów, tzn.

2:20jeżeli nagle jest potrzebny jakiś pop-up z

2:23jakąś informacją, to zaprojektowany taki pop-up powinien być w dokumentacji po to,

2:28aby inne zespoły mogły z tego też skorzystać, a nie tworzyć

2:33inny, niespójny z tym, który powstał jako pierwszy.

2:36Pracując nad produktami cyfrowymi warto

2:39sobie przedefiniować w ogóle definicję, że coś zostało wykonane, ponieważ w cyfrowym

2:44produkcie wiele rzeczy można bardzo szybko poprawić i zmienić.

2:48To nie jest książka do druku, że jeżeli wykorzystamy zły kolor do projektu

2:52okładki, to pójdzie 50 tysięcy nakładu i nagle przyjedzie okładka

2:56zielona, nie czerwona, bo coś nam się pomyliło i będzie awantura.

3:01W cyfrowym produkcie możemy wszystko bardzo szybko poprawiać.

3:05Dlatego nie czekaj z publikowaniem elementów design w systemie.

3:09Nawet jeżeli wiesz, że kolor za tydzień się zmieni.

3:13Masz przygotowany zestaw, masz paletę, ale wiesz, że za tydzień ona się zmieni, bo

3:18klient będzie miał rebranding albo wyszło w badaniach, że trzeba to zmienić.

3:21Publikuj to, co masz teraz.

3:22Jeżeli wiesz, że masz komponent, ale za

3:24tydzień dodana będzie do niego funkcja nie czekaj, że to będzie za tydzień, bo może

3:28za tydzień się przesunie o dwa tygodnie, o miesiąc.

3:31Publikuj to co masz, a za tydzień opublikujesz aktualizację.

3:35Aktualizacje są bardzo ważne.

3:37To ciągłe update'owanie i informowanie

3:40zespołów o updacie jest kluczowe, ponieważ najgorsze co możemy zrobić to

3:45stworzyć system raz i uznać, że OK powstał,

3:49tam jest wszystko.

3:51My sobie teraz działamy i zawsze działamy.

3:54Podejmujemy wszystkie decyzje odnosząc się

3:56do tego naszego design systemu, który sobie gdzieś tam leży, który rok temu

4:00stworzyliśmy, ponieważ przez rok mogło się bardzo dużo wydarzyć.

4:04Dlatego musimy go zawsze aktualizować i pamiętać, że on się musi zmieniać.

4:09Dlatego też dużym błędem jest publikowanie

4:11dokumentacji w formie zamkniętych plików np. PDF, bo taki raz wysyłany PDF będzie potem

4:17tygodniami, miesiącami, latami krążył po organizacji i ludzie sobie go przesyłać

4:22się do niego odwoływać, nie patrząc kiedy on powstał, a możliwe, że w międzyczasie

4:27wiele, wiele, wiele elementów tej dokumentacji się zmieniło.

4:31Dlatego warto skorzystać z narzędzia,

4:33dowolnego narzędzia online do publikowania naszego design systemu.

4:38Na rynku dostępnych jest wiele naprawdę

4:40fajnych narzędzi do publikowania design systemów.

4:43Jednym z nich jest Zeroheight, z którego korzysta naprawdę wiele organizacji.

4:48Na ich stronie możesz zobaczyć w zakładce showcase przykłady wdrożenia.

4:54Korzysta z nich np. Decathlon i możemy sobie obejrzeć design system

5:00decathlon'a widzimy, że jest to wersja dwudziesta druga, najnowsza.

5:05Mamy różne informacje o przyciskach, stylu

5:09zdjęć i innych komponentach, które występują w ich design systemie.

5:15Tworzenie takiego design systemu jest naprawdę proste.

5:19Po zalogowaniu do aplikacji klikamy create styleguide, nazwę go sobie Eduweb.

5:26Mogę sobie wgrać jakieś logo.

5:29Następnie możemy wybrać opcję czy chcemy

5:31zacząć od zera, czy potrzebujemy jakiegoś szablonu?

5:34Ja skorzystam z przykładowego szablonu.

5:37Fajną opcją jest to, że do Zeroheight możemy

5:42w bardzo łatwy sposób podpiąć nasz projekt Figm'y,

5:45Sketch'a, Zaplin'a czy XD.

5:49Więc prześlę tutaj projekt nad którym pracujemy,

5:56a po chwili zostaną do naszego design systemu zaimportowane wszystkie elementy.

6:02One jeszcze nie są widoczne, ale korzystając z nawigacji po lewej stronie

6:07mogę podejmować decyzje, które elementy chcę dodać.

6:11I tak na przykład w zakładce colors,

6:14primary colors wybieram z listy zaimportowanych elementów np.

6:19sprint orange i zaznaczam, że chcę zaimportować wszystkie kolory.

6:26Po chwili cała paleta została zaimportowana.

6:31Oczywiście mogę tutaj dodać opis jak kolory powinny być stosowane zarówno dla

6:36całego dokumentu, jak i dla poszczególnych kolorów.

6:40W ten sam sposób mogę dodawać inne

6:42elementy stylów oraz komponenty zdefiniowane w Figm'ie, np.

6:49przyciski. Klikam więc zakładkę buttons, wybieram

6:52Primary i z bazy komponentów wybieram przycisk sprint primary.

7:00Zaznaczam wszystkie jego instancje, wszystkie jego stanty i po chwili zostaną one zaimportowane.

7:08Teraz mogę sobie tutaj jeszcze zmienić nazwę.

7:13Ten jest default.

7:16Ten jest hover.

7:19Wszystkie zaaplikowane do Zeroheight elementy możemy przeglądać za pomocą inspektora.

7:28To rozwiązanie na pewno spodoba się programistom,

7:33chociaż myślę, że programistom dużo bardziej podoba się nie inspektor w

7:36zakładce design, ale zakładka obok, czyli code.

7:40Miejsce, w którym mogą wkleić swój przygotowany dla danego designu kod.

7:47Czyli przechowujemy w jednym miejscu

7:48zarówno komponenty w formie graficznej, jak i gotowej funkcjonalności.

7:53Możemy również

7:55dokładnie określić zasady stosowania danego elementu, łącznie z do and don't.

8:02Jak widzisz Zeroheight czy inne podobne temu narzędzia pozwalają stworzyć naprawdę

8:08ciekawe, efektowne, a przede wszystkim funkcjonalne dokumentacje

8:13design systemów, które potem będziesz mógł w łatwy sposób udostępniać wszystkim

8:19interesariuszom i zapewnić sobie spójność w budowaniu swoich produktów.

8:27Zachęcam Cię, abyś z dokumentował cały

8:30projekt wykonany w trakcie naszych ćwiczeń w jednym z tego typu narzędzi.