Niedawno miałem okazję przekonać się jak ukształtowanie interfejsu użytkownika może wpływać na sposób w jaki aplikacja będzie odbierana przez użytkowników. W skrajnym przypadku może prowadzić do odrzucenia systemu.
Czekając w kolejce do bankomatu zauważyłem, że dwie osoby przede mną odchodzą nie pobierając gotówki. Gdyby to była tylko jedna osoba pomyślałbym, że chodzi o brak środków na koncie. Gdy druga osoba odebrała kartę obstawiałem problem z bankomatem. Postanowiłem sprawdzić co jest przyczyną problemów.
Na pierwszym ekranie widocznym po włożeniu karty pojawiło się pytanie:
Czy potrzebujesz gotówki?
Poniżej znajdowały się dwa przyciski: TAK i NIE. Pytanie wydało mi się dziwne jak na bankomat sieci Euronet.
Kiedy użytkownik wybierał "TAK" (przecież po gotówkę przyszedł do bankomatu) kierowany był na stronę ze szczegółami reklamy kredytów gotówkowych i "głupiał". Użytkownik oczekiwał przecież pojawienia się menu bankomatu, dostawał coś mylącego. Rezygnował więc z transakcji ("bankomat zepsuty") i odchodził.
Aby móc dokończyć transakcję należało wybrać "NIE" - dalej procedura przebiegała już standardowo.
Tak oto z mojego małego doświadczenia można wnioskować, że prosty błąd popełniony na etapie projektowania interfejsu użytkownika potrafi zniechęcić większość potencjalnych użytkowników systemu. Nie był to błąd działania systemu (nie poleciał żaden wyjątek, salda zachowały poprawną wartość), ale operacja do której bankomat był stworzony nie doszła do skutku.
Stało się tak, ponieważ przy integracji komponentów (nowa wersja reklamy w istniejącym UI bankomatu) nie sprawdzono jak całość zostanie odebrana przez klientów. Nie dokonano "testów integracyjnych na poziomie interfejsów białkowych". Z moich doświadczeń wynika, że styk człowiek-komputer jest trudniejszy do oprogramowania niż interfejsy pomiędzy komponentami oprogramowania.