Frustrujące wzorce projektowe, które wymagają naprawy: wybór urodzin

Widziałeś je wcześniej. Mylące i frustrujące wzorce projektowe, które wydają się ścigać Cię wszędzie, od jednej witryny do drugiej. Być może jest to wyłączony przycisk przesyłania, który nigdy nie informuje o tym, co naprawdę jest nie tak, lub podpowiedzi, które po otwarciu zakrywają pole wejściowe , gdy trzeba poprawić błąd. Są wszędzie i są denerwujące , często przerzucając nas z jednego ślepego zaułka w drugi, w coś, co wydaje się dobrze zaaranżowaną i kiepsko zaprojektowaną pułapką na myszy.

Te wzorce nie są złośliwe ani złe. Nie mają wiele wspólnego z oszukańczymi podpowiedziami o ciasteczkach lub tajemniczymi CAPTCHA w przebraniu hydrantów przeciwpożarowych i przejść dla pieszych. Nie zostały zaprojektowane z myślą o złych intencjach lub szkodzie: nikt nie budzi się rano z nadzieją zwiększenia współczynnika odrzuceń lub zmniejszenia konwersji.

Po prostu z biegiem lat niektóre mniej lub bardziej losowe decyzje projektowe stały się powszechnie akceptowane i przyjmowane, a zatem są powtarzane w kółko — często bez kwestionowania lub walidacji przez dane lub testy użyteczności. Stały się ugruntowanymi wzorcami projektowymi. I często dość biedni . Pojawianie się raz za razem wśród skarg użytkowników podczas testów.

W tej nowej serii artykułów przyjrzyjmy się bliżej niektórym z tych frustrujących wzorców projektowych i poznaj lepsze alternatywy , wraz z mnóstwem przykładów i pytań, o których warto pamiętać podczas tworzenia lub projektowania jednego z nich. Te spostrzeżenia pochodzą z badań użytkowników i testów użyteczności przeprowadzonych przez twoich prawdziwych i kolegów ze społeczności, i oczywiście wszystkie będą wymienione w każdym z nadchodzących postów.

Zaczniemy od skromnego i pozornie nieszkodliwego wzoru, którego wszyscy doświadczyliśmy w pewnym momencie — niesławnego selektora urodzin, który zbyt często okazuje się niedostępny, powolny i nieporęczny w użyciu. O idealnych selektorach daty i godziny pisaliśmy już bardzo szczegółowo, ale selektory urodzin zasługują na osobną rozmowę.

Frustrujące UX: menu urodzinowe/widżety od 2021 r.

Za każdym razem, gdy składasz podanie o pracę, otwierasz konto bankowe lub rezerwujesz lot, prawdopodobnie będziesz musiał wpisać swoją datę urodzenia . Oczywiście dane wejściowe to data , więc nie powinno dziwić, że interfejsy używają dobrze przyjętego widżetu podobnego do selektora dat (natywnego lub niestandardowego) lub listy rozwijanej z prośbą o podanie konkretnych danych wejściowych .

Prawdopodobnie możemy dostrzec powody, dla których te opcje są często preferowane. Z technicznego punktu widzenia chcemy mieć pewność, że dane wejściowe są poprawne i wcześnie wyłapywać błędy . Nasza walidacja musi być wystarczająco kuloodporna, aby zweryfikować dane wejściowe, zapewnić jasny komunikat o błędzie i wyjaśnić, co dokładnie klient musi zrobić, aby to naprawić. Po prostu nie mamy wszystkich tych problemów z menu rozwijanym lub widżetem kalendarza. Ponadto możemy łatwo zapobiec wszelkim różnicom w ustawieniach regionalnych lub formatowaniu, udostępniając tylko te opcje, które pasują do rachunku.

