E-commerce

Frontend

UX

W Królestwie Kalendarza, czyli jak zintegrować zespół UX z zespołem frontendowym

Grafika z wykresem obrazującym punkty styku współpracy zespołu UX z zespołem frontendowym

Poznaj specyfikę zespołów UX i frontendowego oraz dowiedz się, jakie korzyści płyną z ich połączenia.

W latach ’90 na 21-calowych wypukłych ekranach odbiorników telewizyjnych królował japoński serial, okraszony włoskim dubbingiem – Yattodetaman. Fabuła nie była specjalnie odkrywcza. Dwójka nastolatków – Beppe i Tina – pomocników znanego detektywa, pomaga zagubionej w czasie księżniczce Niedzieli, próbując przeszkodzić jej kuzynce w schwytaniu mistycznego Pawia Kosmosu. Oczywiście w każdym odcinku młodzi docierają do momentu, w którym nie mogą poradzić sobie z wrogiem sami, i aby przetrwać muszą przywołać z innego wymiaru wielkiego robota – Gwiezdnego Króla, który ostatecznie rozprawia się ze złą księżniczką i jej sługami. Ale żeby przywołanie się udało, potrzebne są dwa artefakty – klucz i kłódka. Dokładnie taki sam przepis na sukces możemy wykorzystać, chcąc dostarczyć naszym klientom doskonałą aplikację, która rozwiąże ich wszystkie problemy, a przynajmniej ich znaczną większość.

Składniki przepisu

Naszym kluczem i kłódką są dwa zespoły, które w wielu organizacjach istnieją i współgrają ze sobą, ale często pozostając przy tym osobnymi bytami – Zespół UX i Zespół Frontend. Zajrzyjmy na chwilę do środka każdego z nich i sprawdźmy, z jakich elementów powinny się składać. Każdy z członków zespołu UX pełni określoną funkcję, a zakres jego działań i kompetencji jest różny. Wśród nich znajdziemy badaczy (UX Researcher), projektantów (UX i UI Designers), osoby odpowiedzialne za prowadzenie warsztatów (UX Participators) czy też analityków, mogących zbudować wysokopoziomową wizję produktu (UX Architects). Odrobinę mniej zdywersyfikowany pozostaje Zespół Frontend. Pomijając kwestie czysto techniczne, wynikające na przykład z języka, w jakim specjalizują się programiści, możemy wyróżnić dwie role: Web Developera (osoba odpowiedzialna głównie za wdrożenie wyglądu i interakcji w aplikacji) i Business Logic Developera (programista zajmujący się tworzeniem logiki biznesowej aplikacji). Co więcej, te dwie role często łączy jedna osoba, stąd wymienione nazwy stanowisk nie padają zbyt często w codziennych rozmowach.

Leo, why?

Można się zastanawiać, do czego nam jest w zasadzie potrzebny ten cały Zespół UX? Przecież nasi frontendowcy sami realizują znakomicie projekty. Może nie są najładniejsze, ale utrzymywanie kolejnego zespołu generuje koszty, a na ładne oczy (czytaj: design), to w dzisiejszym świecie raczej niczego się nie dostanie.
W praktyce jest dokładnie odwrotnie. Według raportu CEI aż 86% badanych konsumentów była skłonna zapłacić więcej za lepsze doświadczenia z obsługi czy korzystania z aplikacji. Prawie 9 na 10 klientów wybrałoby konkurencyjne aplikacje, gdyby rozwiązania, z których aktualnie korzystają, nie spełniały ich oczekiwań pod względem designu. Co więcej, 75% użytkowników ocenia jakość i wiarygodność usługi wyłącznie na podstawie estetyki i tak zwanego pierwszego spojrzenia (które trwa średnio tylko 3,42 milisekundy) . Tym, co przemawia za przydatnością zespołu UX jest to, że potrafi on w skuteczny sposób obniżyć koszt developmentu poprzez prototypowanie. Dzięki temu możemy estymować nasze projekty z dużo większą dokładnością i unikamy strukturalnych zmian w ich końcowych etapach. Dzieje się tak, ponieważ wszystkie kluczowe zmiany zachodzą właśnie na etapie prototypowania. Dodatkowo unikamy mrożącego krew w żyłach zjawiska, jakim jest Feature Creep – „pełzające funkcjonalności”, które z każdym dniem rozszerzają zakres projektu o niepotrzebne elementy. Nie zdajemy się już wtedy tylko na wewnętrzny głos, mówiący: „to może się kiedyś przydać”, tylko opieramy się na badaniach UX, które w sposób jednoznaczny odpowiadają na pytanie, czy dana funkcjonalność jest niezbędna. W końcu zespół UX jest w stanie przetestować to, jak będzie postrzegana zawartość naszej aplikacji. Badania pokazują, że prawie co drugi użytkownik przestaje korzystać z aplikacji bądź witryny internetowej, ze względu na nieatrakcyjny content . Takie testy na etapie prototypowania pozwalają uniknąć wdrażania niepotrzebnych funkcjonalności i konieczności ich późniejszej modyfikacji.

