UX i web developerzy? Oczywiście, że tak!

Zdezorientowany użytkownik stojący pomiędzy dziurą, w której chowają się UXi a jaskinią developerów
Projektanci UX na prawo, developerzy lewo (albo na odwrót) — a co z użytkownikiem?

Wiele mówi się o tym, że projektanci UX powinni posiadać wiedzę techniczną. Sam jestem zwolennikiem tezy, że dobry UX powinien wiedzieć, jak działa HTML i CSS (jak inaczej mógłby brać się za zagadnienia związane z dostępnością, albo naprawdę wydajnie prototypować?) i, że przyda mu się też wiedza z pogranicza “web developerki”. Technologie zmieniają się szybko, a to, jak kształtują zachowania ma znaczący wpływ na nasze podejście do pracy.

Rzadko jednak mówi się o tym, że web developerzy mogą bardzo dużo zyskać na nauce podstawowych metodologii UX. Czego możemy nauczyć nasze koleżanki i kolegów? Jak uprzyjemnić im życie, pracę i interakcje z zespołami tworzącymi produkty cyfrowe? I po co?

Każdy sobie rzepkę skrobie

O ile produkt może zostać zaprojektowany przez developerów, UXów i content writerów zamkniętych w osobnych pokojach i komunikujących się tylko przez Slack, o tyle jest to bardzo zły pomysł. Zwłaszcza w przypadku programistów, których tok logicznego rozumowania i umiejętność do odpowiadania na założenia projektowe w kodzie nie zawsze idzie w parze z empatią dla użytkownika końcowego. My, projektanci też nie jesteśmy lepsi — często myślimy, że na psychologii i obserwacji użytkownika świat definitywnie się kończy. Tymczasem, niczym w jaskini Platona, specjaliści siedzący w swoich niszach nie dostrzegą niczego poza czubkiem własnego nosa. Co nam grozi?

1. Problemy w interakcji z użytkownikiem

Rozwiązania ważne dla użytkownika są często “psute” niewłaściwym doborem wzorców projektowych lub technologii, na przykład dlatego, że tak łatwiej. Przykłady można mnożyć: CAPTCHA, idiotyczne wymogi dotyczące haseł (“Hasło musi zawierać 8 do 16 znaków, jeden wykrzyknik, siedem znaków specjalnych, odcisk buta i nutę z antenką”) czy wygasające w czasie sesje, które uniemożliwiają poprawne wypełnianie formularzy osobom niepełnosprawnym.

2. My i oni

Separacja ról może zajść za daleko — co często powoduje wytwarzanie niezdrowych podziałów w zespole projektowym. W wyniku tego powstają “obozy” programistów i projektantów, a na piedestał wchodzą osobowości, które dominują kanały komunikacyjne, czasem skutecznie zagłuszając głosy zdrowego rozsądku. Rozłamy w drużynach współpracowników mogą przynieść tylko problemy. Nie zawsze łatwo potem towarzystwo wprowadzić w stan względnego spokoju i wzajemnego rozumienia.

3. Dystans do użytkownika końcowego

Każdy, kto choć palec macza w procesie projektowym kierowanym metodologiami UX staje się automatycznie projektantem. Każda linia kodu, która może spowodować, że wydajność systemu zmieni się na lepsze lub gorsze ma znaczenie dla użytkownika końcowego. Każde rozwiązanie związane z bezpieczeństwem (np. metoda autentykacji czy sposób, w który system pobiera opłatę kartą) ma wpływ na doświadczenie klienta na końcu systemowego kija. Utrzymywanie “userów” dla siebie powoduje niepotrzebne problemy i naraża projekt na niepowodzenie. A my, projektanci UX, często właśnie tak postępujemy — zamykając się w naszej bibliotece wyników badań i obwarowując się kartkami z nabazgranymi prototypami. Zapominamy o tym, że zmniejszanie dystansu pomiędzy użytkownikiem a całym zespołem projektowym to jedno z naszych głównych zadań.

Co zatem możemy zrobić dla naszych koleżanek i kolegów, którzy zjadają JavaScript i Pythona na śniadanie? Czego możemy ich nauczyć?

Trzy narzędzia, które przydadzą się każdemu developerowi

1. Proto-persony

Prawdziwe, “grube” persony wymagają oczywiście ugruntowania w badaniach. Nic jednak tak nie nastraja developerów na właściwy, skoncentrowany na użytkowniku tok myślenia jak zaangażowanie ich w proste projektowanie proto-person. Wystarczy na kartce papieru spisać efekt przemyśleń na prosty temat: kim jest nasz użytkownik? Jaki jest jego/jej profil demograficzny? Czym się zajmuje i jakie ma oczekiwania w stosunku do produktu? Jakie ma podstawowe potrzeby (oczywiście w kontekście projektowym)? Oczywiście, tak naprawdę grozi nam ciężki brak obiektywizmu (już widzę, jak akademicy zagryzają ołówki), ale odpowiedzmy sobie na pytanie: czy wolimy developera, który chociaż trochę zwizualizował sobie wymagania czy takiego, dla którego “user” to wciąż tylko ciąg znaków w bazie danych? Po tym, jak developerzy w fazie wstępnej (nawet sami dla siebie i bez żadnego ugruntowania wiedzy w badaniach, po prostu używając zdrowego rozsądku) zabiorą się do pracy nad proto-personami, zaangażujmy ich w proces definiowania właściwych person. W ten sposób zweryfikujemy ich tok myślenia. Już na tym etapie jednak będziemy z nimi za pan brat. Rybka połknie haczyk.