Mogłoby się wydawać, że najlepszym sposobem zapobiegania błędom jest zaprojektowanie interfejsu użytkownika w taki sposób, aby błędy były trudne do zrobienia. Może to oznaczać bycie ścisłym i jednoznacznym w projektowaniu formularzy — w zasadzie dopuszczanie tylko dobrze sformułowanych danych wejściowych. W końcu dostarczenie źle sformułowanych danych wejściowych jest niemożliwe, jeśli wszystkie dostępne opcje są dobrze sformułowane. Ale chociaż dane wejściowe rzeczywiście będą dobrze sformułowane, nie muszą być dokładne, zwłaszcza jeśli dostarczanie ich jest męczące i frustrujące.

W praktyce również popełniamy podobne błędy w przypadku zbyt skomplikowanych i rygorystycznych wymagań dotyczących haseł. Często zdarza się, że ludzie są tak zirytowani tymi wymaganiami, że umieszczają hasła na karteczkach samoprzylepnych na ekranie lub ukrywają je w pliku personal.txt na pulpicie, aby w razie potrzeby móc je ponownie wpisać. Hasła firmowe Wi-Fi i złożony SuperPIN dla bankowości internetowej są dobrymi przykładami tego w działaniu.

Okazuje się, że ludzie są bardzo kreatywni w naginaniu zasad na swoją korzyść, więc gdy system nie nadaje się do użytku, nie jest bezpieczny; a gdy dane wejściowe formularza nie nadają się do użytku, dane, które otrzymujemy, będą mniej dokładne i będą prowadzić do większej liczby błędów. Ostatecznie oczywiście doprowadziłoby to do sytuacji, w których użytkownicy są zablokowani i zmuszeni do porzucenia interfejsu użytkownika, ponieważ nie mogą poczynić żadnych postępów.

Ta moneta ma również drugą stronę. Moglibyśmy oczywiście wyeliminować wszelką złożoność i zawsze udostępniać jedno pole wejściowe, umożliwiając użytkownikom wpisywanie tego, co im się podoba. W praktyce oznacza to, że faktycznie będą pisać, co chcą, często w słabo ustrukturyzowany i nieefektywny sposób.

W przypadku danych wejściowych dotyczących urodzin, w testach użyteczności, klienci wpisują wszystko od lipca do lipca do 6-6 , często z przypadkowymi ogranicznikami i kilkoma literówkami po drodze oraz z mieszaną kolejnością dni, miesięcy i lat. Sprawdzanie poprawności danych wejściowych po przesłaniu nie służy użytkownikom dobrze, ponieważ nie wiedzą, jakie formatowanie danych wejściowych będzie działać. Oczywiście nie służy to również dobrze naszym potrzebom.

W naszym projekcie musimy zapewnić pełne szacunku, proste wskazówki oraz przystępną implementację techniczną. To prowadzi nas do kilku typowych wad natywnych selektorów dat i list rozwijanych.

Pułapki rodzimych selektorów i rozwijanych dat

Niestety, natywne selektory dat , podpowiadane przez <input type="date"> , niosą ze sobą wiele koszmarów związanych z ułatwieniami dostępu. W momencie pisania, gdy są używane od razu po wyjęciu z pudełka, nie są one bardzo dostępnym wyborem dla praktycznie każdego rodzaju wprowadzania danych. Istnieje nie tylko wiele problemów z czytnikiem ekranu, ale także problemy z ostrością i układem, mylące i ogólne komunikaty o błędach.

Widziałem wiele wdrożeń, które całkowicie wyłączają wprowadzanie danych z klawiatury (patrz wyżej), wymagając od klientów korzystania wyłącznie z widżetu kalendarza natywnego selektora dat . A to jest boleśnie, boleśnie powolne. Bez awaryjnego wprowadzania danych z klawiatury użytkownicy muszą wyruszyć w długą podróż między dniami, miesiącami i latami, wykonując dziesiątki stuknięć lub kliknięć .

Chociaż od razu znamy datę, interfejs zachęca nas do poruszania się między datami, a gdy już tam dotrzemy, znajdujemy naszą datę w przeglądzie miesięcznym. To jest powód, dla którego te doświadczenia są frustrujące.

