Zespół Design System jako DesignOps? Czemu nie!

W wielu organizacjach zespół odpowiedzialny za Design System traktowany jest wyłącznie jako „strażnicy komponentów”. Oczekuje się, że dostarczą bibliotekę i pilnują spójności, ale niewiele osób dostrzega, jak głęboka wiedza tego zespołu może usprawnić pracę wszystkich projektantów i programistów.

Zespół Design Systemu to coś więcej niż tylko „klocki” – to centrum wiedzy o komponentach, wzorcach UX i procesach projektowych. To unikalna pozycja, z której można wspierać zespoły produktowe w codziennej pracy i pomagać im rozwiązywać realne problemy w bardziej przemyślany i efektywny sposób.

Przecież osoby zajmujące się Design Systemem są praktycznie i naturalnie zapoznane z każdym projektem / produktem używającym bibliotek!

Zmiana, która wzbudziła mój sprzeciw … na początku

Jakiś czas temu organizacja zdecydowała się połączyć zespół Design Systemu z zespołem Standaryzacji. Pierwsza myśl? Sprzeciw. Wydawało mi się, że to zupełnie różne obszary: Design System to konkretne komponenty, wzorce i spójność interfejsów, a Standaryzacja to coś szerszego, obejmującego procesy i narzędzia.

Ale im dłużej się nad tym zastanawiałem, tym bardziej dochodziłem do wniosku, że to genialny pomysł. W końcu od początku swojej pracy, jako zespół Design Systemu, wspieraliśmy inne zespoły nie tylko wiedzą o komponentach, ale także w kwestiach związanych z procesami, narzędziami i standaryzacją pracy. Robiliśmy to naturalnie.

Pomagaliśmy znaleźć najlepsze rozwiązania, które były efektywne, spójne i zgodne z potrzebami użytkowników. Zmiana, która początkowo wydawała mi się rewolucją, okazała się uświadomieniem tego, co już robiliśmy. Tylko teraz dostaliśmy do tego bardziej formalną rolę.

Przykład z życia wzięty

W nowej roli zauważyliśmy coś ciekawego, a właściwie nazwaliśmy po imieniu. Ponad połowa zgłoszeń, które do nas trafiały, dotyczyła:

💠 Nowych komponentów
💠 Nowych wariantów istniejących komponentów
💠 Nowych funkcjonalności

W teorii zlecenia brzmiały logicznie i sensownie. W praktyce? Po analizie zwykle okazywało się, że:

🔍 Większość tych zgłoszeń nie miała uzasadnienia.
🔍 Istniało już rozwiązanie.

Przykład? Ktoś potrzebował nowego „banera” do aplikacji. Ale po kilku pytaniach okazywało się, że wystarczy lepiej użyć istniejącego alertu. Albo inny zespół chciał „unikalny” przycisk, który – jak się okazało – już istnieje jako wariant w naszym Design Systemie, tylko projektant nie zajrzał do dokumentacji albo po prostu nie wiedział że w innym zespole produktowym tak to zostało już rozwiązane.

Co to pokazało?

1️⃣ Zespoły często nie mają pełnej wiedzy o istniejących rozwiązaniach.
2️⃣ Zamiast sięgać po sprawdzone komponenty, próbują wymyślić koło na nowo.
3️⃣ Wiele problemów da się rozwiązać przez usprawnienie procesów projektowych, a nie przez tworzenie kolejnych elementów.

Dzięki naszej wiedzy o Design Systemie i wzorcach UX, mogliśmy te zgłoszenia przeanalizować i zaproponować lepsze, prostsze rozwiązania. Oszczędziliśmy czas, zasoby i uniknęliśmy zbędnego skomplikowania.

Rola projektanta Design Systemu jako DesignOps-a

Właśnie takie działania – optymalizowanie pracy zespołów, poprawa procesów i rozwiązywanie problemów systemowo – są esencją DesignOps. Połączenie Design Systemu ze Standaryzacją uświadomiło mi, że to, co robiliśmy od zawsze, to w sporej części DesignOps w praktyce.

Zespół Design Systemu:

🔧 Nie tylko dostarcza komponenty, ale pomaga je dobrze wykorzystać,
🛠 Rozwiązuje problemy systemowo, z myślą o długoterminowej efektywności,
🤝 Wspiera zespoły produktowe, dzieląc się wiedzą i usprawniając ich pracę.

To naturalna rola dla specjalistów, którzy znają Design System „od podszewki” i potrafią spojrzeć na projekt z perspektywy całej organizacji ale i innych projektów, o których projektanci nie mogą wiedzieć.

Kończąc

Połączenie Design Systemu i Standaryzacji to nie tylko logiczny krok, ale też krok w stronę większej efektywności. Zespół Design Systemu to naturalni partnerzy dla zespołów produktowych. Dzięki swojej wiedzy mogą:

✅ Pomóc rozwiązywać problemy szybciej i skuteczniej,
✅ Optymalizować procesy projektowe,
✅ Oszczędzać czas i zasoby, eliminując zbędną pracę.

Naturalne i kluczowe jest, by po intensywnej fazie projektowania i produkcji, gdzie wymagana jest pełna kreatywność i produktywność, przejść do etapu rozwijania i wspierania Design Systemu. To właśnie wtedy zespół może skupić się na optymalizacji procesów i rozwiązywaniu realnych problemów organizacji.

Bo czasem nie trzeba projektować czegoś nowego. Czasem wystarczy dobra analiza, rozmowa i wsparcie, żeby znaleźć najlepsze rozwiązanie.

PS.

Mój tip na koniec, znacie metodę pięciu „dlaczego?” (5 Whys) Sakichi Toyody? Zadajcie zlecającemu albo sobie 5x pytanie „dlaczego”.

😮 1x Dlaczego potrzebujesz nowy banner?
🥺 Bo musze wyjaśnić funkcjonalność w aplikacji
😮 2x Dlaczego musisz wyjaśnić userowi funkcjonalność?
🥺 Bo jej użytkownik nie rozumie
😮 3x Dlaczego jej nie rozumie?
🥺 Bo jest skomplikowana
😮 4x Dlaczego jest skomplikowana?
🥺 Bo jest dużo pól na jednej stronie
😮 5x Dlaczego jest dużo pól na jednej stronie?
🥺 Bo nikt nie pomyślał żeby podzielić na kroki albo sekcje …

Działa!

Tagi: Design System, DesignOps