UX i UI dotyczą tego samego produktu.
UX opisuje drogę do wykonania zadania: potrzebne informacje, kolejność decyzji i zachowanie po pomyłce. UI nadaje tej drodze widoczny kształt: układ, typografię, pola i przyciski. Ładny ekran nie zastąpi brakującej reguły, a poprawna reguła musi być zrozumiała dla użytkownika.
W aplikacji wynajmu sprzętu klient potrzebuje dat, ilości i dostępności. Musi też odróżnić opłatę za najem od kaucji. Projektowanie zaczyna się od tej informacji, nie od telefonu na efektownym tle. Wygląd powinien wspierać wybór, a firma znać skutki potwierdzenia.
Właściciel ocenia zgodność z ofertą, natomiast przyszły użytkownik sprawdza, czy potrafi wykonać zadanie. To dwa potrzebne spojrzenia. Dobrze przygotowany projekt nie wymaga od klienta znajomości nazw technologii ani języka projektanta.
Rozpisujemy poprawny przebieg i wyjątki.
Dla wynajmu droga może wyglądać tak: termin, rodzaj urządzenia, ilość, podsumowanie i potwierdzenie. Do niej dochodzą brak dostępności, nieprawidłowa data oraz rezygnacja. Każdy z tych stanów wymaga komunikatu i działania, a nie tylko ogólnego napisu „wystąpił błąd”.
Oddzielamy role. Klient chce wybrać sprzęt, magazyn potwierdzić wydanie, a administrator zmienić stawkę. Nie wszystkie informacje muszą pojawić się w każdym widoku. Wcześniejsze ustalenie odpowiedzialności ogranicza zbędne pola i pomaga przygotować uprawnienia.
Warto używać przykładów z codziennej pracy: ostatni egzemplarz, zwrot później niż planowano albo zmiana ilości. Takie sytuacje pokazują, czy ścieżka jest kompletna. Podgląd wypożyczalni pozwala sprawdzić część tych reguł.
Makieta porządkuje treść przed wyglądem.
Makieta pokazuje hierarchię informacji i miejsce decyzji. Powinna odpowiedzieć, co użytkownik widzi jako pierwsze, czego potrzebuje do wyboru i jaki rezultat otrzyma. Na tym etapie łatwiej zmienić liczbę kroków niż po połączeniu wszystkich ekranów z pełnym systemem.
Używamy realnych rodzajów danych i odpowiednio długich opisów. Krótka nazwa produktu nie ujawni problemu z długą nazwą, a pusta tabela nie pokaże, czy da się ją odczytać na telefonie. Dane przykładowe powinny przypominać wymagania produktu bez udawania rzeczywistych klientów.
Materiałem do odbioru może być mapa ekranów, makiety i opis działania. Sama kolekcja obrazków bez powiązań nie wyjaśnia, co stanie się po przycisku ani jak użytkownik wróci do poprawy wcześniejszych danych.
Prototyp służy próbie wykonania zadania.
W prototypie można sprawdzić kolejność, nazwy i zrozumiałość podsumowania przed pełnym programowaniem. Zadanie powinno brzmieć jak potrzeba użytkownika, na przykład „potrzebujesz dwóch urządzeń na trzy dni”. Nie podpowiadamy od razu nazwy przycisku, który chcemy przetestować.
Obserwujemy, gdzie osoba się zatrzymuje, czego szuka i jak interpretuje wynik. Pytanie „czy podoba Ci się ekran” nie daje tej samej informacji. Nielsen Norman Group opisuje takie podejście w scenariuszach testów użyteczności.
Prototyp może mieć ograniczoną liczbę stanów i nie zapisuje prawdziwych rezerwacji. Trzeba jasno opisać, co można nim sprawdzić. Spostrzeżenia pomagają poprawić projekt, ale nie zastępują testów gotowej aplikacji z danymi, integracjami i uprawnieniami.
Wygląd obejmuje także komunikaty i telefon.
Po uporządkowaniu przebiegu dobieramy typografię, kontrast, odstępy i sposób zaznaczania stanów. Projekt obejmuje przyciski aktywne i niedostępne, dłuższe teksty, brak wyników oraz informację o zakończeniu. Spójność dotyczy zachowania, nie wyłącznie powtarzania koloru.
Na telefonie potrzebne są czytelne pola i układ, w którym decyzja nie ginie poza ekranem. Obsługa klawiaturą i dostępność informacji o błędzie również należą do projektu. Nie zakładamy, że późniejszy etap automatycznie naprawi niewygodną strukturę.
W3C zaleca ocenę dostępności podczas tworzenia produktu, a nie wyłącznie na końcu. Materiały WAI o ocenie podkreślają także granice narzędzi automatycznych. Ten zakres potwierdzamy odpowiednimi sprawdzeniami, bez deklaracji zgodności na podstawie samego wyglądu.
Projekt ma być podstawą wykonania i odbioru.
Przed programowaniem ustalamy, które ekrany, stany i teksty są uzgodnione. Ważne reguły pozostają opisane obok projektu: kiedy odjąć dostępność, kiedy wymagana jest akceptacja i kto może poprawić dane. Dzięki temu wykonawca nie musi zgadywać znaczenia interfejsu.
Właściciel firmy powinien otrzymać czytelny zakres do oceny, z miejscem na pytania i korekty. Nowe pomysły można dopisać do planu rozwoju. Nie należy jednak traktować każdej uwagi do niejasnego działania jako nowej funkcji; najpierw sprawdzamy uzgodniony cel.
Projekt jest gotowy do kolejnego etapu, gdy znamy drogę użytkownika, informacje i istotne stany. Opis procesu tworzenia pokazuje, jak łączymy to z wykonaniem i testami, a nie traktujemy jako odrębne dekorowanie ekranów.
Jaką decyzję podjąć dalej?
Przy pracy przerwanej przed przesłaniem zobacz Powrót do niedokończonego formularza: co użytkownik powinien odzyskać?.
Dla rozdzielenia szkicu, przekazania i akceptacji przeczytaj Wersja robocza i zatwierdzenie: kiedy sprawa staje się wiążąca?.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Projektowanie UX/UI.