W tym świetle listy rozwijane są znacznie szybsze i łatwiejsze w nawigacji. Są one domyślnie dostępne, a ponadto zamiast nawigować między miesiącami i latami, wystarczy zlokalizować właściwe liczby na 3 listach — dni, miesiące i lata. Ale rozwijane menu są nadal powolne. Mają problemy z powiększaniem. Ściskanie przewijanych opcji jest męczące. Zajmują dużo miejsca. Lista lat jest długa. A określając dane wejściowe, musimy dotknąć kontrolki, a następnie przewinąć (zwykle więcej niż raz), znaleźć i wybrać cel, a następnie przejść do następnego menu rozwijanego. To też nie jest ekscytujące.

Dlatego często zdarza się, że listy rozwijane są uważane za interfejs użytkownika ostatniej szansy i zwykle są zastępowane przyciskami (np. dla filtrów), przełącznikami, segmentowanymi kontrolkami lub polami autouzupełniania, które łączą elastyczność pola tekstowego z pewnością <select> - skrzynka. Listy rozwijane same w sobie nie są złe; po prostu użytkownicy spędzają o wiele więcej czasu niż to konieczne, wypełniając w nich dane.

A potem pojawia się pytanie o wartości domyślne . Podczas gdy w przypadku list rozwijanych często domyślnie nie wprowadzamy żadnych danych wejściowych ( mm/dd/yyyy ), w przypadku selektora daty musimy podać punkt początkowy widoku kalendarza. W tym drugim przypadku, jak na ironię, data „początkowa” zwykle wypada w okolicach daty wypełnienia formularza, np . 15 maja 2021 r . Nie wydaje się to oczywiście optymalne, ale jaka powinna być właściwa data? Musimy gdzieś zacząć, prawda?

Cóż, naprawdę nie ma odpowiedniej daty . Moglibyśmy zacząć wcześnie lub późno, 3 miesiące temu lub jutro, ale w przypadku wyboru urodzin wszystkie te opcje są czystym zgadywaniem. W związku z tym są one nieco frustrujące: bez żadnych danych wejściowych klienci mogą potrzebować przewijać od 1901 do późnych lat 80., a przy pewnym zestawie danych wejściowych będą musieli to poprawić, często przeskakując dziesiątki lat w przód iw tył. Ta interakcja będzie wymagała nienagannej precyzji przewijania.

Bez względu na to, jakiego wyboru dokonamy, prawie cały czas się mylimy . Prawdopodobnie będzie inaczej w przypadku witryny rezerwacji hoteli lub usługi dostarczania jedzenia i wielu innych przypadków użycia — tylko nie w przypadku urodzin. To prowadzi nas do rozmowy o tym, jak obiektywnie ocenić, jak dobrze zaprojektowane są dane wejściowe formularza.

Ocena jakości projektu formy

Design może być postrzegany jako bardzo subiektywna sprawa. W końcu wydaje się, że każdy ma swoje zdanie i preferencje co do właściwego podejścia do danego problemu. Ale w przeciwieństwie do jakiegokolwiek sposobu wyrażania siebie czy sztuki, projektowanie ma rozwiązywać problem. Pytanie brzmi zatem, jak dobrze dany projekt rozwiązuje konkretny problem. Im bardziej jednoznaczne oddanie intencji projektanta, im mniej błędów popełnianych przez klientów, im mniej im przerywa się, tym lepszy projekt. Te atrybuty są mierzalne i obiektywne .

Z własnego doświadczenia wynika, że ​​formularze są najtrudniejszym aspektem user experience. Jest tak wiele trudnych aspektów, od mikrokopii i układu formularza po walidację inline i komunikaty o błędach. Prawidłowe uzyskanie formularzy często wymaga odpowiedniego przedstawienia błędów zaplecza i błędów stron trzecich w interfejsie użytkownika oraz uproszczenia złożonej struktury bazowej w zestaw przewidywalnych i rozsądnych pól formularza. Może to łatwo stać się frustrującym koszmarem w przypadku złożonych starszych aplikacji i integracji innych firm.

