Czy UX powinien znać się na frontendzie?

Choć łączy nas wspólny cel, często stajemy po dwóch stronach barykady i nie potrafimy wypracować wspólnego rozwiązania. Specjaliści UX i Frontendowcy, jak psy i koty. Co może zrobić UX aby współpraca była bardziej efektywna? Czas włożyć kij w mrowisko.

Podobnych tematów w Internecie można znaleźć całkiem sporo, jednakże zazwyczaj autorzy dywagują nad tym czy to programista powinien znać się na szeroko pojętym UX. Ja natomiast chciałbym podejść do tematu od drugiej strony i nieco krytycznie spojrzeć na pracę specjalistów od użyteczności. Będzie nieco kąśliwie, ale to dlatego, że na przestrzeni kilku lat doświadczenia w pracy z nimi, zdążyłem sobie już wyrobić pewne (niezbyt) pozytywne zdanie o nich. Nie zamierzam jednak podważać potrzeby posiadania zespołu UX, nie będę też robił personalnych wycieczek. Jeżeli jednak poczujesz się tym wywodem urażony to zrób kilka ćwiczeń oddechowych i spróbuj jeszcze raz spojrzeć na wszystko z większego dystansu.



Był sobie projekt

Wszystko zaczyna się od projektu. A przynajmniej tak ja to widzę z punktu widzenia programisty, bo to co działo się przed projektem niezbyt mnie interesuje. Biznes rozwodzi się nad tym jak projekt jest wspaniały, jak bardzo innowacyjny, a developerzy zachwycają się stackiem technologicznym. Pojawiają się pierwsze zadania i cała ludzka maszyneria idzie w ruch. Firma co prawda ma już pierwsze makiety jak produkt ma wyglądać, ale postanawia zatrudnić jeszcze zespół UX aby popracował nad użytecznością. Wszystko ma być przecież na najwyższym poziomie, a końcowy klient ma być wręcz zachwycony gdy zobaczy gotowy produkt. Aplikacja nie tylko powinna pięknie wyglądać, ale także działać na wielu urządzeniach i być szybka jak to tylko możliwe. Dlatego też właśnie nad każdym aspektem projektu będzie pracowała rzesza specjalistów. Jak to pięknie brzmi, tak pięknie, że wręcz nie może się nie udać. Po serii spotkań programiści są gotowi z architekturą, a zespół UX ma już pierwsze „poprawione” makiety poszczególnych ekranów w aplikacji. No i się zaczyna.



Przychodzi UX do developera…

– Cześć, przesłałem wam na maila ekrany do tego procesu, w razie pytań piszcie.

Rzeczywiście e-mail się pojawił. Ręka na myszce zaczyna drżeć i już słychać przełykanie śliny. Są makiety, można więc zaczynać zadanie. Ale czy rzeczywiście można? Na pierwszy rzut oka tak, ale gdy zacznie się analizę, to wizja skończenia tego do końca sprintu zaczyna się oddalać. Kilka ekranów z różnymi nagłówkami, kontrolkami i całą gamą kolorów. Zaczynają się pierwsze pytania o wielkość czcionek, o różnice między nagłówkami, o te i tamte kontrolki, o wersje mobilną, o ten dziwny półprzezroczysty prostokąt z zanikającym gradientem i cieniem… Mail zwrotny tutaj nie pomoże, potrzebne jest spotkanie!

UX, możesz używać tego słowa, ale nie sądzę abyś znał jego znaczenie

…a potem developer do UXa

– Cześć! Dostaliśmy designy, ale nie ma widoków mobilnych. Myślałem, że robimy „Mobile First”?
– A tak! Będą jeszcze dzisiaj.
– Widok dla tabletów też zostanie uwzględniony?
– Tabletów?? A to robimy też na tablety?
– No tak, w końcu to RWD.
– Ok, będą będą. Jeszcze coś? Spieszę się na spotkanie.
– Hmm od czego teraz by zacząć…

Jest szansa, że ten fikcyjny dialog może się powtórzyć… cyklicznie. Ba! Może nawet dotyczyć w kółko tego samego! Uwierzcie, zdarzają się na tym świecie osoby, które mają permanentną sklerozę i ciągle powtarzają te same błędy. Jaka jest przyczyna takiego stanu rzeczy? Zazwyczaj jest to po prostu kwestia braku konsensusu w tym co my uważamy, że jest potrzebne do rozpoczęcia pracy. Więc jeżeli uda Wam się wypracować schemat działania z zespołem UX, powtarzalny schemat dostarczający niezbędne informacje do zabrania się do zadania, to zazdroszczę. Osobiście nie pamiętam żebym dostał dopięty design w 100% i zawsze jakieś pytanie się znajdzie.

Największe grzechy UX przeciwko developerom

Skoro dotarliście aż tutaj to wypada podzielić się z Wami moją listą spostrzeżeń na temat współpracy „Juiksów” z programistami. Najwięcej przygód z nimi miałem w poprzedniej firmie, która przy okazji była dużą korporacją, więc bardzo prawdopodobne, że w małych firmach gdzie ludzie współpracują se sobą na prawdę blisko, taki schemat zachowań nie występuje wcale.