Zespół UX może być wsparciem także na późniejszych etapach realizacji projektu. Pozytywne doświadczenia użytkowników naszych aplikacji, przyczyniają się do zwiększenia ich poziomu przywiązania do marki czy produktu. Korzystając z narzędzi, takich jak Customer Journey Map, heatmapy czy eye- i mousetracking, zespół UX może niejako „wejść w buty” użytkownika i precyzyjnie określić, które etapy w poruszaniu się po aplikacji sprawiają największe trudności (tzw. bottlenecki). Dane z tych obszarów pozwalają zespołowi UX zoptymalizować projekt i dzięki temu zwiększyć retencję użytkowników.

W końcu te wszystkie prace zebrane razem przyczyniają się do osiągnięcia rzeczywistych oszczędności w innych obszarach. Stworzenie przyjaznej i funkcjonalnej aplikacji spowoduje, że nasi użytkownicy będą sami ją zachwalać swoim znajomym czy współpracownikom. Taki kanał promocji jest oczywiście jednym z najskuteczniejszych i buduje największe zaufanie – przecież nikt nie poleci nam produktu, z którego sam nie jest zadowolony. Co więcej, taka forma promocji jest bezpłatna. Najlepszym przykładem oszczędności, jakie może przynieść korzystanie ze wsparcia zespołu UX, jest IBM. Firma ta po wdrożeniu jednego z narzędzi zespołu UX – Design Thinking, w ciągu trzech lat zaoszczędziła w swoich projektach ponad 20 milionów dolarów. Pozwoliło to między innymi zredukować czas wytworzenia oprogramowania i jego testowania o 33%.

Wkładamy klucz do kłódki

Skoro wiemy już, jak działa nasz klucz (Zespół UX), to teraz musimy włożyć go pod odpowiednim kątem do naszej kłódki (Zespół Frontend). Żeby zrobić to idealnie, musimy znać punkty przecięcia, w których oba zespoły będą mogły współpracować. Przyjmując pewne uproszczenie, możemy te punkty dopasować do trzech grup: narzędzi, frameworków i idei.

Do tych ostatnich należy zaliczyć podejścia bliskie obu zespołom, na przykład ideę atomiczności (Atomic Design), czyli podziału projektu (zarówno programistycznego, jak i graficznego) na możliwie małe, funkcjonalne elementy i łączenie ich w większe grupy (molekuły, organizmy, szablony). Dla obu zespołów nieobca jest również idea pracy w sprintach. Oczywiście Design Sprint i Agile Sprint różnią się od siebie w kilku miejscach, ale ich motyw przewodni pozostaje ten sam – iteracyjny postęp, rozwój projektu i nieustanne testowanie wypracowanych rozwiązań.

Kolejną zapadką w kłódce, do której pasują wypustki na UXowym kluczu są frameworki. Przestrzeganie wypracowanych w danym frameworku zasad projektowych, usprawnia wdrożenie konkretnych rozwiązań, ponieważ zespół programistów może korzystać z tych samych założeń i gotowych komponentów. Doskonałymi przykładami frameworków, z których korzystają oba zespoły, są systemy stworzone przez gigantów świata IT: Material Design od Google czy Human Interface opracowany i utrzymywany przez Apple.

Miejscem, gdzie klucz i kłódka stykają się najmocniej, powodując też największe tarcie, są narzędzia, które zespół UX wykorzystuje do dostarczenia programistom wkładu do ich pracy. Dobre przygotowanie i przekazanie projektu za pomocą Zeplin, Framer X czy InVision stało się już standardem. Oczywiście takich narzędzi istnieją dziesiątki i tylko od nas zależy, którego z nich zechcemy użyć.

