Apple słynie z dobrego UX, ale czasem i najlepszym zdarzają się takie kwiatki. Hint: to 1,5-liniowe „okienko” pod „Download PDF” zawiera kilkanaście stron tekstu.
Zapytany mówię, że moja praca składa się z:
To nie pomyłka – odkąd mam 2 duże monitory mogę zerkać na te pieprzone paski i w międzyczasie robić inne rzeczy (np. pisać ten wpis) – w ten sposón wyrabiam 150% normy
Przejdźmy więc przez moją życiową drogę pasji i pracy w IT i zobaczymy jak to było na przestrzeni lat.
Odbieram maila. Czytam: „Proszę wydrukować załączony protokół odbioru usługi, podpisać, zeskanować i odesłać mailem, dziękuję”. Jak robot robię CTRL+P, idę do drukarki, podpisuję, skanuję a niepotrzebny papier wrzucam do niszczarki.
Ile razy tygodniowo, miesięcznie, rocznie, robię w ten sposób? Myślę, że rocznie niszczę kilkadziesiąt świeżo wydrukowanych i podpisanych kartek. Ile mamy takich jak ja pracowników w Polsce, na świecie? Ile razem marnujemy papieru i prądu? Nie wspominając o zużyciu części w drukarkach i niszczarkach, tonerze, transporcie materiałów i urządzeń – wszystkiego co jest potrzebne abym mógł coś wydrukować i natychmiast potem zniszczyć?
Historia poniższa wydarzyła się naprawdę. Za siedmioma biurami, za siedmioma przegródkami żył sobie Prezes i utyskiwał, że w jego zamku nie funkcjonuje żaden eProcurement z prawdziwego zdarzenia. Szczególnie bolało go kulejące UX dla użytkowników końcowych, którzy w znoju klepali zapotrzebowania za pomocą pradawnego ERP’a. Dostęp do ERPa okupiony był zaś takimi opłatami, cłami i daninami, że opłacało się to tak samo jak gnój na pola wozić karetą królewską zaprzężoną w 16 arabów najczystszej krwi.
Projektując system bardzo rzadko zwraca się uwagę na komunikaty błędów. Nasza aplikacja przecież będzie zawsze działać poprawnie, czyż nie? Niestety testy (a czasem dopiero uruchomienie produkcyjne) rewiduje to życzeniowe podejście i okazuje się, że…
Podzielę się z Wami paroma pomysłami na lepsze komunikaty błędów w aplikacjach biznesowych.
Startując nowy projekt w firmie często stajemy przed wyborem:
a) kupmy gotowe narzędzie i dostosujmy nasze procesy do tego co ono oferuje; może będzie trzeba nagiąć nasze procedury ale system wystartuje błyskawicznie – dzięki temu znacznie szybciej zaczniemy korzystać z jego benefitów (znam kilka takich przypadków).
b) wynajmijmy programistów i zbudujmy aplikację szytą na miarę, zróbmy testy z użytkownikami, iterujmy kolejne coraz lepsze wersje; nasza firma ma już wypracowane procesy, wzorce i trzeba się idealnie w nie wpasować. Będzie drożej w implementacji ale po wdrożeniu systemu proces będzie szedł szybciej, wygodniej, taniej a użytkownicy będą zadowoleni (co na każdym etapie potwierdzimy badaniami UX – takich znam mniej ale jednak były).
Skoro z grubsza mamy takie dwie czarno-białe opcje (i jakąś gamę szarości pomiędzy nimi) to czemu idziemy zazwyczaj w…
kręcąc się przy laptopach usłyszałem co następuje Pani z działu laptopy: Jaki to moa być laptop? Klientka: no taki do internetu, filmów, gier Pani z działu laptopy: a jeśli do gier to musi być, wie pani, taki z lepszym, szybszym znaczy, procesorem no i musi mieć, tę, kartę graficzną osobną, tak zwaną Nvidia albo Dżifors, … Czytaj dalej
zabawne jak kolejne fale przedstawicieli różnych produktów odkrywają technologię cienkiego (webowego) klienta. Ja rozumiem, że jeśli przez 15 lat sprzedawaliśmy produkt oparty o grubego klienta, instalowanego na stacji u użytkownika, przejście na web może wywołać szok. Jednak opowiadanie potencjalnemu klientowi, że to jest nowość, rewolucja, przewaga konkurencyjna? Trąci sporym oderwaniem od rzeczywistości.
Użytkownik jest zestresowany, spać nie może