1. Niekonsekwencja

Coś co zaburza mój mały wewnętrzny ład w każdym projekcie. Umawiamy się, że odległości między elementami będą wielokrotnością np. 4px, albo że korzystamy z gamy ośmiu kolorów i to wszystko. Finalnie i tak odległości będą określane na oko, a kolorów doliczysz się kilkudziesięciu (o różnicach tak niewielkich, że tylko oni to dostrzegą). Dorzuć do tego kilka czcionek i całą masę ich wielkości i możesz zacząć otwierać burdel.

2. Brak odpowiedniej wiedzy

Otwierasz design a tam margines 30.5px. UXy potrafią dostrzec półpiksele, a Ty nie? Pomijając kwestie natury czysto informatycznej, zarzut braku wiedzy tyczy się także np. braku informacji na temat wydajności poszczególnych urządzeń mobilnych. Myślę, że warto byłoby zainwestować w szkolenie, choćby wewnętrzne, aby wyrównać poziom wiedzy w zespole i dowiedzieć się czym tak na prawdę zajmuje się zespół developerski.

3. Ignorancja

Doświadczenie developerów powinno być dla zespołu UX skarbnicą wiedzy na temat tego, czy pewne rzeczy są wykonalne czy też nie, czy coś jest wydajne, czy wręcz przeciwnie. Niestety nie wszyscy potrafią słuchać, albo robią to po czasie, gdy już pierwsza wersja aplikacji zdążyła zniechęcić do siebie prawie wszystkich. Do tego punktu chciałbym również dołączyć ignorowanie nowych trendów, lub też wdrażanie ich wtedy gdy już się po prostu zestarzeją. Przy porannej kawie czytasz sobie, że hamburger menu to może nie jest to co chciałbyś wdrożyć u siebie, po czym dostajesz na designie nawet dwa, krwiście wysmażone. A osoby niepełnosprawne? Ciekawe ile specjalistów UX wie, że takie osoby też aktywnie korzystają z Internetu.

4. Brak szerszej perspektywy

Do tego punktu mógłbym przytoczyć nagminne zapominanie o dostarczeniu wyglądu każdego stanu kontrolki, czy też wyglądu na konkretne urządzenie. Niestety nie wszyscy potrafią się domyślić jak może wyglądać nowo zaprojektowany dropdown po rozwinięciu. Takie rzeczy należy po prostu opisywać. Przypomniała mi się jeszcze historyjka z poprzedniej firmy dotycząca ścieżki negatywnej w jednym procesie. Kiedy użytkownik wysyła żądanie do serwera to zdarzyć się może na prawdę wiele, może np. stracić łączność z siecią i fajnie by było w jakiś sposób na to zareagować. Jeden z UXów stwierdził, że nie ma potrzeby projektowania ekranu komunikatu błędu, bo przecież nie powinniśmy takowych popełniać! Także ten tego… w pracy potrafi być na prawdę wesoło.

5. Przesadzanie

Po kilku latach na walki froncie rzeczy takie jak modal w modalu człowieka po prostu nie dziwią. Szkoda tylko, że ostatecznie cierpi na tym klient. Na pewno sztuką jest znalezienie złotego środka pomiędzy na prawdę ubogim interfejsem, a czymś przeładowanym wodotryskami. Widać to szczególnie na mobile’u. Ale nie jest to niemożliwe! Dlatego nie zapominajmy, że nawet najładniejszy interfejs może być zabity ciężkimi animacjami, a przejrzysty formularz nieintuicyjną walidacją. Skomplikowane kontrolki są nie tylko trudne do wykonania, ale także trudne do opanowania przez osoby niepełnosprawne.

Podsumowanie

Czy w mojej opinii specjalista od UX powinien znać się na frontendzie? W pewnym zakresie oczywiście, że tak. To, że ktoś umie rysować, nie oznacza, że od razu stanie się architektem wnętrz i w naszej branży jest podobnie. Jest sporo technicznych aspektów, których znajomość znacząco poprawiłaby jakość współpracy z programistami, jak choćby rozumienie HTMLa. Pewna wiedza przychodzi wraz z doświadczeniem i mam tu na myśli kwestie np. przeładowanych interfejsów na urządzeniach mobilnych, ale są elementy których można się nauczyć na podstawowym poziomie, bez większego wysiłku. Wystarczą chęci.

Świat cyfrowy jest znacznie prostszy od świata rzeczywistego. Tutaj źle zaprojektowana kontrolka nie sprawi, że ktoś dorobi się uszczerbku na zdrowiu (choć kto wie…), tylko najwyżej da upływ swojej frustracji. Łatwość wejścia w ten świat sprawia, że absolwenci ASP falami uderzają do firm jako specjaliści od użyteczności, nie mając tak na prawdę większego pojęcia o tej dziedzinie. Źle zaprojektowany samochód nie pojedzie, albo kogoś pozbawi życia. Źle zaprojektowana strona… no cóż, to po prostu kolejny projekt.