Zonal | Matt Staniszewski

Zonal to brytyjski dostawca technologii dla branży HoReCa, oferujący rozwiązania od terminali POS dla restauracji po oprogramowanie do zarządzania magazynem i zapasami. W miarę jak konkurencja w sektorze technologii dla gastronomii rosła, Zonal musiał poradzić sobie z coraz większą presją na modernizację swojego produktu. Konkurencyjne platformy inwestowały mocno w dopracowane, skalowalne systemy projektowe, które dawały spójne interfejsy i szybsze cykle rozwoju.

Żeby nie zostać w tyle, Zonal potrzebował działającego systemu projektowego, który zwiększyłby efektywność, ograniczył fragmentację między aplikacjami i dał spójne doświadczenie zarówno użytkownikom wewnętrznym, jak i klientom końcowym.

Zastrzeżenie: wszystkie opinie wyrażone w tym tekście są moje własne i mogą nie odzwierciedlać oficjalnego stanowiska firmy. Niektóre szczegóły projektowe zostały zmienione.

Moja rola

Jako Principal Designer odpowiadałem za przebudowę systemu projektowego Zonal: inicjatywę, która miała ujednolicić UI/UX w ponad dziesięciu aplikacjach wewnętrznych używanych przez zespoły i klientów w branży HoReCa.

Największym wyzwaniem było utrzymywanie i rozwijanie systemu w warunkach dużej wewnętrznej złożoności: współpraca z wieloma projektantami i ośmioma zespołami deweloperskimi, każdym działającym na innym frameworku, z innymi priorytetami i innym rytmem wydań.

Cele strategiczne

Naszym zadaniem było zbudowanie skalowalnego systemu projektowego, który ujednolici ponad dziesięć produktów Zonal używanych w środowiskach HoReCa, w oparciu o trzy cele.

Skalowalność. Zbudowanie elastycznego systemu projektowego, który da się skalować na ponad 10 produktów.

Spójność i testowanie w praktyce. Aktualizacja i standaryzacja komponentów oraz wzorców UX, a także testowanie decyzji projektowych na rzeczywistych ścieżkach w działających aplikacjach Zonal.

Dostępność. Wprowadzenie i wdrożenie standardów dostępności na desktopie i mobile.

Razem te cele miały pozwolić Zonal ograniczyć powtórzenia, zwiększyć efektywność deweloperów i poprawić doświadczenia użytkowników w rozdrobnionym portfolio produktów.

Analiza i budowanie fundamentów

Zaczęliśmy od przeglądu tego, jak w Zonal wygląda projektowanie. Zewnętrzna agencja dostarczyła wcześniej bibliotekę komponentów, ale brakowało jej spójności z finalnymi produktami i nie rozwiązywała poważnych problemów z użytecznością. Żeby to naprawić, poprowadziłem przegląd aplikacji Zonal z udziałem wielu zespołów: analizowaliśmy przepływy pracy, hierarchię wizualną i wzorce w całym ekosystemie, szukając strukturalnych dziur i niespójności projektowych.

Obejmowało to audyt i rozebranie gotowej biblioteki, zmapowanie ścieżek UX na desktopie i mobile oraz stworzenie jednej warstwy fundamentów: typografii, układu, odstępów i ikonografii. Na tej podstawie zaplanowaliśmy kolejne etapy: modernizację komponentów, przepisanie dokumentacji i wdrażanie nowych standardów projektowych w działających produktach.

Wnioski z analizy

Spójność komponentów była sercem tego projektu. Każdy element wizualny, od przycisków do tabel danych, musiał zostać sprawdzony pod kątem funkcji, wyglądu i reakcji na interakcję w całym portfolio produktów. Wprowadziłem proces przeglądu, który utrzymał spójność wizualną nawet wtedy, gdy zespoły produktowe miały bardzo różny poziom nadzoru.

Zrozumienie użytkowników

Żeby nie oddalać się od rzeczywistości, stworzyłem trzy wewnętrzne persony:

