Design system: 10 pytań, które powinieneś zadać na następnym spotkaniu

Autor: Marcin Sasin, UI Designer w Autentika

Wiesz, że potrzebujesz design systemu, ale nie masz pewności, czy masz wewnętrzne zasoby i kompetencje, by go zbudować? Oto lista kontrolna na następne spotkanie z zespołami produktowymi i projektowymi – z kluczowymi pytaniami i sygnałami ostrzegawczymi, na które warto zwrócić uwagę.

Nadszedł czas. Masz dość marnowania czasu i energii na projektowanie i rozwijanie nowych produktów. Nie możesz już znieść słabego UX, który frustruje wszystkich. Doprowadza cię do szału fakt, że każdy z twoich systemów wygląda i działa inaczej. I że kosztuje to fortunę.

Podjąłeś decyzję: organizacja potrzebuje design systemu (a może nawet dwóch). Wiesz o tym, a korzyści są dla ciebie oczywiste. Nie będzie łatwo, ale jesteś gotowy na tę rewolucję (i masz na nią budżet). Ale jak upewnić się, że zespoły produktowe i projektowe mają odpowiednie umiejętności i kompetencje? Czy będą wiedzieć, od czego zacząć? Czy mają doświadczenie w budowaniu design systemów? Czy mają właściwych ludzi w swoich zespołach?

W Autentika mamy doświadczenie w pracy z dużymi firmami nad ich design systemami i znamy wszystkie zawiłości tego wyzwania. Wiemy też, że niektóre organizacje – na przykład holdingi medialne – często potrzebują dwóch niezależnych design systemów – i odważymy się stwierdzić, że wewnętrzne zespoły nie zawsze są w stanie podołać temu zadaniu.

W tym artykule wymieniamy kluczowe pytania, które powinieneś zadać na następnym spotkaniu, aby ocenić, czy ludzie w twojej firmie mają wiedzę i zasoby do zbudowania design systemu. Uważaj – niektóre odpowiedzi, które możesz usłyszeć, to sygnały ostrzegawcze. Jeśli je usłyszysz, powinieneś rozważyć zwrócenie się do zewnętrznych ekspertów z udokumentowanym doświadczeniem – w przeciwnym razie ryzykujesz niepowodzeniem całego projektu.

Przeczytaj też: Głos eksperta: Jak zbudować design system? .

Podstawy

1) Czy wiemy, co chcemy zbudować?

Pierwsze pytanie, które powinieneś zadać, dotyczy tego, czy ludzie w twojej organizacji rozumieją, czym jest design system i czy akceptują jednolitą, ogólnofirmową definicję.

Design system można zdefiniować na wiele sposobów – i nie wystarczy powiedzieć, że to „biblia firmy dla projektowania i rozwijania produktów cyfrowych". Czasem ludzie mylą design system ze style guide'em, który jest tylko jednym z wielu elementów DS, albo z UI kitem – czyli zestawem elementów interfejsu reprezentujących interakcje w odniesieniu do konkretnego produktu. Design system to nie plik Figma z zagnieżdżonymi symbolami, pliki Sketch ani inne pliki graficzne. To nawet nie biblioteka komponentów ani bootstrap – oprócz komponentów musi zawierać wiedzę i kontekst ich użycia.

Jeśli brakuje wspólnego rozumienia design systemu, prowadzenie procesu jest niemożliwe, bo każdy ma inny pomysł na to, co chcecie stworzyć. W takim przypadku pierwszym krokiem może być opracowanie podstawowej dokumentacji z definicjami i założeniami.

Co zawiera design system?

2) Czy wszyscy rozumieją, dlaczego potrzebujemy design systemu?

Może być oczywiste, że twoja organizacja potrzebuje design systemu: ma rozległy ekosystem projektów IT, które muszą się rozwijać, planuje nowe projekty, albo zespoły projektantów i developerów mają trudności z komunikacją i osiąganiem spójnych rezultatów. Wiesz, że marnujesz czas, bo tworzenie aplikacji trwa w nieskończoność. Zdajesz sobie sprawę ze słabości swojego UX i braku spójności między systemami. Wiesz też, że płacisz dwa razy (albo dziesięć razy) za te same rozwiązania wdrażane oddzielnie w wielu miejscach.

