Specyfikacja projektu strony: stany interfejsu przed wdrożeniem

Na makiecie formularz zapytania wygląda na gotowy: pola, przycisk, estetyczny nagłówek. Jednak podczas wdrożenia okazuje się, że nikt nie uzgodnił komunikatów o błędach, oczekiwaniu na odpowiedź ani ponownym wysłaniu. Specyfikacja projektu strony jest potrzebna właśnie w takich sytuacjach: wyjaśnia, jak interfejs zachowuje się w różnych warunkach, a nie tylko jak wygląda w idealnym przypadku.

Przed rozpoczęciem programowania warto uzgodnić zestaw scenariuszy, stanów i zasad przechodzenia między nimi. Wtedy właściciel firmy rozumie zakres zamówionych prac, projektant przekazuje rozwiązania bez ukrytych założeń, a programista nie musi samodzielnie decydować o zachowaniu produktu. Poniżej przedstawiamy praktyczny sposób przygotowania takiego pakietu bez zbędnej dokumentacji.

1. Oddziel decyzje projektowe od atrakcyjnych ekranów

Przekazanie projektu do wdrożenia, czyli handoff, oznacza przekazanie uzgodnionych zasad działania interfejsu wraz z makietami. Ekran pokazuje konkretny moment. Specyfikacja dodaje warunki: co uruchamia działanie, jakie dane są potrzebne, co użytkownik widzi podczas oczekiwania i jak wraca do pracy po niepowodzeniu. Z perspektywy biznesu ważne jest, aby te decyzje nie zapadały przypadkowo podczas kodowania widoków.

Zacznij od rezultatu, który chce osiągnąć użytkownik: znalezienia usługi, porównania wariantów, wysłania zapytania. Dla każdej ścieżki wskaż warunek początkowy, kolejne działanie i oznakę zakończenia.

Ten dokument nie jest zapytaniem służącym wyborowi agencji. Jeśli nadal porównujesz wykonawców, osobno przyda się artykuł o RFI, RFP i RFQ przy wyborze wykonawcy. Tutaj chodzi o inną decyzję: jakie dokładnie informacje zespół powinien otrzymać przed realizacją już określonego projektu.

2. Zbuduj macierz stanów, a nie kolekcję kopii

Stany interfejsu opisują reakcję komponentu na daną sytuację. W przypadku pola są to pusta wartość, wprowadzanie danych, fokus i błąd; w przypadku listy — ładowanie, wynik, brak wyników i awaria. Nie każdy blok wymaga wszystkich wariantów. Wybieraj te, które rzeczywiście mogą wystąpić w uzgodnionym scenariuszu, i wyjaśniaj, dlaczego pozostałe nie mają zastosowania.

Oddziel wygląd od zachowania

Kolor przycisku po najechaniu kursorem nie wyjaśnia, czy można go nacisnąć podczas obsługi żądania. Podobnie narysowany wskaźnik oczekiwania nie określa momentu, w którym ma zniknąć. Obok wariantu wizualnego zapisz trzy rzeczy: zdarzenie wywołujące dany stan, dostępne działania i warunek wyjścia. Jeśli odpowiedź zależy od serwera, zaznacz tę zależność do omówienia z programistą.

Dla powtarzalnych elementów wystarczy jedno źródło zasad i odsyłacze z makiet. Osobny ekran jest potrzebny tam, gdzie zmienia się kompozycja lub ścieżka.

Nie łącz różnych przyczyn pustego stanu

„Nie masz jeszcze zapisanych produktów” i „Nie znaleziono wyników dla tych filtrów” wymagają różnych działań. W pierwszym przypadku właściwe jest przejście do katalogu, w drugim — zmiana warunków wyszukiwania. Niedostępnych danych nie należy przedstawiać jako zerowego wyniku: to inna przyczyna, inny tekst i być może inny sposób ponowienia żądania.

3. Opisz komunikaty, fokus i powrót do pracy

Nie zostawiaj treści komunikatów o błędach na koniec projektu. Specyfikacja powinna zawierać rzeczywiste sformułowania, miejsce wyświetlania i moment pojawienia się komunikatu. W polu adresu e-mail bardziej przydatne jest „Podaj adres w formacie [email protected]” niż „Nieprawidłowa wartość”. Format walidacji musi przy tym odpowiadać uzgodnionym regułom danych, a nie przypadkowemu ograniczeniu makiety.

