Jak przetrwać wdrożenie Design Systemu? ~ Marek Brzeziński

Jak przetrwać wdrożenie Design Systemu? ~ Marek Brzeziński

Myślisz, że wprowadzenie Design Systemu to najlepsze, co możesz zrobić w swojej organizacji? Lepiej uważaj! Po drodze jest wiele pułapek, o których warto pamiętać. Mogą one skutecznie utrudnić codzienną pracę. Lektura tego tekstu z pewnością pomoże Ci lepiej przygotować się do skutecznego wdrożenia.

Z tego artykułu dowiesz się:

  • W jakie najgroźniejsze pułapki wdrażania Design Systemu możesz wpaść
  • Kiedy warto go wprowadzać
  • Jak to zrobić skutecznie – kilka kroków do osiągnięcia celu

 

Po co jest Design System?

Zacznijmy od tego, dlaczego chcesz go wprowadzić. Być może masz już dość chaosu zarządczego, w którego efekcie ten sam element wygląda inaczej w każdym z projektów. Często wszystkie są projektowane od nowa, co zabiera cenny czas. Programiści także muszą zakodować nowe elementy, a to generuje dodatkowe błędy i jeszcze bardziej drenuje Twój budżet.

Design System wydaje się być prostą receptą na tego typu bolączki. Wszystkie elementy są zaprojektowane w konkretny sposób i zebrane w jednym repozytorium. Każdy z projektantów może wybrać je sobie jak z katalogu i przeciągnąć do projektu, a programista pobierze odpowiedni kawałek kodu i wrzuci funkcjonalność na serwer produkcyjny.

Czy tak jest naprawdę?

problemy

Największe problemy podczas wdrażania

Niestety powyższa wizja to utopia, która nie wytrzymuje zderzenia z rzeczywistością. Bardzo szybko okazuje się, że brakuje wybranych komponentów, a zaprojektowanie nowych zajmie za dużo czasu. Poszczególne zespoły decydują się wtedy często na tworzenie własnych elementów, co tylko wprowadza jeszcze większy chaos projektowy. 

Bazując na własnym doświadczeniu, wyróżniam trzy największe problemy pojawiające się przy wdrażaniu Design Systemu.

1.Unikalne wymagania projektowe

Stosowanie Design Systemu zawsze jest kompromisem pomiędzy spójnym wyglądem a realizacją potrzeb użytkowników. Bardzo często okazuje się, że wśród dostępnych komponentów nie ma takiego, którego potrzebują odbiorcy twojej aplikacji. Może się też zdarzyć, że element używany z powodzeniem w innych projektach jest niezrozumiały i nieintuicyjny dla Twoich użytkowników. 

2.Czas wdrażania nowych elementów

Niestety Design System bardzo często spowalnia pracę. Szczególnie w momentach, kiedy element, którego potrzebujesz, nie jest dostępny. Jeśli to zewnętrzny zespół dostarcza zbiór komponentów ł, możesz zgłosić zapotrzebowanie na nowy element, ale musisz czekać, aż zostanie stworzony. Zazwyczaj w tym samym czasie realizuje się więcej niż jeden projekt, przez co pojawia się pytanie: która funkcjonalność powinna mieć wyższy priorytet?

3.Komunikacja w dużej organizacji

Synchronizacja wysiłków projektowych w takim miejscu zabiera sporo czasu. Przede wszystkim trzeba go wygospodarować na wymianę wiedzy i rozwiązyanie problemów, jeśli masz kilka systemów korzystających z tych samych komponentów. Nagle okazuje się, że zamiast prostego oszczędzania pieniędzy, trzeba tak naprawdę dokładać zasoby w celu utrzymania całej inicjatywy poprzez przeciągające się dyskusje i ustalenia.

To tylko wierzchołek potężnej góry lodowej. Być może po tym wstępie skutecznie zniechęciłem Cię do rozważania stosowania Design Systemu. Jednak nie porzucaj nadziei. Jest parę rzeczy, które ostatecznie pomogą Ci podjąć dobrą decyzję.

Kiedy warto wprowadzić Design System?

Opłaca się poświęcić na to czas i pieniądze w kilku konkretnych przypadkach.

Projekty zewnętrzne/wewnętrzne

Jeśli Twoje aplikacje lub strony są udostępnione publicznie dla wszystkich w sieci, dobrze jest dbać o spójną identyfikację wizualną takich produktów. Zapewnia to profesjonalny wizerunek organizacji i pomaga użytkownikom łatwiej odnaleźć się w produktach. Wtedy Design System jest naturalnym rozwiązaniem potrzebnym w organizacji i warto poświęcić czas na jego wdrożenie.

Użytkownicy