2. Proste podróże użytkownika

Nie inaczej jest z user journeys. Jak wiesz, często są one wynikiem pracy rzeszy ludzi, efektem pocenia się i gięcia w spazmach na warsztatach projektowych. Co jednak złego w tym, żeby programistyczna brać, początkowo z twoją pomocą a potem sama, rozrysowała podstawową ścieżkę podróży przez produkt, oznaczając na niej tylko dwie rzeczy: akcje, które podejmuje użytkownik i odpowiedź systemu, który dostarcza mechanizmu pozwalającego wykonać te akcje? Kiedy wałkuję to ze studentami, na osi czasu oznaczamy dwa pola na każdy etap podróży: “user action” i “system response”. Nawet coś tak prostego powoduje zwrócenie uwagi na to, że software to nie tylko linie kodu, ale i interakcja z człowiekiem.

3. Szkice i prototypy

“No dobrze”, powiesz, “ale na co developerom back-end babranie się w tym?” Odpowiem w ten sposób: praca programistów zawsze uwidacznia się w interfejsie. Dlaczego więc nie zachęcić ich do szkicowania interfejsów po to, by zobaczyli, jak efekt ich działań może wpłynąć na doświadczenie końcowego użytkownika?

Przeprowadź ciekawe ćwiczenie: posadź dowolnego znajomego Ci programistę na stołku i każ mu (lub jej) naszkicować interfejs produktu zanim w ogóle Ty, projektant, zacząłeś pracę. Nagle okaże się, że pojawia się masa pytań i ciekawych pomysłów, a po dyskusji obydwoje dojdziecie do wniosku, że użytkownik końcowy nie jest już tylko wyimaginowanym człowiekiem z portfelem w kieszeni.

Uwaga — pamiętaj o zmianie kontekstu!

Opisane narzędzia powinny zostać użyte w kontekście uświadamiania istnienia grupy docelowej, a nie jej badania! To bardzo ważne. Nie oczekuj od developerów znajomości detali metodologii badawczej. Nauczy ich tych prostych technik po to, by łatwiej mogli zogniskować swoje myślenie na użytkowniku końcowym, ale traktuj to bardziej jako zabawę i tak to sprzedawaj. Pozwól im się „zbiasować”. Nie chodzi tu o to, by nagle dział programistów ubzdurał sobie, że twoja praca — praca projektanta — już nikomu nie jest potrzebna tylko o to, by zmieniło się podejście z technologicznie-centrycznego na takie, w którym centralne miejsce w procesie zajmuje użytkownik. Wyjaśnij koleżankom i kolegom, że zweryfikowane wyniki badań mogą wymóc na nich nieco inne podejście do konkretnych zagadnień, ale pozwól im pobawić się w badaczy. To naprawdę przynosi dobre rezultaty. Oczywiście, nie poprzestawaj na tym i wcielaj developerów w zespoły zajmujące się właściwymi badaniami, które określają funkcjonalność produktów.

Efekty tej metody widzę po projektach swoich studentów, którzy przygotowują się do wykonywania zawodu developerów back-endu a także po poprawiającej się jakości pracy developerów, którzy przeszli przez prowadzone przeze mnie szkolenia dla organizacji. Ilekroć wezmą się za proto-persony, podróże użytkownika i szkice w fazie planowania swojego projektu, tworzą o wiele porządniejszy materiał. Nic tak nie poprawia jakości ich pracy jak “lekki skręt” w stronę myślenia właściwego na co dzień projektantom UX, właśnie takim jak Ty.

Notka na marginesie

Jak zapewne zauważyłeś, w poprzednim wpisie odnosiłem się do Ciebie w formie żeńskiej. W tym — w męskiej. Aby zaadresować problem, jaki język polski stawia przed piszącym, który chce komunikować się z czytelnikami w sposób właściwy dla ich płci (a nie ciągle pisać “zrobił”, “zjadł”, “zaprojektował” — dlaczego nie “zrobiła”, “zjadła”, “zaprojektowała”?), zamierzam pisać raz tak, a raz tak. I już. Jest 21 wiek i trochę równości w przekazie się przyda. Chrzanić cyfrowy patriarchat!

Od dzisiaj zarzucam też również pisanie zwrotów anglojęzycznych kursywą— mało wygodnie się to czyta, a większości terminów i tak używamy w języku polskim, kiedy mówimy o UX.

Kilka ostatnich miejsc na warsztaty w Gdańsku

Jeśli chcesz dowiedzieć się, jak dobrze planować procesy UX i nie pogubić się w doborze metodologii projektowej — te warsztaty są dla Ciebie. Przeznaczone dla początkujących i zaawansowanych projektantów, powinny nauczyć Cię paru nowych rzeczy… Odwiedź stronę internetową UX w praktyce by dowiedzieć się więcej. Zostało nam już tylko kilka miejsc.