W objaśnieniu kryterium WCAG 3.3.1 dotyczącego identyfikacji błędów W3C wskazuje, że automatycznie wykryty błąd wprowadzania danych należy opisać tekstowo i wskazać element, którego dotyczy. Czerwona ramka może uzupełniać wyjaśnienie, ale go nie zastępuje. To konkretne wymaganie dotyczące błędu, a nie potwierdzenie dostępności całej strony.

Osobno określ zachowanie fokusu klawiatury — bieżącego elementu, z którym użytkownik wchodzi w interakcję bez myszy. Dokąd przechodzi po otwarciu okna dialogowego, zamknięciu okna lub nieudanym wysłaniu? Na makiecie pokaż widoczne wyróżnienie, a w notatce opisz oczekiwaną ścieżkę. Ostateczne rozwiązanie sprawdza się już we wdrożonym interfejsie.

Komunikat „Zapisano” lub „Nic nie znaleziono” może pojawić się bez przejścia na inną stronę. WCAG 4.1.3 dotyczące komunikatów o stanie wyjaśnia, jak takie zmiany powinny być programowo dostępne dla technologii asystujących bez konieczności przenoszenia fokusu. Nie wymagaj takiego samego powiadomienia dla każdej zmiany: sposób ogłoszenia zależy od kontekstu i znaczenia zdarzenia.

Na etapie projektowania wystarczy wskazać, jaki komunikat ma otrzymać użytkownik i czy należy przerwać jego pracę. Programista ustala sposób technicznej realizacji, a tester sprawdza rezultat. Szerszy kontekst przedstawia artykuł GL.ua o projektowaniu z myślą o dostępności; specyfikacja stanów obejmuje tylko część tego zadania.

4. Przejdź przez hipotetyczny przykład zapytania o wycenę

Przykład hipotetyczny: firma przyjmuje przez stronę zapytania o wycenę mebli. Odwiedzający wybiera rodzaj produktu, zostawia dane kontaktowe i dodaje komentarz. Celem biznesowym jest otrzymanie zgłoszenia, na które można odpowiedzieć. To scenariusz edukacyjny, a nie opis klienta czy rezultatu GL.ua.

Od kliknięcia do potwierdzenia

Przed wysłaniem formularz pokazuje pola wymagane i podpowiedzi. Jeśli pole kontaktu jest puste, po próbie wysłania pojawia się obok niego konkretne wyjaśnienie. Komentarz pozostaje na miejscu. W zaleceniach WAI dotyczących powiadomień w formularzach przedstawiono podejścia do zbiorczej listy błędów i wyjaśnień przy polach. Specyfikacja określa kombinację potrzebną dla tego formularza, zamiast kopiować wszystkie warianty naraz.

Jeśli lokalne kontrole zakończą się pomyślnie, przycisk przechodzi w stan „Wysyłanie”. W tym hipotetycznym rozwiązaniu ponowne kliknięcie jest niedostępne do zakończenia bieżącego żądania. Trzeba osobno uzgodnić, czy podczas oczekiwania można zmieniać pola i które wprowadzone wartości zostaną zachowane po nieudanej próbie. Sam wygląd przycisku nie określa tych zasad.

Jeśli serwer potwierdził utworzenie zgłoszenia, pokazujemy „Zapytanie wysłane” i uzgodniony kolejny krok. Jeśli połączenie zostało przerwane, a wynik jest nieznany, nie piszemy „Zgłoszenie nie zostało utworzone”: interfejs tego nie wie. Potrzebny jest osobny tekst o braku potwierdzenia oraz uzgodniony sposób ustalenia wyniku. Mechanizm ponawiania zespół określa wspólnie z warstwą serwerową, a nie wyłącznie w projekcie interfejsu.

5. Sprawdź treść i responsywność przed kodowaniem widoków

Makieta z krótkimi nagłówkami nie pokazuje, co stanie się z długą nazwą usługi lub wielowierszowym błędem. Dodaj przykłady treści o realistycznej strukturze: długie imię i nazwisko, brakujące zdjęcie, kilka komunikatów w formularzu. Dla każdego złożonego bloku uzgodnij zawijanie, skracanie i sposób odczytania ukrytej treści w całości.