Jeśli rozmawiamy o produktach wewnątrzfirmowych lub dostępnych po zalogowaniu, to bardzo ważne jest zidentyfikowanie użytkowników, którzy z nich korzystają. Zazwyczaj warto uspójniać tylko te aplikacje, z których na co dzień korzystają te same grupy użytkowników. Nie ma sensu inwestowanie w spójny design kolejnego systemu, jeśli korzysta z niego zupełnie inna grupa ludzi. Takie podejście widać często w aplikacjach bankowych. Część dla klientów indywidualnych nierzadko znacząco różni się od części dla klientów biznesowych.

Projektanci

Nawet jeśli masz różne grupy użytkowników i zupełnie odmienne systemy, to czasami warto wdrożyć Design System, żeby usprawnić pracę zespołu projektowego. Ustalając standardy projektowe do najważniejszych elementów interfejsu, można zaoszczędzić dużo czasu (nie trzeba opracowywać ich za każdym razem od podstaw) i poświęcić go na ważniejsze/trudniejsze elementy. W dalszej części artykułu opisuję, jak zrobić to mądrze.

zespół deweloperów

Zespół deweloperski

Kwestie techniczne to chyba najbardziej obszerny temat podczas wprowadzania Design Systemu. Bardzo często w organizacjach jest więcej niż jeden zespół deweloperski. Zazwyczaj pracują one nad różnymi aplikacjami w zakresie jednego ekosystemu i zdarza się, że dobierają rożne technologie do swoich projektów. To może skutecznie utrudnić pracę nad jednym spójnym, zbiorem komponentów. Warto wspólnie z nimi podjąć decyzję, jakie rozwiązanie będzie dla nich na co dzień najlepsze. Może zespoły będą chciały korzystać z gotowych komponentów, a może wygodniejsze będą style zdefiniowane w CSS.

Pomyśl o swoim konkretnym przypadku i zastanów się, które strony lub aplikacje warto uspójniać, a które dołożą tylko pracy (założę się, że obecnie masz jej i tak dużo). Kiedy już wstępnie ocenisz swój przypadek, możesz się zabrać za właściwe wdrożenie.

 

Wprowadzanie Design Systemu krok po kroku

Uzyskaj zgodę swojej organizacji

Koniecznie musisz zdobyć poparcie menedżerów. Wprowadzenie Design Systemu to bardzo duża zmiana organizacyjna i, według mnie, żadna oddolna inicjatywa tego typu nie ma szans przetrwać. Przedstaw zalety, ale także wady nowego rozwiązania. Pokaż, w jakie obszary organizacja musi zainwestować i jaką wartość to przyniesie. Im dokładniej się przygotujesz i im więcej konkretnych informacji przedstawisz, tym większa szansa, że transformacja będzie stała. 

Zdecydujcie też razem, kto podejmuje ostateczne decyzje projektowe elementów Design Systemu. Polecam włączyć w taką dyskusję wszystkich product ownerów, których będzie dotyczyła zmiana. To ich projekty będą musiały dostosować się do wytycznych i konieczne jest, żeby wiedzieli, czemu warto to zrobić. 

Wybierz elementy do uspójnienia

Pamiętaj, że nie musisz od razu wprowadzać pełnego Design Systemu. Przejrzyj swoje strony oraz aplikacje i oceń, które elementy można uwspólnić. Stosując nomenklaturę „Atomic Design” autorstwa Brada Frosta, każdy z systemów można podzielić na elementy o różnej złożoności. Atomy to najbardziej podstawowe elementy interfejsu: typografia, kolory, przyciski, pola do wprowadzania tekstu. Molekuły to elementy złożone z kilku atomów. Przykładem może być wyszukiwarka z etykietą, polem do wpisania frazy oraz przycisku „szukaj”. Jeszcze bardziej złożone są organizmy. Tu mówimy już np. o połączeniu elementu wyszukiwarki z listą wyników. 

Nawet atomy mogą znacząco różnić się pomiędzy systemami. System wyświetlający duże ilości danych na jednym ekranie potrzebuje małych różnic wielkości pomiędzy nagłówkami tekstowymi, żeby zmieścić więcej informacji. Za to na stronie marketingowej lepiej sprawdzają się duże różnice w nagłówkach, bo to przyciąga uwagę czytelników. Tak samo jest z bardziej skomplikowanymi elementami interfejsu. Jeden projekt będzie potrzebował prostych filtrów do tabeli, a inny złożonego mechanizmu z zapisywaniem ulubionych wyszukiwań. 

Nie ma jednego uniwersalnego Design Systemu i musisz strategicznie zdecydować, które elementy warto uspójniać.

Koniecznie ustal też, na ile wolności pozwalasz swoim systemom w tworzeniu unikalnych rozwiązań.

komunikacja międzyzespołowa

Zadbaj o komunikację między zespołami

Im lepiej projektanci w Twojej organizacji się znają, tym większe jest prawdopodobieństwo, że będą wymieniali się projektami i wspólnie rozwiązywali problemy. Często zatrudnieni w dużych organizacjach, nawet jeśli wiedzą nawzajem o swoim istnieniu, są skutecznie zniechęcani do utrzymywania relacji międzyzespołowych przez ilość codziennej pracy. To znaczny problem, szczególnie jeśli chcesz zadbać o spójność rozwiązań.