Ale czy twoi kluczowi interesariusze o tym wiedzą?

Idea design systemu polega na tym, by stworzyć go raz i używać wielokrotnie. Ale to ty powinieneś zadbać o to, by wszyscy w organizacji byli świadomi korzyści, jakie niesie design system, takich jak:

• Większa efektywność czasowa i kosztowa przy budowaniu nowych produktów,
• Spójny branding aplikacji w ramach ekosystemu,
• Obniżone koszty rozwijania istniejących aplikacji,
• Lepsze doświadczenie użytkownika,
• Zoptymalizowana kontrola ról i uprawnień.

Kluczowe jest też to, by ludzie rozumieli zmianę, którą przyniesie design system – zwłaszcza dlatego, że wdrożenie nie jest końcem projektu (do tego jeszcze wrócimy).

3) Czy jesteście gotowi traktować design system jak produkt?

Zanim przejdziemy do pytań o kluczowe umiejętności i kompetencje potrzebne do zbudowania design systemu, chcemy zwrócić uwagę na częstą pułapkę. Wielu menedżerów myśli, że design system to projekt – zestaw działań prowadzących do jednego, określonego celu. My wolimy traktować go jako produkt, który tworzy wartość dla użytkownika, rozwiązując konkretny problem.

To, co wyróżnia produkt, to fakt, że nigdy nie jest skończony. Jego cechy wymagają ciągłej pracy nad refaktoryzacją i rozwojem komponentów. Jako produkt design system potrzebuje zasobów i wsparcia nie tylko po to, by go zbudować, ale także by go utrzymywać i rozwijać.

Można powiedzieć, że tworzenie design systemu składa się z dwóch faz. Pierwsza, trwająca zazwyczaj od sześciu do dwunastu miesięcy, to faza rozwoju, gdy intensywnie pracujecie nad budowaniem nowych komponentów i dodawaniem ich do biblioteki. Z czasem biblioteka się zapełnia, a nowe elementy są dodawane coraz rzadziej. Następnie przychodzi faza utrzymania (12+ miesięcy), która nigdy się nie kończy – przynajmniej dopóki produkt istnieje. Kluczowe jest zrozumienie tego i odpowiednie zaplanowanie pracy oraz zaangażowania pracowników.

Umiejętności i kompetencje zespołu

4) Czy macie wystarczająco dużo ludzi i odpowiedni zespół do tego zadania?

Gdy znasz już podstawy, czas pomyśleć o zespole design systemu. Pierwszą rzeczą, którą prawdopodobnie będziesz chciał ocenić, jest to, czy masz wewnętrzne zasoby, by go zbudować. Z naszego doświadczenia wynika, że zespół design systemu powinien składać się z co najmniej dwóch pełnoetatowych pracowników: pełnoetatowego UI designera i pełnoetatowego front-end developera.

„Pełnoetatowy" to tu kluczowe słowo. Jeśli myślisz, że możesz wyrywać pracowników z ich regularnych obowiązków na kilka godzin tygodniowo, żeby rozwijali design system, to nie zadziała. Potrzebujesz zespołu – ludzi pracujących razem, uzgadniających i wdrażających procesy.

Możesz też rozważyć dodanie do zespołu UX designera i product ownera, który pomoże ci zarządzać projektem, rozwijać strategie, planować i realizować roadmapę. W miarę rozwoju projektu rośnie też zespół: możesz potrzebować content designera, UX writera, badaczy, analityków danych i innych.

Pamiętaj, że po najintensywniejszej fazie pracy (po około 12 miesiącach) prawdopodobnie nie będziesz potrzebować pełnoetatowego zespołu – wystarczy zaangażowanie ludzi na poziomie 20–25% ich czasu.

