Sytuacja kobiet w IT w 2024 roku
31.03.20207 min
Piotr Wegner
Britenet

Piotr WegnerFrontend & UX ManagerBritenet

Jak zintegrować zespół UX z zespołem frontendowym

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

Jak zintegrować zespół UX z zespołem frontendowym

W latach ’90 na ekranach 21-calowych, wypukłych odbiorników telewizyjnych królował japoński, okraszony włoskim dubbingiem serial – 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ę z 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 (no, w każdym razie ich znaczną część).

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ą osobnymi bytami – Zespół UX i Zespół Frontend. Zajrzyjmy na chwilę do środka każdego z nich i zerknijmy z jakich elementów każdy z tych zespołów może i powinien się składać.

Zespół UX złożony jest z kilku, różniących się zakresem działania i kompetencjami ról. W jego składzie znajdziemy na pewno badaczy (UX Researcher), projektantów (UX i UI Designers), osoby odpowiedzialne za prowadzenie warsztatów (UX Participators) czy też analitycy, mogący 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 poruszają 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 nie pojawiają się zbyt często w codziennych rozmowach.

Leo, why?

No dobrze, ale po co nam w zasadzie ten cały Zespół UX? Nasi frontendowcy sami realizują znakomicie projekty. No może nie są najładniejsze, ale utrzymywanie kolejnego zespołu to tylko 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 tylko za lepsze doświadczenia w obsłudze czy korzystaniu z aplikacji, a prawie 9 na 10 klientów zdecydowałoby się na współpracę lub korzystanie z aplikacji konkurentów, jeśli ich doświadczenia z bieżącym rozwiązaniem byłyby nieprzyjemne. Co więcej 75% użytkowników ocenia jakość i wiarygodność usługi tylko i wyłącznie na podstawie estetyki i tak zwanego pierwszego spojrzenia (które, swoją drogą, trwa średnio tylko 3,42 milisekundy).

Co więcej, zespół UX potrafi 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 końcowych etapach projektu, ponieważ wszystkie kluczowe zmiany zachodzą właśnie na etapie prototypowania. Dodatkowo unikamy mrożącego krew zjawiska jakim jest Feature Creep – “pełzające funkcjonalności”, które z każdym dniem rozszerzają nasz 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ą nam czy dana funkcjonalność jest nam niezbędna. W końcu zespół UX jest w stanie przetestować 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ąć niepotrzebnego wdrażania funkcjonalności i ich późniejszej modyfikacji na etapie wdrożenia.

Zespół UX może pomóc również na późniejszych etapach projektu. Pozytywne doświadczenia użytkowników naszych aplikacji przyczyniają się do podniesienia 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 wejść w buty użytkownika i precyzyjnie określić, które etapy sprawiają największe trudności w poruszaniu się po aplikacji (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 wszystkie te zebrane prace pozwalają na rzeczywiste oszczędności w innych obszarach. Stworzenie przyjaznej i funkcjonalnej aplikacji spowoduje, że nasi użytkownicy z chęcią sami powiedzą o niej znajomym czy współpracownikom. Taki kanał promocji marketingowej 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, na ten kanał nie wydamy ani złotówki. Za jego wykorzystanie zapłaciliśmy już inwestując w dobry i skuteczny zespół UX. Najlepszym przykładem oszczędności jest firma IBM, która [o wdrożeniu jednego z narzędzi zespołu UX – Design Thinking, w ciągu trzech lat osiągnęła oszczędności w swoich projektach na poziomie 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 wiedzieć jaki kąt dobrać, trzeba 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 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 paru miejscach, ale ich motyw przewodni pozostaje ten sam – iteracyjny postęp, rozwój projektu i nieustanne testowanie wypracowanych rozwiązań.

Kolejnym zapadką w kłódce, do której pasują wypustki na UXowym kluczu są frameworki. Przestrzeganie wypracowanych w konkretnym frameworku zasad projektowych bardzo usprawnia wdrożenie konkretnych rozwiązań, ponieważ zespół programistów będzie 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ą narzędzi takich jak 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 zechcemy użyć.

Balistyka zespołów

Jedną z dziedzin, którą 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 wzajemnie.

Mimo bezpośredniego kontaktu z klientem, programiści często podchodzą do swoich zadań bardzo mechanicznie, próbując starannie wykonać zapisane w backlogu zadania i nie starając się wejść we wcześniej już wspomniane 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 “uczłowieczyć” pracę developera. Przejście przez i zrozumienie 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 wyników pracy kolegów i koleżanek z Zespołu Frontend poprzez Code Review może podnieść również jakość rozwiązań wypracowywanych w Zespole UX. Dokładne komentarze, wskazujące miejsce jakiejś niedoskonałości, na przykład na makiecie pozwolą Zespołowi UX uniknąć 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ć, ale również sam 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ść technologii takich jak HTML czy CSS, czy 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.

No i warto?

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 przyniosło 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 stawiających na dostarczanie doskonałych doświadczeń dla swoich użytkowników. 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 zespoły mogą liczyć na szybki zwrot z tej inwestycji. Co więcej nie będzie to tylko zwrot wymierny, wyrażony dodatkowymi złotówkami. Inwestycja w 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 tylko zadowolonych klientów?

<p>Loading...</p>