Początek to konkretna praca do wykonania.
Tworzenie aplikacji zaczyna się od sytuacji w firmie, a nie od listy modnych funkcji. Klient dzwoni po status naprawy, recepcja przepisuje zapisy albo magazyn szuka informacji o zwrocie. Wybieramy jeden problem i określamy, jak ma wyglądać jego obsługa po uruchomieniu produktu.
Dobry opis zawiera uczestników, dane i rezultat. W warsztacie klient akceptuje zakres, pracownik wykonuje naprawę, a obsługa potwierdza gotowość auta. Już tutaj trzeba zdecydować, co dzieje się po zmianie kosztorysu. Sam ekran z sumą nie opisuje całej sprawy.
Na pierwszą rozmowę warto przynieść anonimowy przykład zlecenia i pokazać używany formularz. Materiały pozwalają zobaczyć wyjątki, których nie widać w krótkim haśle „potrzebujemy aplikacji”. Zobacz, jak przygotować taki opis.
Pierwsza wersja zamyka cały proces.
Zakres powinien wskazywać, kto rozpoczyna sprawę, kto ją obsługuje i w jakim momencie jest zakończona. Oddzielamy funkcje konieczne do tego przebiegu od dodatków. Dzięki temu można rozpocząć od mniejszego produktu, który wykonuje pełne zadanie, zamiast wielu ekranów bez połączenia.
Dla warsztatu pierwszym zakresem może być kosztorys, akceptacja klienta i etap naprawy. Magazyn części, wiele oddziałów i automatyczne rozliczenia mogą pojawić się później. Nie usuwamy jednak kontroli akceptacji tylko dlatego, że na liście startowej ma być jak najwięcej funkcji.
Ustalamy również warunki odbioru. Przykład: po dodaniu nowej pracy wcześniejsza akceptacja przestaje obowiązywać, a naprawy nie można rozpocząć przed ponownym potwierdzeniem. Taki zapis daje wspólny punkt odniesienia przy projektowaniu, programowaniu i testach.
Projekt pokazuje decyzje i stany.
Najpierw rozpisujemy drogę użytkownika, później układ informacji i wygląd ekranów. Sprawdzamy, czy klient rozumie zakres i koszt, a pracownik wie, co może zrobić dalej. Projekt obejmuje także pustą listę, błąd, oczekiwanie na odpowiedź i zakończenie działania.
Prototyp pozwala przejść przez wybrane zadanie przed przygotowaniem pełnego systemu. Nie jest jeszcze gotową aplikacją, ale pomaga wychwycić niejasne nazwy i zbędne kroki. Przegląd odbywa się na przykładzie pracy, nie wyłącznie przez ocenę kolorów i pojedynczych widoków.
Na tym etapie warto potwierdzić także teksty, materiały i zachowanie na telefonie. Właściciel firmy ocenia zgodność z praktyką, a przyszły użytkownik próbuje wykonać zadanie. Poradnik UX/UI wyjaśnia, jak przygotować taką ocenę.
Programowanie łączy interfejs z regułami.
Widoczny ekran jest częścią produktu. W aplikacji z kontami potrzebne są również zapis danych, uprawnienia i sprawdzenie działań po stronie serwera. Powiadomienie, płatność lub połączenie z magazynem wymaga osobnego przebiegu i obsługi błędu zewnętrznego systemu.
Realizację warto dzielić na fragmenty, które można ocenić od początku do wyniku. Zamiast odbierać samo logowanie, sprawdzamy na przykład utworzenie kosztorysu i jego akceptację. Kolejne fragmenty powinny korzystać z tych samych ustalonych danych oraz reguł.
AI może usprawniać część programowania i przygotowania testów. Nadal trzeba sprawdzić logikę, dostęp użytkownika i współpracę elementów. Szybkie wygenerowanie kodu nie potwierdza gotowości produktu. Opisujemy korzyści i granice wsparcia AI.
Testy sprawdzają także pomyłki.
Przed startem wykonujemy scenariusze z ustalonego zakresu, w tym poprawki danych, anulowanie i brak dostępu. W naszym przykładzie trzeba sprawdzić próbę rozpoczęcia naprawy bez akceptacji oraz zmianę kosztorysu po potwierdzeniu. Udany przebieg nie wystarcza do oceny całego procesu.
Osobno sprawdzamy wygodę na telefonie, obsługę klawiaturą, czytelność komunikatów i działanie integracji. Testy reguł nie zastępują próby w prawdziwej przeglądarce lub na urządzeniu. Klient powinien otrzymać jasną informację, jakie sprawdzenia wykonano i co pozostaje poza zakresem.
Odbiór odnosimy do uzgodnionych warunków. Nowy pomysł odkryty podczas testu może trafić do kolejnego etapu, natomiast błąd w zadeklarowanym działaniu wymaga poprawy. Rozróżnienie pomaga utrzymać przewidywalny zakres bez ignorowania potrzeb, które pojawiają się w praktyce.
Uruchomienie ma własną listę zadań.
Start obejmuje konfigurację środowiska, kont i danych potrzebnych użytkownikom. Ustalamy również, kto obsługuje zgłoszenia i jak wrócić do wcześniejszej wersji w razie problemu. Dla aplikacji mobilnej dochodzą materiały sklepu, testy urządzeń i procedura zgłoszenia do oceny.
Nie każda aplikacja musi od razu objąć całą firmę. Można zacząć od wybranej grupy lub jednej lokalizacji, zebrać uwagi i dopiero rozszerzyć użycie. Taki start nadal wymaga poprawnego zapisu, dostępu i obsługi spraw; nie jest sposobem pominięcia istotnych testów.
Po uruchomieniu oceniamy to, czy użytkownicy wykonują zadanie, a nie tylko liczbę wejść. W warsztacie można obserwować ręczne pytania o status lub czas potrzebny na akceptację. To cele do pomiaru, bez obietnicy określonego wzrostu. Zobacz podgląd takiego procesu.
Jaką decyzję podjąć dalej?
Przy planowaniu ekranów pomocny będzie artykuł Projektowanie UX/UI aplikacji — co powstaje?.
Aby sprawdzić rezultat z perspektywy pracownika firmy, zobacz Jak zorganizować odbiór przez osobę z firmy?.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Projektowanie UX/UI.