Rozwój design systemu to ciągła podróż

5) Czy zespół ma odpowiednie umiejętności i kompetencje?

Wielkość zespołu jest równie ważna jak umiejętności i kompetencje tworzących go ludzi. Powinieneś dokładnie ocenić, czy osoby pracujące dla ciebie poradzą sobie z następującymi zadaniami:

• tworzenie dokumentacji procesów
• przeprowadzanie wywiadów z użytkownikami
• zbieranie wymagań systemowych
• tworzenie fundamentów i struktur systemu
• tworzenie komponentów systemu i ocena ich użyteczności

Pamiętaj, że mówimy o zespole – ludzie, których zatrudnisz do tego projektu, muszą współpracować, nieustannie wymieniać się pomysłami i dawać sobie wzajemnie informacje zwrotne. W świecie design systemów komponent zaprojektowany przez UI wpływa na front-end i odwrotnie. Dlatego kluczowe jest, by osoby nad nim pracujące myślały całościowo o tym, jak różne elementy współgrają ze sobą, tworząc spójne doświadczenie dla końcowych użytkowników. Z tego powodu twój zespół powinien być zorientowany na użytkownika: rozumieć jego potrzeby i przekładać informacje zwrotne na rozwiązania.

Równorzędnie ważne są umiejętności komunikacyjne – w końcu twój zespół będzie prezentować wizję kluczowym interesariuszom i partnerom. Innymi przydatnymi „miękkimi" kompetencjami są ciekawość i prawdziwa pasja do designu – jeśli masz kogoś, kto naprawdę interesuje się design systemami, najprawdopodobniej osiągniesz świetne rezultaty.

6) Czy zespół ma doświadczenie w budowaniu design systemów?

To prawdopodobnie jedno z najważniejszych pytań, które powinieneś zadać i poważny sygnał ostrzegawczy, jeśli odpowiedź brzmi „nie". Budowanie design systemów wymaga szczególnych umiejętności, a ekspertów na rynku jest niewielu.

Planując design system, zapytaj, czy ludzie mają wcześniejsze doświadczenie w tej dziedzinie, jak często to robili i jak dawno temu. „Świeżacy", którzy chcą zmierzyć się z wyzwaniem design systemu, mogą popełniać kosztowne błędy, mimo entuzjazmu do nowych zadań. Jeśli masz wątpliwości co do ich doświadczenia, rozważ zatrudnienie zewnętrznej firmy konsultingowej i zespołu wykonawczego z udokumentowanym doświadczeniem. Takie podejście eliminuje ryzyko niepowodzenia i gwarantuje spokój ducha.

Masz więcej pytań o design system w swojej organizacji? Porozmawiajmy —->

Technologia i procesy

7) Jakiej technologii będziecie używać?

Twoi partnerzy powinni wiedzieć, jakich narzędzi i technologii będą używać w trakcie procesu. Warto sprawdzić, czy mają konkretne aplikacje na myśli, takie jak:

• Design: Figma, Sketch, inVision, Adobe XD
• Development: React, Angular, Vue, webpack, Node, styled-components, xstyled, Typescript, CSS-in-JS
• Dokumentacja: Storybook, zeroheight, Docusaurus

Wyzwanie z zestawem narzędzi polega na tym, że w dużej mierze zależy on od technologii, której już używasz w swojej organizacji – czy istniejące aplikacje zostały zbudowane w jednym, dwóch czy trzech frameworkach i czy masz stare systemy legacy. Poprzeczka podnosi się jeszcze bardziej, jeśli chcesz budować aplikacje mobilne z jednym źródłem kodu na wielu platformach.

8) Czy macie procesy do tworzenia i utrzymywania design systemu?

Oprócz narzędzi kluczowe jest posiadanie odpowiednich procesów. Powinieneś zapytać zespoły produktowe i projektowe, czy przygotowały proces rozwijania i utrzymywania design systemu, tworzenia dokumentacji oraz dzielenia się wiedzą o nowym DS.