Opisuj responsywność jako zasady zmiany układu, a nie tylko parę „komputer — telefon”. Wskaż, które elementy zmieniają kolejność, co pozostaje widoczne i jak zachowują się tabele oraz długie listy. Dokładne progi szerokości zespół dobiera do treści i komponentów. Osobno sprawdzaj rozmiary pośrednie: dwa uzgodnione ekrany nie opisują wszystkich sytuacji między nimi.

W przypadku wielojęzycznej strony sprawdź teksty o różnej długości. Wskaż źródło fontów, dostępne odmiany i zasady dotyczące ikon. Wyeksportowane materiały muszą odpowiadać tym użytym w makiecie.

6. Uzgodnij pakiet i przejdź przez numerowaną listę kontrolną

Kryteria gotowości projektu powinny opierać się na możliwości zrealizowania scenariusza, a nie na liczbie narysowanych stron. Minimalny pakiet zawiera mapę ścieżek, bibliotekę powtarzalnych komponentów, macierz stanów, teksty, reguły responsywności i listę otwartych pytań. Każde pytanie wymaga osoby odpowiedzialnej i decyzji: wyjaśnić przed startem lub jawnie odłożyć poza bieżący zakres.

Przed rozpoczęciem wdrożenia przeprowadź poniższą kontrolę prototypu. Przed uruchomieniem strony powtórz te same scenariusze we wdrożeniu: klikalna makieta nie dowodzi, że komunikaty, przejścia i obsługa danych działają poprawnie.

1. Przejdź główną ścieżkę od warunku początkowego do potwierdzonego wyniku.
2. Dla każdego działania sprawdź oczekiwanie, sukces i niepowodzenie. Znajdź stany bez wyjścia.
3. Wstaw długie i brakujące wartości oraz sprawdź kilka błędów w formularzu jednocześnie.
4. Przejdź ścieżkę na wąskim ekranie i przy szerokości pośredniej. Na gotowej stronie dodatkowo sprawdź obsługę klawiaturą i ogłaszanie ważnych komunikatów.
5. Porównaj makiety, teksty i bibliotekę komponentów. Usuń sprzeczności i ustal jedną wersję do wdrożenia.
6. Zapisz nierozwiązane zależności i uzgodnij, które blokują start. Przed publicznym uruchomieniem sprawdź ich rozwiązanie w działającym scenariuszu.

Do odbioru gotowego produktu użyj osobnego planu. Artykuł o odbiorze strony firmowej dotyczy kolejnego etapu. Przekazanie projektu określa oczekiwania, a odbiór sprawdza stan faktyczny; te procedury są powiązane, ale nie zastępują się wzajemnie.

7. Oceń terminy, koszty i ryzyko nadmiernej szczegółowości

Czas przygotowania zależy od liczby różnych scenariuszy, gotowości treści, złożoności komponentów i tempa uzgodnień. Najpierw ustal reguły biznesowe, następnie opracuj główną ścieżkę i wyjątki, a potem uzgodnij responsywność oraz pakiet przekazania. Praca równoległa jest możliwa, ale nie należy finalizować komunikatów o wyniku, dopóki sam wynik nie został określony.

W kosztach wyodrębnij analizę scenariuszy, prototypowanie, opracowanie wizualne, komponenty, teksty stanów, warianty responsywne i weryfikację z programistą. Osobno ustal koszty fontów, ilustracji lub narzędzi do współpracy, jeśli są potrzebne. Aktualizowanie specyfikacji przy zmianach również wymaga czasu. Bez tego niższa wycena może oznaczać jedynie mniejszy zakres przekazania.

Największe ryzyka to sprzeczne wersje, nieuzgodnione odpowiedzi serwera i wymagania pojawiające się po rozpoczęciu prac. Zapisuj datę i wersję pakietu, a zmiany opisuj przez ich wpływ na scenariusze, makiety i kontrole.

Nie trzeba rysować ekranu dla każdej teoretycznej kombinacji. Stronie informacyjnej bez formularzy mogą wystarczyć zwięzłe zasady dotyczące komponentów i responsywności. Szczegółowo opracuj miejsca, w których użytkownik wprowadza dane lub może utracić postęp.

Uzgodniony pakiet projektowy uwidacznia zmiany przed programowaniem. Przekaż GL.ua (Glyanets) listę głównych scenariuszy i istniejące makiety, aby omówić stworzenie strony i uzgodnić zakres przygotowania projektu do wdrożenia.