Zastanów się, w jaki sposób możesz zadbać o regularność takich kontaktów. Dobrym rozwiązaniem jest zorganizowanie cyklicznego wydarzenia, podczas którego będziecie mieć możliwość konsultowania konkretnych rozwiązań i wymiany pomysłów. Konieczne jest jednak aktywne planowanie tematów takich spotkań i dbania o to, żeby się odbyły. W innym wypadku ludzie uznają je za bezowocne i przestaną przychodzić przez nawał pracy w projektach.

Pracujcie mądrze

Według mnie najlepszym sposobem na utrzymywanie odpowiedniej komunikacji pomiędzy projektantami jest wspólna praca nad konkretnymi funkcjonalnościami. W Twojej organizacji na pewno zdarzy się sytuacja, w której różne zespoły projektowe będą pracowały nad podobnymi rzeczami. Mogą to być na przykład formularze. Lepiej, żeby projektanci z obu zespołów razem przyjrzeli się wymaganiom projektów i zastanowili, jaki design komponentów będzie najlepszy. W ten sposób będziecie w stanie szybciej zidentyfikować problemy projektowe i zyskacie czas na mierzenie się z innymi wyzwaniami. 

Zbierajcie swoje decyzje projektowe w jednym miejscu

Ten punkt wiąże się z poprzednim i można go zastosować w każdej organizacji, niezależnie od tego, czy używasz Design Systemu. 

Zapisuj swoje decyzje projektowe, szczególnie jeśli dotyczą mniej oczywistych funkcjonalności – na przykład ucinania zbyt długich nazw w polach formularza albo sposobów walidacji formularzy. Zazwyczaj dopracowujemy je dopiero na dalszych etapach projektu i taki zbiór przypadków bardzo przyspiesza pracę. 

Żeby dodatkowo usprawnić tworzenie tego typu listy, polecam zaimplementowanie jednego z rozwiązań do trzymania dokumentacji w repozytorium Git. Takie podejście nosi nazwę „docs-as-code” i pozwala uniezależnić się od płatnych platform, jak Zero Height albo Frontify. Polecam choćby Nuxt Docs Theme, czyli prostą aplikację stworzoną za pomocą frameworku Nuxt. Tym, co mi się najbardziej podoba w takim rozwiązaniu, jest możliwość wykorzystania funkcjonalności platform do przechowywania kodu. 

Na przykład na Gitlab każdy może otworzyć wątek dyskusji na temat nowej lub problematycznej funkcjonalności. Mogą się w niej udzielać wszyscy projektanci z organizacji (warto ustawić jako aktywne powiadomienia o powstaniu nowego wątku). Następnie z takiej dyskusji można utworzyć oddzielną gałąź kodu, w której wprowadza się konkretne opisy do dokumentacji. Dużą zaletą platformy Gitlab jest edytor tekstowy online, więc nawet osoby nieumiejące korzystać z Gita i terminala mogą w łatwy sposób pisać taką dokumentację. Na końcu, w momencie, w którym wszyscy zgodzą się na konkretne rozwiązanie, gałąź może zostać scalona z główną dokumentacją. W ten sposób wyłapujemy wszelkie wątpliwości i ustalamy w jednym miejscu wspólne podejście, a wiedza organizacyjna nie ucieka.

Utrwalcie proces

Jak z nauką każdego nawyku, kluczowe jest powtarzanie go. Najlepiej wypracować proste procesy, stosować je, a później dopracowywać. Moje doświadczenie podpowiada, że bardzo ciężko jest wprowadzić Design System za jednym zamachem i lepiej zastosować metodę małych kroków. Proponuję skupić się na zbieraniu dyskusji i decyzji projektowych w jednym miejscu. Mam poczucie, że wszystkich rzeczy, o których napisałem, ta przynosi największą długodystansową wartość. 

Podsumowanie

Mam nadzieję, że po lekturze tego artykułu lepiej przygotujesz się do wdrożenia Design Systemu w swojej organizacji. Powyższe rady, nawet jeśli proste, stanowią według mnie sedno całej zmiany. Przy zastosowaniu powyższych punktów wybór odpowiednich narzędzi i organizacja szczegółów powinny być proste. 

Inspiracje

Autor

Marek Brzezinski

Marek Brzeziński

Absolwent neurokognitywistyki (specjalizacja: interakcja człowiek-komputer) z ponadośmioletnim doświadczeniem w User Experience. Pracował w agencji interaktywnej Kalicińscy.com i Centralnym Ośrodku Informatyki. Od 5 lat projektuje systemy wspierające wczesną fazę odkrywania leków w firmie Roche Polska (https://it.roche.pl). Jego specjalnością jest facylitacja warsztatów i rozwiązywanie złożonych problemów projektowych.

Linkedin: https://www.linkedin.com/in/sara-kapela-23533b80/