Użyteczna ewolucja

Tradycyjne kwestionariusze to rzecz zwyczajna i rutynowa, jednak często widać witryny, gdzie ten problem nie jest opanowany. Więc kilka podstawowych rad poniżej. Nie pisze tu o nowych sposobach budowania kwestionariuszy – w większości wypadków wystarczą stare. O nowych napisze w innym poście.
Kwestionariusze występują to tu, to tam na wielu stronach. Często, w miejscach kluczowych dla naszego biznesu – jak w procesie zakupu, zapisywania się czy budowania profilu.
Rzecz jest prosta, mało seksi i właściwie nie warto robić tego źle, gdyż z błahych niedoróbek wychodzi problem dla użytkowników i poważne konsekwencje ich utraty – dla nas.

Jeden krok na stronę

Warto podzielić proces na pojedyncze, zrozumiałe i powiązane z rzeczywistym światem etapy. Na przykład Dane kontaktowe – służące do kontaktu firmy z użytkownikiem. Dalej Adres dostawy – czyli dane ściśle związane z jedną, węzłową czynnością użytkownika. Kolejne – Dane płatności… etc. etc.

Wizard działa

Każdą czynność umieszczamy na jednej stronie wizarda. Użytkownicy nie mają problemu z chodzeniem do przodu i do tyłu w wizardzie – nawet, jeśli ma wiele stron.
Wypełnione już pola muszą być pamiętane w całym wizardzie  – użytkownikowi nie mogą znikać już wpisane dane, gdy przemieszcza się w wizardzie.

Okruszki

Ścieżka czynności czyli „okruszki” z bajki o Jasiu i Małgosi napisanej przez braci Grimm. Przydają się w wizardzie pod warunkiem, że są krótkie – maksymalnie 5 kroków i opisują całe logiczne bloki czynności. W innym przypadku straszą długością procesu i szczegółami wymagań.
Etapy okruszków nie muszą odpowiadać pojedynczym stronom wizarda. Wręcz przeciwnie – ważne jest zaznaczenie logicznych czynności a nie poszczególnych stron kwestionariusza.

Dominujący przycisk

Na stronie gdzie występują przyciski (szczególnie kwestionariuszowej, ale nie tylko) należy wyraźnie wyróżnić przycisk główny. Przycisk ten realizuje główną funkcję strony. Powinien być jeden. Powinien mieć na sobie fokus, tak by wciśnięcie Enter wciskało go.
Pozostałe przyciski powinny być znacznie gorzej widoczne. W praktyce zwykle projektuję przycisk kolorowy jako główny (niebieski szczególnie jest dobry bo się kojarzy z linkami), a pozostałe przyciski szare lub białe.

Długie i krótkie pola

Długość pól tekstowych i drop downów powinna być dostosowana do spodziewanych danych. Na przykład pole na adres e-mail powinno być długie, pole na kod pocztowy – krótkie, a pole na numer mieszkania – bardzo krótkie.
W wielu projektach kwestionariuszy widzimy pola o równej szerokości – zaprojektowane tak z lenistwa lub ze względów estetycznych. Użytkownik taką estetykę ma w nosie, a przy równych polach może pomylić się i wpisać dane w pole wyżej, lub niżej.

Opisy pól

Opisy pól powinny być jak najbliżej pola – chodzi o to, by użytkownik nie pomylił się i nie uznał, że inne pole przynależy do danego opisu. Dlatego najlepiej opis umieszczać bezpośrednio nad polem. Gdy umieszczamy jest z lewej strony – należy justować je do prawej – tak by przylegały do pola, a nie tkwiły daleko po lewej (szczególnie, gdy mamy długie i bardzo krótkie opisy.

Dodatkowe opisy

Bardzo często warto dodać dodatkowe opisy z wyjaśnieniem możliwych wątpliwości. Wtedy można umieszczać je pod lub po prawej stronie pola. Te napisy powinny być szare – o znacznie mniejszym kontraście niż główne opisy.

Błędy

W zasadzie nie powinienem używać tego określenia – użytkownik nie popełnia błędów. To my się z nim nie dogadujemy. No, czasami popełnia pomyłki .
Komunikat powinien zawierać tylko opis oczekiwanej akcji, nigdy wytykanie czy opisywanie błędu.
Źle: Błąd. Brak adresu e-mail.
Dobrze: Wpisz adres e-mail.
Czerwony komunikat powinien pojawić się pod polem do uzupełnienia. Pole powinno być podświetlone na żółto. Są to kolory alarmowe i zwracające uwagę.
Dodatkowo, na górze kwestionariusza powinien pojawić się komunikat ogólny – użytkownicy czasami nie rozumieją, dlaczego kwestionariusz przeładował się i nic się nie stało (nie zauważają pojedynczego podświetlonego pola).

Sprawdzanie formatu pól

Sprawdzanie zawartości pól sprawia najwięcej kłopotów użytkownikom. Zwykle dlatego, że sprawdzanie to jest zbędne, lub nieintuicyjne. Bardzo często wymagany jest specyficzny format danych, mimo, że użytkownicy mogą wpisywać je na różne sposoby. Opis formatu obok pola zwykle nie jest czytany, a jeśli, to często kłopot, a nie podpowiedź.
Na przykład:
Źle: 23-12-2010 – data musi być zapisana z kreseczkami.
Dobrze: 23-12-2010, 23.12.2010 – użytkownicy nie rozróżniają przerywników i gdy wyskoczy błąd „złej daty”, nie będą wiedzieli dlaczego jest zła – przecież wpisali właściwą. Pomysł, że data może być zła w sensie formatu, a nie merytoryki jest typowym błędem w projektowaniu kwestionariuszy. W przypadku daty lepiej dać wyskakujący kalendarzyk.
Inne przykłady tolerancji sprawdzania pól:
Kod pocztowy: 00-445, 00445;
Numer rachunku bankowego: 12 1234 2345 4567 6789 8976; 1212342345456767898976; 1212342-345456767898976; 1212342 345456767898976.

Sprawdzanie zawartości pól

Sprawdzanie ma zwykle na celu zmniejszenie liczby błędów lub też fałszywych zapisów w naszych bazach. To słaba motywacja – jak ktoś chce podać fałszywe dane lub śmiecie, tylko po to by sprawdzić nasz serwis, to poda fałszywe nawet jak będziemy sprawadzać zawartość.
Za to nękamy i odstraszamy tych co chcą spróbować. To potencjalni klienci. Jak im się spodoba, to zmienią albo założą prawdziwe konto.
Kiedy sprawdzać?
Gdy to ułatwia użytkownikowi wpisywanie danych poprawnych, których na pewno nie chce wpisać źle: numer konta bankowego, hasło (powtórzenie), adres e-mail (czasami powtórzenie).
Nie należy sprawdzać kodu pocztowego, liczby cyfr w telefonie i innych danych, które ktoś może mieć nietypowe (tracimy klienta).

Na przykład pole adresowe podzielone na oddzielne bloki „ulica”, „numer domu” i „mieszkanie” mogą sprawiać kłopoty, jak ktoś mieszka pod dziwnym adresem lub za granicą, gdzie inaczej opisuje się adresy. Zastanówmy, się czy rzeczywiście potrzebujemy takiego rozbicia danych.