Dlaczego czas jest tak istotny dla UX?

Nasz zespół developerski od miesięcy zmagał się z łączniem dwóch bardo dużych systemów, ilość iteracji, zmian i kompromisów była ogromna. Niech o masie tego przedsięwzięcia świadczy fakt, że jeden system przetwarza dziennie jakieś 2.000 plików typu PDF a drugi około 5.000 (OCR). Trzeba było to sprytnie połączyć i wydawało się, że po miesiącach żmudnej pracy jest już dobrze.

Testy UX wyszły dobrze czyli źle

Każdy test UX przeprowadzony zgodnie ze sztuką (odpowiedni testerzy, narzędzia, scenariusze, próba badawcza, archiwizacja, wnioskowanie etc.) generuje rezultaty i odpowiedzi na wiele niezadanych wcześniej pytań. Ilość błędów, niespójności i problemów jaki się wylał zespół dev przyprawił o ból głowy. Niektórzy w kuluarach mówili, że gdyby spodziewali się takich wyników, żadnych testów UX by nie było. Każdy ma jakiś cel, dev ma za zadanie wykonać zalecenia, dodatkowe zmiany to dla nich dodatkowa robota co zrozumiałe. Jeżeli zespół programistów nie rozumie procesu UX, nie jest w niego włączony w jakimś marginalnym stopniu to ocenia go jako wroga, który tylko generuje zmiany oraz problemy.

Jak złe wyniki UX mogą być dobrymi wynikami?

Każda dodatkowa wiedza, świadomość co jest nie tak prowadzi nas do celu. Celem nadrzędnym w tym przypadku jest ilość rejestracji i wolumen przetwarzania dokumentów. Jeżeli system będzie działał źle cel nadrzędny nie zostanie osiągnięty, pomimo, że zespół developerów wykonał wszystko z największą starannością. Wyniki były miażdżące. Może się okazać pewnego dnia, że wszyscy stracą pracę, bo klientów ubędzie, trzeba mieć tego świadomość. Dlatego testy UX w tym przypadku pozwoliły uniknąć sromotnej klęski, która objawiała by się w masowym odpływie użytkowników do konkurencji. W skrócie, otrzymaliśmy masę krytycznych komentarzy od naszych klientów, to dobrze bo wiemy jak ulepszyć nasz system i nie stracić ich zaufania.

Tyle zmian od czego zacząć?

W zespole poświęciliśmy sporo czasu na odfiltrowanie niepotrzebnych zmian od ważnych. To co jest kluczowe w ewaluacji zmian jest częstotliwość wykorzystywania danego elementu/funkcji jego wpływ na proces klienta oraz pracochłonność. Spisaliśmy listę i wrzuciliśmy do Jira (taki program do zarządzania projektami) w celu ich egzekucji.

Efekt domina

Jednym z czynników, który wymagał natychmiastowej poprawy był czas. Mieliśmy problem z ładowaniem podstron, przetwarzaniem dokumentów. Nasza baza tak urosła, że pojawiły się wąskie gardła mocno spowalniające prace systemu. Czas był jednym z priorytetów. Po 2. tyg zaplanowaliśmy kolejne testy UX po wprowadzeniu pierwszej partii zmian. Testy przyniosły spore zaskoczenie. Okazało się, że 70% problemów  zniknęło, a jeszcze ich nie wyeliminowaliśmy. Użytkownicy przestali je zauważać. A wszystko to przez przyspieszenie czasu działania systemu. Z 3 sek, zeszliśmy do około 1 sekundy. Nieduża zmiana, mogło by się wydawać. Okazało się, że gdy system działa szybko, nasi użytkownicy są w stanie szybko nauczyć się nowej logiki. W przeciwieństwie do stanu, w którym każde kliknięcie powodowało 3 sekundową przerwę. Ludzie szybko się irytowali gdy trzeba było tak długo czekać i nie zamierzali wdrażać się w nową logikę. Czas pozwolił pośrednio wyeliminować większość problemów naszej integracji.

P.S. Warto sobie wyobrazić co by się stało gdybyśmy uznali czasy ładowania za zadowalające. Kosztowało by nas to ogromną ilość czasu oraz środków, może nawet porażkę całego projektu.