Projektant: Alex to projektant produktu, który tworzy intuicyjne i wizualnie spójne interfejsy. Pracując w wielu zespołach, Alex opiera się na systemie, żeby zachować spójność, ograniczyć powtórną pracę i sprawić, że każdy punkt kontaktu z użytkownikiem wydaje się naturalny i znany. Cel: korzystać z systemu, żeby szybko projektować, prototypować i wdrażać spójne interfejsy, które łatwo skalują się między platformami, co oszczędza czas i wzmacnia zaufanie do marki.

Deweloper: Jordan to full-stack deweloper z pragmatycznym podejściem do budowania. Jordan ceni narzędzia, które sprawiają, że integracja komponentów jest bezbolesna i niezawodna, dzięki czemu aktualizacje wychodzą bez problemów, a współpraca z projektantami nie rodzi frustracji. Cel: bez wysiłku integrować gotowe komponenty projektowe, zachowując czysty, niezawodny i łatwy w utrzymaniu kod.

Operator restauracji: Sam prowadzi ruchliwą restaurację skoncentrowaną na gościach i od niedawna korzysta z nowych aplikacji Zonal, żeby efektywniej zarządzać zamówieniami, menu i personelem. Cel: czerpać z systemu Zonal jak najwięcej, żeby przyspieszyć codzienną pracę, poprawić doświadczenie gości i dać zespołowi narzędzia do sprawniejszej pracy.

Trzy zasady pracy

Od początku miałem jasną wizję i swobodę, by ją realizować. Nasza baza użytkowników była duża, zawodowa i zróżnicowana, więc oparłem całe doświadczenie na trzech zasadach:

Przeglądać. Przeglądanie i aktualizowanie odstępów, kolorów, interakcji i tagów dostępności.

Koordynować. Koordynacja z innymi projektantami przy zbieraniu i zarządzaniu wariantami komponentów.

Decydować. Podejmowanie ostatecznej decyzji, czy nowy wariant trafia do biblioteki, i przegląd każdego nowego projektu przed wejściem w development.

Wprowadzanie w życie

Szybko natrafiliśmy na przeszkody strukturalne i kulturowe, które utrudniły wdrożenie dużo bardziej, niż się spodziewaliśmy. Zespoły deweloperskie działały w silosach, każdy na swoim frameworku front-endowym i swoim procesie dostarczania, co od razu rodziło tarcia w tym, jak aktualizacje były udostępniane i wdrażane. Jednocześnie product ownerzy często stawiali na szybkość kosztem jakości: rutynowo pomijali QA i wypuszczali aktualizacje bez żadnej informacji zwrotnej po wdrożeniu czy iteracji. Prośby projektantów o właściwy przepływ pracy (odkrywanie → projekt → feedback → development) były regularnie odrzucane, co zmuszało zespół projektowy do działania reaktywnego, a nie strategicznego.

Te problemy wykraczały poza codzienną frustrację. W organizacji brakowało spójności i jasnej odpowiedzialności za decyzje. Zrozumiałem, że nawet najlepszy system projektowy nie zadziała bez akceptacji na każdym poziomie organizacji. Zmieniłem więc podejście: postawiłem na jasną dokumentację, budowanie relacji między zespołami i tłumaczenie długofalowej wartości spójności projektowej. Precyzja techniczna była niezbędna, ale bez wsparcia organizacji sama nie wystarczała.

Aktualizacje projektowe

Równolegle zbudowaliśmy od zera ponad 10 nowych wzorców UI, w tym rozwiązania dla wyszukiwania, filtrowania, tabel danych i powiadomień. Te wzorce pomogły ustandaryzować zachowania w produktach, które wcześniej opierały się na przypadkowej, niespójnej logice. Ujednoliciliśmy też najważniejsze elementy wizualne: układy, typografię i systemy kolorów, dbając o to, by każdy ekran spełniał aktualne standardy dostępności i zachowywał spójność z marką.

