Jest w sztuce UX szczególna kategoria błędów. Zdarzają się, gdy projektanci chcą by coś było „lepsze”, ale zapominają o skutkach i detalach. Takie błędy mają niską szkodliwośc i często przechodzą niezauważone. Potrafią jednak przeszkadzać i świadczą o jakości pracy.
Rzadko piszę o błędach i zwykle robię to, gdy w krótkim czasie zaatakuje mnie kilka przypadków, które mają wspólny mianownik. Tym razem inspiracją jest notka na Twitterze. Zanim ją przeczytałem myślałem, że jestem jedynym, który widzi wady luzackiego stosunku do dat.
Czy tylko ja uważam, że określanie wieku artykułu w serwisie blogowym/news jako „dawno temu” jest lekko…idiotyczne? Szczególnie z danymi
— Mateusz Śledzik (@MSledzik) May 8, 2015
Niejasne daty
Ktoś kiedyś zauważył, że zamiast pisac 10.34 lepiej podać informację „5 minut temu”. Taka forma jest bardziej naturalna i zrozumiała. O tym, co dopiero się stało, myslimy „przed chwilą”. W określonym kontekście to ma sens. Weźmy jednak taki scenariusz: oglądam swoje stare zdjęcia na Instagramie. Okazuje się, że byłem gdzieś 130 tygodni temu. Tylko kiedy to mogło być? Jaki miesiąc?
Niszą, jaką są użytkownicy zaglądający w historię, nikt się nie zajął. Precyzja i użyteczność zawartych tu informacji padły ofiarą. Coraz więcej jest tych niedokładności. W aplikacji muzycznej na smartfonie nie sprawdzicie już jaki bitrate mają wasze mptrójki itd. (wiedząc co to jest bitrate jesteśmy w niszy). Może nikt normalny (o ile istnieje użytkownik normalny) nie ogląda swoich starych zdjęć na Instagramie, ale wyobraźcie sobie, że projektanci innowacyjnego interfejsu w banku na liście przelewów umieszczają datę „bardzo dawno temu”. Coraz więcej jest „fajnych” interfejsów finansowych, gdzie obrazki zastępują przejrzystość, więc na pewno gdzieś to zrobią.
W swoim banku mogę użyć własnej ikony z burakiem do przelewów za telekomunikację, ale nie mogę ustawić jako „domyślny” rachunku, który jest dla mnie domyślny (pierwszy pokazuje się rachunek kredytowy). Bank, ten z większych, zapytany nabrał wody w usta wyjaśniając ” Sprawa została przekazana do merytorycznej komórki Banku celem weryfikacji”. Przy okazji poinformował, że zamiast numeru klienta, którego w pięć lat nauczyłem się już na pamięć, mogę zacząć używac „przyjaznego loginu”. Na szczęście nie pozbawi mnie możliwości używania numeru.
Agresywne ostrzeżenia
Czasem projektanci robią coś, bo mają za dużo czasu. Dzieje się tak w organizacjach, w których mają mocną pozycję, czas i warunki do działania. Na tyle dobre, żeby pracować nad lepszymi formularzami.
W takim formularzu podaję nr telefonu. Wpisuję tylko pierwszą cyfrę. Obok formularza pojawia się ostrzeżenie „Podany numer jest za krótki”. Na czerwono, co w jakiś sposób atakuje. Formularz zareagował za wcześnie. Ostrzeżenie będzie mnie pilnowało do wpisania ostatniej cyfry. Nie powinno być tak zrobione – nie powinno mówić użytkownikowi, że zrobił coś źle, zanim jeszcze to zrobił. Rozwiązaniem jest zmiana koloru, albo pokazanie komunikatu w momecie, gdy użytkownik opuści pole.
Takie rzeczy są po to, żeby zachwycić, poprawić komfort i wygodę. Powinno się je robić dobrze, albo wcale. Wcale oznacza tu zastosowanie prostych, sprawdzonych rozwiązań. Dobrze – przemyślenie całości i znalezienie czasu na doskonałą realizację. Formularz „wystarczająco dobry” spełniłby swoją funkcję. Ten niby lepszy, za to niedorobiony, nic nie daje biznesowi. Może czasem jakiś prezes bez pojęcia o temacie pokiwa głową mrucząc z zadowoleniem na wieśc o możliwości wyboru ikonek i kolorowych wykresach. Na robienie doskonale zwykle czasu brakuje (nawet jeśli się ma go na tyle dużo, żeby się bawić). To paradoks, ale dość powszechny.
Wszechobecne tutoriale
Kopalnią źle zrobionych detali jest dla mnie Deezer. To krzywdzące stwierdzenie może wynikać z tego, że dobrze znam tę aplikację. Zacząłem jej używać pewnie „153 tygodnie temu”. Mimo tego ostatnio postanowiła mnie siebie nauczyć i podpowiadała jak dodać album do ulubionych. Mam kilkadziesiąt albumów w ulubionych. To nie jest bardzo trudne sprawdzić, czy użytkownik korzysta z „promowanej” funkcji, czy radzi sobie z aplikacją, czy może jest „power userem”.
Na marginesie uważam, że „tutoriale” są złe. Jeśli musisz je pokazywać projektancie, to znaczy, że źle zrobiłeś swoje. Zwłaszcza gdy tłumaczysz jak używać podstawowej funkcji w usłudze. Interfejsy powinny tłumaczyć się same. Pokazywanie „tipów” ma sens w określonych sytuacjach. Np. gdy zależy nam na zwiększeniu korzystania z czegoś, co dużo da użytkownikom, a nie jest do końca naturalne. Na stronie ze zdjęciami np. gdy użytkownik kilka razy kliknie myszą w „następne” podpowiadamy mu „możesz użyć strzałek na klawiaturze”.
Istnieje jeszcze taka możliwość, że na obrazku wyżej padłem ofiarą testu. Coraz częściej tak się robi. Sprawdzamy o ile wzrośnie nam wykorzystanie funkcji, jeśli pokażemy użytkownikom takie coś. Ten samouczek przestał się pojawiac.
…
Wszyscy robimy takie błędy. Zdarzają się, gdy ktoś da projektantom wolną rękę i nie zadba o konsekwencje. Nie wyjdą we wskaźnikach mierzonych przy rozwoju produktu. Nie są też przesadnie szkodliwe. Często projektanci wiedzą o nich. Nie zaskoczymy ich mówiąc „macie tam takie bez sensu ostrzeżenia”. Zapewne mają to na liście do poprawy – niestety ma ona 30 pozycji a zawsze jest coś ważniejszego do zrobienia. Kiedyś zaczęli, nie skończyli i przepadło.