Proces dzielenia się wiedzą jest tu szczególnie ważny, bo design system nie powstał bez powodu. Jego celem jest szybsze i tańsze tworzenie nowych aplikacji, dlatego organizacja musi zadbać o to, by nowe produkty nie powstawały w oderwaniu od design systemu. Ludzie muszą wiedzieć, że design system istnieje i jak z niego korzystać.

Innym aspektem, którego nie wolno zaniedbać, jest proces dokumentacji. To coś, co po prostu musi być zrobione, a jeśli ktoś w zespole podważa konieczność dokumentowania procesu – to sygnał ostrzegawczy. Dokumentacja to miejsce, gdzie wychodzi wiele błędów i niespójności. Czasem dochodzisz nawet do wniosku, że potrzebujesz dodatkowej osoby w zespole, która mogłaby się tym zająć – więc z wyprzedzeniem zastanów się, jak ten proces będzie wyglądał i jakich narzędzi zamierzasz użyć.

Niektóre technologie i narzędzia, które mogą być przydatne

9) Kto będzie odpowiedzialny za utrzymanie design systemu?

Zbudowanie design systemu to dopiero początek pracy – prawdziwa praca zaczyna się wtedy, gdy DS jest już wdrożony, bo teraz ludzie powinni z niego korzystać przy budowaniu nowych produktów. Dlatego dobrze jest mieć w organizacji osobę odpowiedzialną za dzielenie się wiedzą i śledzenie wszystkich zespołów, które mają używać DS.

Niełatwo znaleźć taką osobę: musi ona dobrze znać całą organizację i mieć ogólny ogląd wszystkich zespołów i procesów w dziale IT. Najlepiej, żeby taka osoba była rodzajem „wolnego elektronu", niezwiązanego z żadnym zespołem. Dzięki temu może krążyć po firmie, uczestniczyć w różnych spotkaniach, rozmawiać z ludźmi i „zarządzać przez obecność". Możemy go/ją nazwać „właścicielem przestrzeni" – kimś, kto wie, co się dzieje i co jest planowane w zakresie rozwoju.

10) Jak będziecie mierzyć efektywność design systemu?

Twój zespół powinien znać prognozowane rezultaty, jakie design system przyniesie biznesowi pod względem szybkości i efektywności. Ile czasu można zaoszczędzić dzięki design systemowi? O jaką optymalizację kosztów chodzi? Jaki procent komponentów z design systemu zostanie użyty do zbudowania nowej aplikacji?

Z naszego doświadczenia wynika, że oszacowanie tych wyników jest jak najbardziej możliwe – na przykład jeśli zbudujesz aplikację w cztery miesiące zamiast sześciu, zaoszczędzisz co najmniej 60 osobodni, co już przekłada się na konkretną kwotę pieniędzy. Twoi partnerzy powinni być w stanie udzielić podobnej odpowiedzi – a jeśli nie są w stanie – to kolejny sygnał ostrzegawczy.

Podsumowanie

Te 10 pytań powinno dać ci dobry obraz wiedzy i umiejętności pracowników oraz pomóc zdecydować, czy możesz zbudować design system z wewnętrznym zespołem. Może się okazać, że wewnętrzne zasoby są niewystarczające – pracownicy są zajęci innymi zadaniami lub brakuje im niezbędnego doświadczenia, by podjąć się tak złożonego zadania. Nie martw się – to normalna sytuacja i nie oznacza, że nie możesz zbudować design systemu.

Sygnały ostrzegawcze lub niejasne odpowiedzi, które usłyszysz na spotkaniu, powinny skłonić cię do poszukania pomocy z zewnątrz. Ale nie musi to być typowa agencja stosująca rozwiązania „jeden rozmiar dla wszystkich". Może to być partner, z którym będziesz współpracować przy tworzeniu systemu dostosowanego do twoich potrzeb.

Przeczytaj case study z naszej pracy nad design systemem dla Wirtualnej Polski