Balistyka zespołów

Jednym z działów, którym zajmuje się balistyka, jest badanie indywidualnych śladów, jakie gwintowana lufa zostawia na wystrzelonym pocisku. Podczas obracania klucza w kłódce, na obu częściach pozostają podobne zagłębienia – rzeczy, których zespoły uczą się od siebie nawzajem.

Mimo bezpośredniego kontaktu z klientem programiści często podchodzą do swoich zadań bardzo mechanicznie. Starannie realizują zapisane w backlogu zadania, ale nie starają się przy tym „wejść w buty” zwykłych użytkowników aplikacji, którą właśnie tworzą. Jest to przestrzeń, w której skorzystanie z narzędzi zespołu UX może wnieść pierwiastek ludzki do pracy developera. Poznanie i przejście przez Customer Journey Map powinno pomóc zespołowi programistów zrozumieć sens wykonywanych działań i, przy okazji, pozytywnie wpłynąć na ich motywację.

Z drugiej strony, sumienność i precyzja codziennego sprawdzania poprzez Code Review wyników pracy kolegów i koleżanek z Zespołu Frontend, może podnieść jakość rozwiązań wypracowywanych w Zespole UX. Dokładne komentarze, wskazujące miejsce wystąpienia jakiejś niedoskonałości, na przykład na makiecie, pozwolą Zespołowi UX uniknąć zebrania całego worka drobnych poprawek w następnych etapach projektu.

Oba zespoły mogą również skorzystać na znajomości podstaw pracy drugiej strony. Zespół Frontendowy dużo łatwiej będzie mógł implementować oraz proponować skuteczne i funkcjonalne rozwiązania, jeśli jego członkowie będą mieli podstawowe kompetencje z zakresu projektowania użyteczności. Już sama świadomość istnienia, na przykład heurystyk Nielsena, pozytywnie wpływa na realizację projektów przez zespół developerski. Z drugiej strony podstawowa znajomość takich technologii jak HTML czy CSS bądź ograniczeń JavaScript pozwala zespołowi UX projektować rozwiązania, które będą możliwe do wdrożenia w skończonym czasie i budżecie.

Czy warto?

Włączenie zespołu UX nie tylko do zespołu frontendowego, ale do całej organizacji, przynosi wymierne korzyści. Wcześniej wspomniana firma IBM, po wprowadzeniu do struktury zespołu UX i zastosowaniu metodologii Design Thinking, osiągnęła zwrot na poziomie 301%! Czas dostarczania kolejnych produktów na rynek zmniejszył się o połowę, a cały proces projektowy został zredukowany o 75%. W 2006 roku Facebook założył tak zwany Fundusz UX (UX Fund) i zainwestował po 5000 dolarów w 10 firm dbających o zapewnianie doskonałych doświadczeń swoim użytkownikom. W gronie tych firm były między innymi Apple, Nike, Netflix czy Electronic Arts. W ciągu jednego roku zwrot z inwestycji wyniósł niemal 40% (dla porównania w tym samym czasie giełda w Nowym Jorku przyniosła średni zwrot na poziomie 15%). W ciągu 10 lat od rozpoczęcia eksperymentu (zahaczając o poważny kryzys w 2008 roku) cała inwestycja przyniosła zwrot na poziomie 450%!

W rozpędzającym się coraz bardziej świecie IT żadna organizacja nie może pozwolić sobie na pozostanie w tyle. Jak pokazują liczby, firmy, które zainwestują w doświadczone zespoły, mogą liczyć na szybki zwrot poniesionych kosztów. To jednak nie wszystko. Dobry zespół UX to również inwestycja w przywiązanie naszych użytkowników do marki czy aplikacji i zbudowanie ich zaufania. A kto z nas nie marzy o posiadaniu wyłącznie samych, zadowolonych klientów?

Zdjęcie profilowe Piotra Wegnera

Piotr Wegner

Lider obszarów Frontend i Product Design z kilkunastoletnim doświadczeniem w branży. Świeżo upieczony absolwent Executive Master of Business Administration IT. Change manager odpowiedzialny za promocję podejścia produktowego. FRISowy Wizjoner w myśleniu i Strateg w działaniu. Na pierwszy miejscu stawia ambicję oraz chęć działania – reszty można nauczyć każdego. Z Britenet związany jest od ponad 5 lat.