Kropelka Usability - wiadra nie potrzebuję

Autor prowadzi blog - ProductLabs.co
Ostatnio we Wrocławiu odbyła się duża impreza dotycząca tematu webusability. Nie byłem, ale wysłałem pracownika. Obejrzał tam kilka prezentacji, wykładów, innych wydarzeń oraz wziął udział w warsztatach. Po powrocie zapytałem jak możemy wykorzystać zdobytą tam wiedzę u nas. Niestety nie udało się w żaden sposób. Według mnie tego typu konferencje same mają problem z użytecznością. Ten problem przejawia się w braku celu bezpośredniego jaki ma realizować. Usability ma na celu przywiązać klientów i zarabiać kasę.

Kiedyś byłem bardzo zajarany webusability. Czytałem, stosowałem (lub próbowałem) praktyki Jakoba Nielsena i innych guru. Problem był jednak w tym, że nie przekładałem tego w żaden sposób na wyniki biznesowe. Zabawa w teorie, siermiężne badania, diagramy UML i hasła "8 sekund" tylko wydłużały moją ścieżkę do robienia tych rzeczy, które powinienem. Mój dzisiejszy odbiór publikacji o usability jest taki, że urasta do metody samej w sobie, często bez kontekstu.

Usability czy po polsku użyteczność/ergonomia to po prostu właściwa komunikacja z klientem. I tyczy się to zarówno mebla z Ikea jak i strony e-commerce. Jeśli drażni mnie używanie czegoś czy korzystanie z jakiejś usługi to użyteczność jest słaba. Jeśli postawiono znak na drodze ale zasłania go drzewo to użyteczność jest zerowa. Jeśli chcemy zbadać czy nasza stronka jest użyteczna to nie badamy jedynie statycznego obrazka ale także kontekst jej użycia (user experience). A więc warto badać całe procesy np. rejestracji użytkownika czy idzie jak po maśle.

Czasami banki ze swoimi gwiazdkami na umowach celowo dają nam coś bardzo nieużytecznego. Zdarza się, że prowadzimy eksperyment aby dać ludziom coś czego nie nazywamy i badamy jak oni to nazwą i jak to użyją. Jednak najgorsze co może być to nieświadome eksperymentowanie i drażnienie użytkowników wymyślaniem koła na nowo.

W latach 2000-2005, pracowałem firmach tworzących strony znanych marek. Był wtedy szał na kolory, animacje flashowe, INTRO (o zgrozo) i wszelkiego typu bajery świadczące o rzekomej oryginalności. Potem zacząłem natrafiać na amerykańskie strony. Czcionka 12px lub większa, cały wygląd oparty na stylach, białe tło i czarne litery. Pomyślałem "ale brzydkie". Olśnienie przyszło trochę później.

Pomimo, że powyższe to banały to jeszcze wielu tego nie rozumie chcąc tworzyć "oryginały". Wtedy zawsze przytaczam przykład: Daewoo jest brzydkie i mało oryginalne, Aston Martin jest piękny. Natomiast oba samochody mają kierownicę na wysokości rąk (nie nóg), drążek biegów po środku (nie w tylnim fotelu), itd. Dlatego właśnie oba są mniej czy bardziej użyteczne. Kluczem jest tu zastosowana konwencja (wzorzec). Po prostu większość ludzi tak jak inżynier Mamoń lubi coś co już zna i wie jak tego używać. Robienie wyzwań w postaci toru przeszkód do użycia produktu to strzał w swoją głowę.

Jeśli chodzi o praktykę. Warto wydzielić w małym startupie czy organizacji role grafików, projektanta UX oraz kodera css, bo często się zlewają. Mogą to być oddzielne osoby albo te same ale mające świadomość, że każda z tych ról służy czemuś innemu. Często grafik rysuje coś w zaciszu i wysyła do akceptacji klientowi (strony internetowe). To najgorsza taktyka jeśli nie bierze pod uwagę zdania użytkowników o użyteczności już podczas projektowania. Kolejna dobra praktyka to robienie makiet (layout), wsadzenie potem zestawu makiet dla zobrazowania flow np. do invisionapp.com, potem testy typu fivesecondtest.com, potem dopiero dodanie tzw. look&feel czyli praca graficzna na makietach. Oczywiście możecie użyć kartki papieru. Ważne aby był feedback potwierdzający, że użytkownicy łykają konwencję i nie muszą się domyślać. Taki proces pozwala unikać marnowania czasu na projektowanie trzech pięknych wersji, potem mega cięcie w html5 i programowanie, a user po pół roku mówi "won mi z tym syfem co się nie da używać".

Chciałbym wspomnieć jeszcze o jednym zjawisku. Niektórzy często powtarzają "userzy to lamerzy". Zaczęło się od aparatów Kodaka dla małp, których użytkownicy Practica i innych Zenitów mieli w głębokim poważaniu. Potem panowie informatycy jeździli po pani Krysi, którą Windows 98 Me zaatakował z ekranu (wierzę w to). Takie podejście czasami jeszcze można spotkać, ale to dyskwalifikuje osobę jako biznesmena (i nie tylko). Jeśli użytkownicy lamerują to znaczy, że TO TY źle coś zrobiłeś.... To samo się tyczy startupowców, którzy na pytanie "ale ja tego nie widzę" (główna funkcjonalność) odpowiadają "no jak to, ale to jest w 10-tej zakładce na samym dole". Warto pamiętać, że przewaga konkurencyjna to często lepsza użyteczność. Więc jeśli na rynku są rozwiązania ale słabe być może warto atakować pomimo nawoływaczy - "ale to już było".

Oprócz doświadczenia dużo w temacie usability dała mi książka (w zasadzie uporządkowała wiedzę) S. Krug'a - "Nie każ mi myśleć!". W zasadzie po co ją czytać, tytuł mówi wszystko o właściwej użyteczności. Taka kropla ale konkretna. I jeszcze jedno, zanim zaczniecie się bawić w usability upewnijcie się, że macie produkt który rozwiązuje istniejący i konkretny problem ludzi. Później szlify usability. Najlepsza użyteczność nie pomoże jeśli produkt jest beznadziejny.

Zdjęcie goryla ze strony silverbackapp.com

Autor prowadzi blog - ProductLabs.co
Maciej Oleksy