Tak więc, jeśli chodzi o projektowanie form , w naszych projektach zawsze staramy się mierzyć jakość konkretnego rozwiązania na podstawie 9 atrybutów:

• Model mentalny
  Jak dobrze nasz projekt formy wpisuje się w model mentalny klienta? Pytając o dane osobowe, musimy zapytać dokładnie o minimum tego, co jest nam potrzebne, aby pomóc naszym klientom zacząć. Nie powinniśmy prosić o żadne wrażliwe lub osobiste dane (płeć, data urodzenia, numer telefonu), chyba że mamy ku temu dobry powód i wyjaśnimy to w interfejsie użytkownika.
• Złożoność
  Ile elementów wejściowych wyświetlamy na stronie, na urządzeniu mobilnym i na komputerze? Jeśli formularz zawiera 70–80 pól wejściowych, zamiast wyświetlać je wszystkie na jednej stronie lub używać układu wielokolumnowego, dobrym pomysłem może być użycie wzorca listy zadań, aby podzielić złożoność na mniejsze, łatwe do zarządzania fragmenty.
• Prędkość wprowadzania
  Ile czasu i wysiłku potrzebuje klient, aby poprawnie wypełnić dane? Dla danego wejścia, ile naciśnięć/naciśnięć klawiszy/operacji jest wymaganych, aby poprawnie wypełnić formularz podanymi danymi, zakładając, że po drodze nie popełniono żadnych błędów.
• Dostępność
  Mówiąc o szybkości wprowadzania danych, musimy upewnić się, że obsługujemy różne tryby interakcji, przede wszystkim użytkowników czytników ekranu i użytkowników klawiatury. Oznacza to m.in. odpowiednio ustawione etykiety, duże przyciski, etykiety umieszczone nad polem wejściowym, poprawnie komunikowane błędy.
• Skalowalność
  Gdybyśmy kiedykolwiek musieli przetłumaczyć interfejs użytkownika na inny język lub dostosować go do innego formatu, jak proste by to było i ile problemów mogłoby to spowodować? (Typowym przykładem problematycznego rozwiązania jest wzorzec etykiety pływającej, o którym powiemy w osobnym poście).
• Nasilenie przerw
  Jak często przeszkadzamy klientom, czy to z ładowaniem spinnerów, wczesną lub późną walidacją inline, zamrażaniem części interfejsu użytkownika w celu dostosowania interfejsu na podstawie dostarczonego interfejsu użytkownika (np. po wybraniu kraju), częstotliwości błędnie wypełnionych danych, lub błędnie automatycznie poprawione dane?
• Wskaźnik sukcesu formularza
  Ilu klientów z powodzeniem wypełniło formularz bez jednego błędu? Jeśli formularz jest dobrze zaprojektowany, zdecydowana większość klientów nie powinna w ogóle widzieć żadnych błędów. Na przykład wymaga to skorzystania z automatycznego wypełniania przeglądarki, kolejność kart jest logiczna, a wprowadzanie zmian jest konwencjonalne i oczywiste.
• Szybkość odzyskiwania
  Jak wysoki jest odsetek klientów, którym udało się wykryć błąd, naprawić go i przejść do kolejnego kroku formularza? Musimy śledzić, jak często pojawiają się komunikaty o błędach i jakie komunikaty o błędach są najczęstsze. Dlatego też często warto wpaść do działu obsługi klienta i najpierw sprawdzić, na co klienci często narzekają.
• Wskaźnik awaryjności formularzy
  Ilu klientów rezygnuje z formularza? Zwykle dzieje się tak nie tylko z powodu złożoności formularza, ale także dlatego, że klienci nie mogą znaleźć sposobu na naprawienie błędu z powodu agresywnych walidatorów lub wyłączonych przycisków „wyślij”. Dzieje się tak również dlatego, że formularz prosi o zbyt wiele poufnych i osobistych informacji bez uzasadnionego powodu.

