Projektowanie logowania i rejestracji w aplikacji mobilnej: przejrzysty etap zakładania konta

Wybierz moment, gdy konto staje się przydatne

Zacznij od zadania, dla którego użytkownik przyszedł. Jeśli podstawowe funkcje działają bez konta, pozwól najpierw poznawać produkt i poproś o logowanie przy funkcji wymagającej zapisanych preferencji, dostępu na różnych urządzeniach, współpracy lub transakcji. Wytyczne Apple dotyczące interfejsu zalecają opóźnianie logowania, gdy to możliwe, i wyjaśnianie korzyści, gdy konto jest wymagane.

Prośba pokazana we właściwym kontekście jest łatwiejsza do zrozumienia niż blokada przy uruchomieniu. Na przykład aplikacja czytelnicza może pozwolić przeglądać tytuły, a poprosić o konto dopiero przy synchronizacji listy lektur. Jeśli konto jest niezbędne od początku, wyjaśnij dlaczego przed pokazaniem pól. Wyjaśnienie powinno być konkretne i proporcjonalne: „Utwórz konto, aby zapisywać projekty i otwierać je na innym urządzeniu” pomaga bardziej niż „Dołącz do naszej społeczności”.

• Oddziel wymagane dane od opcjonalnych szczegółów profilu.
• Przy zakupie bez rejestracji lub jednorazowym zadaniu rozważ, czy konto może poczekać do dostarczenia bezpośredniej korzyści.
• Po udanym uwierzytelnieniu wróć z użytkownikiem do działania, które zamierzał wykonać.

Przedstaw jasne i rozpoznawalne metody logowania

Użytkownik powinien rozpoznać, czy tworzy konto, czy wraca do istniejącego. Nazwij obie drogi odmiennie, wyraźnie wyróżnij główne działanie i umieść inne metody tak, aby dało się je porównać bez przytłoczenia ekranu. Używaj nazw dostawców i przycisków zgodnych z zasadami platformy; ogólne „Kontynuuj” samo nie wyjaśnia, co stanie się dalej.

Oferuj tylko metody, które produkt obsługuje i może utrzymywać. E-mail, klucz dostępu lub opcja tożsamości platformy mogą pasować do różnych odbiorców. Pokazuj je jako możliwości, a nie dowód, że jedna metoda jest zawsze najłatwiejsza lub najbezpieczniejsza. Wyjaśnij dodatkowe wymagane informacje.

Powracający użytkownicy mogą nie pamiętać swojej metody logowania. Ułatw znalezienie odzyskiwania dostępu i innych metod oraz wyjaśnij, co zrobić, jeśli e-mail jest powiązany z inną metodą. Wskazówki dotyczące łączenia kont pomagają zachować dostęp do istniejącego konta.

Twórz zwięzłe formularze zgodne z narzędziami użytkowników

Proś tylko o pola potrzebne do utworzenia konta lub uzyskania dostępu. Stosuj trwałe etykiety zamiast polegać wyłącznie na tekście zastępczym, dobierz odpowiedni typ pola i klawiatury oraz jasno pokaż następny krok. Jeśli rejestracja wymaga kilku informacji, grupuj powiązane pola i odłóż opcjonalne preferencje do chwili wejścia w produkt.

Uwierzytelnianie powinno działać z automatycznym wypełnianiem i menedżerami haseł. Używaj standardowych nazw i semantyki pól; unikaj własnych rozwiązań blokujących wypełnianie danych logowania. Nie blokuj wklejania hasła: użytkownicy mogą korzystać z menedżera haseł lub innego narzędzia. Wytyczne WCAG wskazują na potrzebę umożliwienia przeglądarkom i zewnętrznym menedżerom haseł wypełniania pól logowania.

Zachowanie może się różnić między urządzeniami i menedżerami haseł, więc sprawdź ścieżkę na obsługiwanych platformach i umożliwiaj ręczną korektę. Po nieudanej próbie, jeśli to praktyczne, zachowaj przydatne dane niewrażliwe, takie jak adres e-mail.

• Użyj widocznej etykiety, na przykład „Adres e-mail”, oraz jasnej etykiety hasła.
• Pozwól użytkownikom pokazać lub sprawdzić hasło, gdy to odpowiednie, nie czyniąc tej kontrolki jedynym sposobem poprawy wpisu.
• Umieść główny przycisk blisko pól i nadaj mu nazwę konkretnego działania, na przykład „Utwórz konto” lub „Zaloguj się”.

Projektuj z myślą o pomyłkach, odzyskiwaniu dostępu i kolejnej wizycie

Pomocny błąd wskazuje dane pole lub nieudany etap tekstem i mówi, jak kontynuować. „Coś poszło nie tak” nie wystarcza, gdy adres e-mail ma zły format lub pole jest puste. Kryterium sukcesu 3.3.1 WCAG 2.2 wymaga, aby wykryte błędy wprowadzania danych były wskazane i opisane tekstem; kolor lub ikona nie mogą być jedynym nośnikiem informacji.

Używaj neutralnego języka i umieszczaj wskazówki dotyczące pola blisko niego. Przykładowy komunikat dla błędnego adresu mógłby brzmieć: „Wpisz adres e-mail w formacie [email protected]”. Przy nieudanym logowaniu produkt mógłby powiedzieć: „Nie udało się zalogować tymi danymi. Sprawdź adres e-mail i hasło albo zresetuj hasło”. Nie ujawniaj wrażliwych informacji o koncie w komunikatach; dobierz słowa do potrzeb produktu w zakresie prywatności i ochrony przed nadużyciami.

Wyjaśnij, co dzieje się po prośbie o resetowanie, zapewnij drogę powrotu do logowania i pomóż odnaleźć wcześniej używaną metodę. Przy kolejnych wizytach jasno pokazuj stan zalogowania oraz drogę do ustawień konta, wylogowania i pomocy. Jeśli konto można utworzyć w aplikacji, zadbaj, by łatwo było znaleźć sposób jego usunięcia.

• Powiąż błąd z opisanym polem i zadbaj, by był widoczny bez polegania wyłącznie na kolorze.
• Umieść odzyskiwanie dostępu blisko formularza logowania i nie każ niepotrzebnie zaczynać od nowa.
• Sprawdź stany pierwszego użycia i powrotu, w tym zmienione adresy e-mail i niedostępne metody logowania.

Praktyczny przegląd ścieżki konta

Przejdź ścieżkę jako nowa osoba, powracający użytkownik i ktoś odzyskujący dostęp. Oceniaj ekrany w kontekście. Biblioteka wzorców mobilnych może pomóc zespołom porównać organizację pól, etykiet i działań w formularzach.

• Czy użytkownicy mogą osiągnąć przydatną wartość produktu przed logowaniem, gdy konto nie jest konieczne?
• Czy ekran wyjaśnia, dlaczego konto jest potrzebne i jakie informacje są wymagane?
• Czy użytkownik potrafi rozróżnić rejestrację, logowanie, inne metody i odzyskiwanie konta?
• Czy etykiety pól pozostają widoczne oraz czy dane logowania można wypełnić automatycznie i wkleić?
• Czy błędy nazywają problem tekstem, zachowują przydatne dane i sugerują następny krok?
• Czy po sukcesie użytkownik wraca do rozpoczętego zadania?