Ponad 30 podstawowych komponentów przeszło przegląd i aktualizację, by poradzić sobie z najbardziej wymagającym przypadkiem użycia w Zonal: prezentowaniem gęstych, ustrukturyzowanych danych w wysoce interaktywnych tabelach. Te zmiany wykraczały poza kosmetykę: dotyczyły odstępów, przejrzystości danych, reakcji na interakcję i zgodności z wymogami dostępności.

Akcenty projektowe

Żeby wzmocnić identyfikację i użyteczność, wprowadziliśmy własną ikonografię i elementy brandingowe dopasowane do każdego produktu Zonal. Dzięki temu łatwiej było odróżnić poszczególne oferty, a hierarchia wizualna między modułami stała się czytelniejsza. Nasz zespół przebudował też dokumentację komponentów od podstaw, żeby była jasniejsza i bardziej praktyczna dla projektantów i deweloperów, zwłaszcza tych pracujących z bardzo specyficznymi przypadkami użycia albo zagnieżdżonymi strukturami danych.

Organizacja komponentów

Na koniec stworzyliśmy osobne biblioteki dla interfejsów mobilnych i desktopowych, uwzględniając różne potrzeby i konteksty użytkowników, przy jednoczesnym zachowaniu wspólnych fundamentów, takich jak siatki układu, skale typografii i zestawy ikon, które utrzymywały wszystko w spójności.

System zaprojektowaliśmy z myślą o elastyczności, skalowalności i dostępności, ale jego sukces w długim terminie zależał od wdrożenia, a to okazało się poza zasięgiem naszego zespołu projektowego.

Wydanie i wdrożenie

Niestety, wykonanie się nie udało, mimo dwóch lat pracy. Braki w komunikacji wewnętrznej i procesy zamknięte w silosach regularnie rozbijały fazę wydania, co czyniło porozumienie między zespołami prawie niemożliwym. Deweloperzy nie koordynowali aktualizacji między zespołami, co prowadziło do niezgodnych wersji komponentów i chaosu przy wdrażaniu. Nawet nowo zaprojektowane ekrany często ignorowały zaktualizowany system, wracając do starych, przestarzałych komponentów, które psuły spójność wizualną i funkcjonalną.

System miał obsłużyć wszystkie osiem zespołów deweloperskich. Jeden z zespołów UI zaimplementował go w kodzie, ale jak dotąd trafił tylko do jednego produktu Zonal. Pozostałe zespoły mają go przejąć później. Większość nowych projektów nadal korzystała ze starych albo niedopasowanych bibliotek, całkowicie pomijając system, jakby nigdy go nie stworzono. Brak centralnej kontroli jakości pogarszał sytuację: nie istniał żaden proces weryfikacji wdrożenia, a pętle informacji zwrotnej od projektantów po prostu nie działały. Praca trafiała na produkcję bez żadnej oceny, więc błędy i niespójności wychodziły na jaw dużo później, jeśli w ogóle.

Mimo systematycznych postępów i dokładnej dokumentacji, pod koniec mojej pracy system trafił tylko do jednego produktu. Rozdźwięk między intencją projektową a wykonaniem po stronie developmentu odzwierciedlał głębsze problemy organizacyjne, których żadna ilość dopracowanych komponentów nie mogła naprawić.

Rezultat

System projektowy miał obsłużyć osiem zespołów, a pod koniec mojej pracy trafił do jednego, z planem adopcji przez pozostałe. To doświadczenie nauczyło mnie, gdzie kończą się możliwości liderowania projektowego w organizacji bez odpowiedniej struktury operacyjnej.

Co się udało. Dwa lata współpracowałem z utalentowanymi, zaangażowanymi ludźmi, którym naprawdę zależało na dobrym projektowaniu. Zbudowałem system oparty na dostępności, skalowalności i przejrzystości.

Dlaczego utknął. Projekt utknął przez procesy produktowe i inżynieryjne. Żeby design trafił na produkcję, potrzebuje akceptacji wewnątrz organizacji, zgodności technicznej i dyscypliny wydawniczej. W Zonal nie było centralnego QA ani procesu sprawdzania, czy to, co trafia na produkcję, zgadza się z systemem.

Zobacz, co Zonal buduje dziś.