Aby zrozumieć, jak dobrze działa formularz, przeprowadzamy badania użyteczności z klientami uzyskującymi dostęp do interfejsu na własnym komputerze — czy to na urządzeniu mobilnym, tablecie, laptopie czy komputerze stacjonarnym — we własnym systemie operacyjnym we własnej przeglądarce. Prosimy o nagrywanie ekranu, jeśli to możliwe, i używanie protokołu głośnego myślenia, aby śledzić, gdzie, jak i dlaczego zdarzają się błędy. Badamy również, jak szybko klient przechodzi z jednego pola formularza do drugiego, kiedy zatrzymuje się i myśli oraz kiedy zdarza się większość błędów.

Oczywiście sama liczba stuknięć lub kliknięć nie zawsze sugeruje, że dane wejściowe były proste lub kłopotliwe. Jednak niektóre tryby wprowadzania danych mogą z większym prawdopodobieństwem generować błędy lub powodować zamieszanie, a inne mogą być wartościami odstającymi , co wymaga o wiele więcej czasu w porównaniu z innymi opcjami. Tego właśnie szukamy w testach.

Zobaczmy teraz, jak możemy to zastosować do problemu z danymi urodzinowymi.

Projektowanie lepszych danych urodzinowych

Jeśli ktoś poprosi Cię o urodziny, prawdopodobnie będziesz miał na myśli konkretny ciąg cyfr. Może być uporządkowany w formacie dd/mm/yyyy lub mm/dd/yyyy , ale będzie to ciąg 8 cyfr, który powtarzasz we wszelkiego rodzaju dokumentach od najmłodszych lat.

Możemy wykorzystać ten prosty model danych wejściowych dotyczących urodzin za pomocą prostego pola z jednym wejściem, które łączy wszystkie trzy dane wejściowe — dzień, miesiąc i rok. Oznaczałoby to, że użytkownik po prostu wpisałby ciąg 8 cyfr, pozostając cały czas na klawiaturze.

Takie podejście rodzi jednak kilka problemów:

• musimy wspierać autoformatowanie i maskowanie,
• musimy wyjaśnić pozycję wejścia dzień/miesiąc,
• musimy wspierać zachowanie przycisku Backspace na wejściu,
• musimy śledzić i ukrywać/pokazywać/na stałe wyświetlać maskowanie,
• musimy wspierać skoki do określonej wartości (np. miesiąc),
• musimy zminimalizować wściekłe kliknięcia i nawigację w obrębie danych wejściowych, aby zmienić konkretną wartość na urządzeniach mobilnych,
• Jeśli automatyczne tworzenie nie jest używane, musimy wymyślić zestaw reguł czyszczenia i walidacji, aby obsługiwać wszelkiego rodzaju ograniczniki.

W swojej książce o wzorcach projektowania formularzy Adam Silver twierdzi, że używanie wielu danych wejściowych zamiast jednego rzadko jest dobrym pomysłem, ale jest to dobra opcja w przypadku dat . Możemy jasno komunikować, co reprezentuje każdy sygnał wejściowy, i możemy wyróżnić konkretne dane wejściowe za pomocą stylów fokusu. Ponadto walidacja jest znacznie łatwiejsza i możemy łatwo przekazać informację, która konkretna część danych wejściowych wydaje się nieprawidłowa i jak to naprawić.

Moglibyśmy albo automatycznie przenieść użytkownika z jednego wejścia do drugiego po zakończeniu wprowadzania, albo pozwolić użytkownikom na samodzielne poruszanie się między polami. Na pierwszy rzut oka to pierwsze wydaje się lepsze, ponieważ wejście wymagałoby tylko 8 cyfr, wpisanych jedna po drugiej. Jednak, gdy ludzie naprawiają błędy, często potrzebują buforów wejściowych — przestrzeni w polu wejściowym, aby poprawić istniejące dane wejściowe.

