Programiści nie potrafią budować użytecznych aplikacji

Programiści nie potrafią budować użytecznych aplikacji
Aby zbudować aplikację przyjazną użytkownikowi programista potrzebuje projektanta interfejsów i/lub specjalisty od użyteczności. W innym przypadku jego software będzie nieużywalny lub będzie traktował użytkownika jak małe dziecko we mgle.

Oczywiście powyższe stwierdzenia są ogólne i nie odnoszą się do wszystkich programistów. Na pewno jest tam przynajmniej jedna osoba, która potrafi nie tylko kodować, ale rozumie również reguły budowania interfejsów. 

Aby pokazać to na przykładzie, prezentujemy proces odnowienia podpisu kwalifikowanego w CenCert. Poczynając od maila przypominającego o wygasającym certyfikacie, przez proces zakupu i jego samodzielną aktualizację. 

https://www.cencert.pl/product-category/podpis-kwalifikowany/ 

Proces nie jest łatwy, ale programiści, którzy go zaimplementowali zrobili wiele, aby go dodatkowo utrudnić. Tworząc oprogramowanie dla ludzi spoza IT założyli, że komunikatem błędu i tekstową informacją mogą załatwić absolutnie wszystko.

Pokażemy to na zrzutach ekranu z naszym komentarzem*

*) czytającym ten tekst pracownikom CenCert przypominamy, że krytyka jest podstawą do poprawy, a prześmiewczego charakteru komentarzy moglibyście uniknąć, gdybyście poprosili kogoś znającego się na użyteczności o pomoc.  

Zaczynamy. 

Kiedy uczyłeś się informatyki w latach osiemdziesiątych i nie zauważyłeś, że co nieco zmieniło się w netykiecie. 

uzyteczne-aplikacje01.png

uzyteczne-aplikacje02.png

Kiedy masz sklep internetowy z czterema produktami, ale uznasz, że sortowanie też się przyda.

uzyteczne-aplikacje1.png

Kiedy wydaje Ci się, że masz skomplikowany produkt więc długi i skomplikowany opis wszystko użytkownikowi wyjaśni. 

uzyteczne-aplikacje2.png

Kiedy nie umiesz w wartości graniczne (to taki testerski klasyczny test).

uzyteczne-aplikacje3.png

Kiedy nie wiesz, jak obsłużyć IF-a w wysyłce mailowej i musisz go zaimplementować tekstowo. 

uzyteczne-aplikacje4.png

Kiedy informacja jest tak ważna, że musisz ją powtórzyć dwa razy w tym samym mailu. 

Pierwszy raz.

uzyteczne-aplikacje5.pngDrugi raz.

uzyteczne-aplikacje6.png

Kiedy twoja aplikacja bez pytania użytkownika, wrzuca mu na pulpit 3 różne skróty, w tym też te, które są mu niepotrzebne.

uzyteczne-aplikacje7.pngI dorzuci jeszcze kilka programów w gratisie do paska START. 

uzyteczne-aplikacje8.png

Kiedy musisz stworzyć komunikat o tym, że może pojawić się problem, ale chcesz pocieszyć użytkownika, że problemy to normalna sytuacja. uzyteczne-aplikacje9.png

 

Kiedy proces aktualizacji to seria niekończących się pop-upów.

Pierwszy.

uzyteczne-aplikacje10.png


Drugi.

uzyteczne-aplikacje11.png

Kolejny.

uzyteczne-aplikacje12.png

Ostatni.

uzyteczne-aplikacje13.png

I na finał - mail podsumowujący zakończenie operacji, w którym robisz tekstowego IF-a i IF-a z ELSE-m, bo nie wiesz w sumie co twój klient zrobił, ale musisz mu powtórzyć to, co mu już przekazałeś w każdym innym kanale wcześniej.

uzyteczne-aplikacje14.png

Na zakończenie, co jest niepodważalnym plusem - cały proces udało się zakończyć z sukcesem. Jednak cały proces odnowienia przez serię powtórzeń, nieprzydatnych i agresywnych komunikatów oraz rezygnacji z implementacji logiki, staje się dla użytkownika bardzo trudny. Mamy tu klasyczny przypadek firmy informatycznej, która zajmuje się sprzedażą usług dla osób niekoniecznie związanych z informatyką. Włożono sporo wysiłku w zaprojektowanie procesu i choć funkcjonalnie działa poprawnie to jednak pomylono użyteczność z tekstową instrukcją obsługi.

To powinno Cię zainteresować