Aby zdiagnozować nieczytelny interfejs aplikacji, należy obserwować jej ekrany, elementy sterujące i reakcje, gdy ktoś próbuje wykonać obsługiwane przez nią zadanie. Trzeba wychwycić pierwszy moment, w którym kolejna czynność staje się niejasna. Następnie należy porównać oczekiwania tej osoby z rzeczywistym działaniem i komunikatami aplikacji. Nieudany zapis lub brakująca funkcja wymagają innej naprawy niż niejasna etykieta lub ścieżka.
Wyobraźmy sobie osobę, która próbuje zmienić istniejącą rezerwację. Otwiera kilka menu, wraca do ekranu głównego i prosi współpracownika o pomoc. Taka sekwencja jest punktem wyjścia obserwacji. Sama nie wyjaśnia, czy osoba później odinstaluje aplikację ani który ekran wymaga przeprojektowania.
Dlaczego ludzie tracą kolejny krok?
Ludzie mogą rozumieć cel, a mimo to przeoczyć niejasną czynność lub reakcję. Szukamy pierwszej widocznej rozbieżności między zadaniem, które zamierzają wykonać, a napotkanym ekranem. Nie należy przesądzać wyjaśnienia przed sprawdzeniem operacji. To, co wygląda na problem z nawigacją, może być również nieudaną prośbą lub rezultatem, którego produkt nie obsługuje.
Treść sugeruje inną czynność. Po naciśnięciu Kontynuuj osoba może oczekiwać kolejnego ekranu podsumowania, podczas gdy aplikacja od razu wysyła prośbę. Wytyczne Apple dotyczące przycisków zalecają jasne określanie ich celu. Przed wyborem nowej etykiety należy porównać oczekiwanie z rzeczywistym skutkiem.
Rezultat pozostaje niepewny. Ktoś naciska ponownie, ponieważ nie potrafi stwierdzić, czy aplikacja przyjęła prośbę. Należy sprawdzić, co faktycznie zapisano i co zakomunikował ekran. Brak potwierdzenia i nieudana operacja wymagają różnych napraw.
Wskazówki dotyczące danych pojawiają się po błędzie. Należy sprawdzić, czy pole wyjaśnia, jakiej wartości wymaga.
W przypadku treści internetowych kryterium W3C dotyczące etykiet lub instrukcji wymaga ich podania, gdy treść wymaga wprowadzenia danych. To odniesienie należy stosować do ekranów internetowych w aplikacji. Aplikacje natywne wymagają oddzielnej oceny według wytycznych danej platformy.
Ścieżka traci kontekst. Ktoś wraca z ekranu szczegółów i nie potrafi odnaleźć elementu, który zmieniał. Należy zapisać punkt początkowy, wybraną czynność oraz ekran wynikowy. Pierwsze niejasne przejście trzeba opisać na tyle precyzyjnie, aby można je było odtworzyć.
Jak zdiagnozować nieczytelny interfejs aplikacji?
Należy zacząć od obsługiwanego rezultatu i porównywalnego stanu początkowego. W przypadku czynności, które powodują wysłanie, obciążenie opłatą, usunięcie lub wpływają na inną osobę, należy korzystać z konta testowego i bezpiecznych danych testowych. Cel trzeba zapisać bez wymieniania menu ani elementu sterującego, który do niego prowadzi. Chodzi o ustalenie, co osoba potrafi znaleźć i zrozumieć, zanim otrzyma wyjaśnienie.
- Należy zdefiniować ukończenie. Czy przy zmianie rezerwacji zamierzonym rezultatem jest wysłana prośba, czy potwierdzona nowa rezerwacja? Trzeba sprawdzić, który rezultat jest obsługiwany w tej wersji i na tym koncie.
- Należy zapisać stan początkowy. Trzeba zanotować wersję aplikacji, urządzenie, język, uprawnienia oraz to, czy rezerwacja już istnieje. Konto administratora może udostępniać inną ścieżkę niż konto klienta.
- Należy obserwować bez nazywania elementu sterującego. Trzeba poprosić osobę o próbę osiągnięcia celu. Należy zapisać wybrany ekran, przeczytaną etykietę i oczekiwania. Jeśli udzielono pomocy, trzeba ją odnotować; późniejsze ukończenie jej nie wymazuje.
- Należy oddzielnie sprawdzić rezultat. Widoczną reakcję trzeba porównać z zapisaną rezerwacją. Należy otworzyć ją ponownie na koncie testowym albo sprawdzić testowy rekord usługodawcy. Naciśnięcie lub ekran wyglądający na potwierdzenie sukcesu nie dowodzą, że zamierzona aktualizacja nastąpiła.
Jeśli sprawdzają Państwo aplikację samodzielnie, należy zapisać to, co daje się odtworzyć, i wyraźnie wskazać to ograniczenie. Znajomość produktu zmienia sposób wykonania zadania. Późniejsza obserwacja osoby, która go nie zna, dostarcza innych dowodów.
Przeanalizujmy to fikcyjne zadanie rezerwacji
Rozważmy wymyśloną aplikację do rezerwowania zajęć, w której można poprosić o inną sesję. Usługodawca musi zaakceptować tę prośbę, zanim rezerwacja się zmieni. Poniższe notatki ilustrują sposób badania nieporozumienia. W tym przykładzie nie używaliśmy działającej aplikacji ani konta, nie uczestniczyła w nim żadna osoba i nie testowaliśmy proponowanego tekstu.
| Obserwacja | Notatka |
|---|---|
| Zamierzone zadanie | Przeniesienie istniejącej rezerwacji zajęć na inną sesję. |
| Czynność i dokładna etykieta | Osoba naciska Zmień rezerwację; przycisk wysyła prośbę. |
| Oczekiwany rezultat | Osoba uważa, że nowa sesja jest już zarezerwowana. |
| Stan rzeczywisty | Pierwotna rezerwacja pozostaje, a prośba czeka na akceptację. |
| Proponowana kontrola | Wypróbowanie Poproś o zmianę oraz komunikatu o wysłaniu prośby. |
Zaobserwowana rozbieżność dotyczy znaczenia czynności. Inna etykieta jest hipotezą, którą trzeba sprawdzić w odniesieniu do faktycznej operacji. Jeśli prośba w ogóle nie dociera do usługodawcy, należy także zbadać nieudaną operację. Jeśli natychmiastowe potwierdzenie jest niezbędne dla produktu, stanowi to oddzielną decyzję produktową, której nie może zapewnić etykieta przycisku.
Obserwację należy zapisać przed jej interpretacją. “Osoba otworzyła rezerwację, nacisnęła Zmień rezerwację i oczekiwała potwierdzenia” opisuje zachowanie w tym fikcyjnym ćwiczeniu. “Interfejs jest zły” pomija pytanie, na które nadal trzeba odpowiedzieć.
Jak wprowadzić najmniejszą zmianę odpowiadającą obserwacji?
Należy wybrać naprawę, która odnosi się do zapisanej rozbieżności i zachowuje zamierzoną operację. Jeśli niepewność dotyczy treści, instrukcji lub informacji zwrotnej, należy zacząć od tych elementów. Zmiana struktury nawigacji lub szersze przeprojektowanie wymagają uzasadnienia opartego na zadaniu. Problemy funkcjonalne powinny pozostać widoczne, aby jaśniejsze wyjaśnienie nie ukryło operacji, która nadal kończy się niepowodzeniem.
-
Należy wypróbować ukierunkowany projekt. Dla fikcyjnej rezerwacji trzeba pokazać proponowaną etykietę czynności i stan wynikowy w klikalnym projekcie. Nasze audyty UX i prototypy aplikacji wykorzystują taką sekwencję od zadania do prototypu. Należy porównać oczekiwanie osoby przed naciśnięciem ze stanem rozpoznanym później; proponowanej etykiety nie wolno opisywać jako potwierdzonego ulepszenia.
-
Należy sprawdzić ścieżkę błędu. Kryterium W3C dotyczące identyfikacji błędów w treści internetowej wymaga, aby automatycznie wykryty błąd danych wskazywał element, którego dotyczy, i opisywał błąd tekstem. Sama kolorowa ramka nie zapewnia takiego wyjaśnienia. Natywne elementy sterujące i pełna ocena dostępności wymagają oddzielnych kontroli właściwych dla platformy.
-
Należy sprawdzić reakcję na ekranie i za pomocą technologii asystujących. W przypadku treści internetowych kryterium W3C dotyczące komunikatów o stanie obejmuje udostępnienie określonych zmian stanu technologiom asystującym bez przenoszenia fokusu z bieżącego elementu sterującego. Trzeba sprawdzić, co pojawia się na ekranie i co mogą wykryć narzędzia asystujące. Czytnik ekranu to na przykład oprogramowanie, które może odczytywać na głos treść interfejsu. To wybrane kryterium nie certyfikuje aplikacji, nie wyznacza docelowego czasu reakcji ani nie naprawia powolnej operacji.
-
Należy prześledzić przejście do internetu. Gdy ścieżka tego samego konta lub tej samej rezerwacji prowadzi na stronę internetową, należy uwzględnić to przejście w teście. Tworzenie stron i aplikacji internetowych powinno zachowywać treść zadania i rzeczywisty stan po obu stronach tej granicy.
Co należy sprawdzić po zmianie?
Należy ponownie wykonać to samo zamierzone zadanie z porównywalnego stanu i zapisać przebieg. Obok rezultatu trzeba zachować informacje o wersji aplikacji, urządzeniu, języku i udzielonej pomocy. Przydatne porównanie dotyczy obserwowanego zadania: tego, czy osoba znalazła czynność, zrozumiała jej skutek i rozpoznała rzeczywisty rezultat. Szersze wnioski biznesowe należy pozostawić otwarte do czasu uzyskania odpowiednich dowodów.
Należy razem zapisywać ukończenie i pomoc, pierwszy błędny krok, błędy danych, których osoba nie potrafiła zinterpretować, oraz to, czy pomyliła prośbę z potwierdzeniem. Odpowiednie kontrole trzeba powtórzyć w sprawdzanej wersji językowej i konfiguracji dostępności. Należy ocenić dłuższe etykiety i informacje dostępne w tej konfiguracji, zamiast zakładać, że ekran angielski reprezentuje każdą wersję.
Jeśli rejestrują już Państwo czynności w aplikacji, takie jak rozpoczęcie prośby o zmianę rezerwacji lub jej dotarcie do usługodawcy, należy sprawdzić, czy rekordy odpowiadają tym rzeczywistym stanom. Zmiany w pytaniach do pomocy technicznej należy zestawiać z tą samą ścieżką. Brak pobrań aplikacji jest oddzielnym problemem pozyskiwania użytkowników; nasz poradnik dotyczący aplikacji bez pobrań zaczyna się przed otwarciem produktu przez użytkownika.
Pomyślne powtórzenie może opisywać tę obserwację. Nie pozwala ustalić, dlaczego ludzie odinstalowują aplikację, ani przypisać naprawie zmiany retencji. Kolejne nierozstrzygnięte pytanie należy zapisać wraz z osobą odpowiedzialną za jego sprawdzenie.
Jak możemy pomóc
Zaczynamy od obsługiwanego zadania, pierwszego niejasnego przejścia oraz dowodów potrzebnych do wyboru naprawy. Możemy przekształcić to w prototyp, sprawdzić wdrożoną ścieżkę i uwzględnić jej internetowy odpowiednik. Opis zadania i miejsca, w którym się zatrzymało, mogą Państwo przynieść na rozmowę o projekcie. Z każdego udostępnianego przykładu należy usunąć nazwiska klientów i inne dane osobowe.