Na przykład często zdarza się, że ludzie wpisują 01, zdają sobie sprawę, że popełnili błąd, a następnie zmieniają dane wejściowe na 010, a następnie usuwają pierwsze 0, aby uzyskać odwrócony (i poprawny) ciąg — 10. Unikając automatyczne przejście z jednego pola do drugiego może sprawić mniej kłopotów i sprawić, że prosty interfejs użytkownika będzie nieco bardziej przewidywalny i łatwiejszy w obsłudze.

Aby wyjaśnić dane wejściowe, musielibyśmy podać etykiety dla dnia, miesiąca i roku, a być może również pokazać przykład prawidłowego wprowadzenia. Etykiety nie powinny być etykietami pływającymi, ale mogą wygodnie znajdować się nad polem wejściowym, wraz z wszelkimi wskazówkami lub przykładami, które chcielibyśmy wyświetlić. Co więcej, każde wejście może być również podświetlone na fokus.

Przez lata nie mogłem dostrzec ani jednego problemu z tym rozwiązaniem przez lata testowania i nie jest zaskakujące, że wzorzec jest również używany na Gov.uk.

Kiedy mimo wszystko potrzebujesz selektora dat

Chociaż powyższe rozwiązanie jest prawdopodobnie więcej niż wystarczające do wprowadzenia danych urodzinowych, może nie być wystarczająco dobre w bardziej ogólnych sytuacjach. Możemy potrzebować danych wejściowych mniej dosłownych niż dzień urodzenia, w którym klienci będą musieli wybrać dzień, zamiast go podawać (np. „ pierwsza sobota lipca” ). W tym przypadku moglibyśmy ulepszyć trzy pola wejściowe za pomocą widżetu kalendarza , z którego również mogliby korzystać użytkownicy. Domyślne dane wejściowe będą zależeć od bieżącej lub przyszłej daty, którą wybiera większość klientów.

Adam dostarcza prosty przykład kodu dla wzorca daty Pamiętna w swoim NoStyle Design System. Rozwiązuje wiele prac programistycznych i pozwala uniknąć wielu problemów z dostępnością, a wszystko to dzięki unikaniu stukania w widżety kalendarza lub niepotrzebnego przewijania kół rozwijanych.

Zawijanie

Oczywiście dobra kontrola formularza zależy od rodzaju danych wejściowych, których oczekujemy. W przypadku planistów podróży, w przypadku których oczekujemy, że klienci będą wybierać datę przyjazdu, przydatne może być elastyczne wprowadzanie danych z przeglądaniem kalendarza.

Kiedy jednak pytamy naszych klientów o datę urodzenia , prosimy o bardzo konkretną datę — bardzo konkretny ciąg, odnoszący się do dokładnego dnia, miesiąca i roku. W takim przypadku lista rozwijana jest zbędna. Nie jest to również wyszukiwanie kalendarza, które domyślnie przyjmuje mniej lub bardziej losową wartość. Jeśli go potrzebujesz, unikaj natywnych selektorów dat i natywnych list rozwijanych, jeśli to możliwe, i zamiast tego użyj dostępnego niestandardowego rozwiązania. I polegaj na trzech prostych polach wejściowych, z etykietami i objaśnieniami umieszczonymi nad polem wejściowym.

Opublikowaliśmy również obszerne dzieło na temat projektowania idealnego selektora daty i godziny, wraz z listami kontrolnymi, których możesz chcieć użyć do zaprojektowania lub zbudowania takiego narzędzia.

Powiązane artykuły

Jeśli uznasz ten artykuł za przydatny, oto przegląd podobnych artykułów, które publikowaliśmy na przestrzeni lat — a kilka kolejnych wkrótce się pojawi.

• Idealny responsywny konfigurator
• Doskonałe porównanie funkcji
• Idealny suwak
• Idealny akordeon
• Książka Wzorów Projektowania Form autorstwa Adama Silvera, opublikowana w SmashingMag
• Zapisz się do naszego biuletynu e-mail, aby nie przegapić następnych.