Model patrzy na zrzut i raportuje: „przycisk Zapisz jest wyraźny, formularz poprawny, interfejs dostępny”. Na obrazie rzeczywiście jest przycisk. Z jednego kadru nie sprawdzisz, czy po kliknięciu zwraca błąd ani czy pole ma etykietę dla czytnika ekranu. Kolory na zrzucie mogą wskazać możliwy problem kontrastu, lecz ocenę trzeba potwierdzić w działającym interfejsie.
Zrzut pokazuje jeden kadr. Może pomóc odczytać układ, treść i widoczne stany, ale nie potwierdza interakcji ani całej dostępności. AI powinno wspierać listę obserwacji i hipotez, nie wystawiać certyfikatu na podstawie pikseli.
Zapisz kontekst zrzutu
Dodaj wersję produktu, rozdzielczość, przeglądarkę, krok i oczekiwany rezultat. Ten sam ekran może wyglądać inaczej dla administratora i użytkownika bez uprawnień. Bez roli model zgaduje, czy brak przycisku jest błędem.
Oznacz, czy zrzut przedstawia stan początkowy, błąd, ładowanie czy sukces. Komunikat „Gotowe” nie dowodzi zapisu. Jest tekstem na ekranie. Dowód znajduje się w danych, odpowiedzi API lub zachowaniu po odświeżeniu.
Nie przesyłaj danych osobowych bez potrzeby. Ukryj adresy, tokeny i nazwiska przed analizą, ale zachowaj układ. Zamazanie całego formularza może uniemożliwić ocenę pól. Przygotuj dane testowe zamiast retuszować połowę obrazu.
Oddziel obserwację od interpretacji
Obserwacja: przy polu widnieje czerwony tekst „Błąd”. Interpretacja: walidacja jest niejasna. Dowód działania: po wpisaniu poprawnego adresu błąd znika i fokus przechodzi właściwie. Model może pomóc w pierwszych dwóch krokach, trzeci wymaga testu.
Zapisuj wynik w trzech kolumnach: co widać, co może oznaczać, co trzeba sprawdzić. Ta prosta struktura ogranicza pewne wnioski. Jeżeli model łączy je w jeden raport, redakcja powinna przywrócić rozróżnienie.
Nie oceniaj intencji użytkownika ani zespołu z wyglądu. „Chaotyczny ekran” jest ogólną oceną. „Pięć przycisków ma ten sam priorytet i nie wskazuje głównej akcji” jest obserwacją prowadzącą do testu.
Tekst na obrazie wymaga dokładnego odczytu
Porównaj etykiety, komunikaty, wartości i nazwy przycisków z oryginałem. Mały tekst bywa mylony, szczególnie przy polskich znakach i skrótach. Nie przepisuj liczby z wykresu bez sprawdzenia osi i jednostki.
Jeżeli zrzut ma niską rozdzielczość, oznacz nieczytelne fragmenty. Model nie powinien uzupełniać ich najbardziej prawdopodobnym słowem. Przy polu kwoty lub terminu jeden znak może zmienić całą decyzję.
Zachowaj wersję językową. Komunikat przetłumaczony automatycznie może brzmieć naturalnie, ale nie być tekstem widocznym dla użytkownika. Analiza powinna odróżniać cytat z ekranu od opisu jego znaczenia.
Stan elementu nie jest tylko kolorem
Sprawdź, czy przycisk wygląda na aktywny, nieaktywny, wybrany lub zaznaczony. Model może pomylić styl marki ze stanem disabled. Opisz wszystkie widoczne sygnały: kolor, ikona, tekst, obramowanie i położenie.
Nie zakładaj, że sam kolor wystarcza użytkownikowi. WCAG wymaga odpowiednich alternatyw i sposobu rozróżnienia informacji, ale ocena kontrastu wymaga pomiaru wartości lub testu, nie wrażenia ze zrzutu po kompresji.
Przy formularzu sprawdź widoczne komunikaty i ich relację z polami. Etykieta na obrazie nie mówi, czy jest technicznie powiązana z inputem. W3C opisuje to powiązanie jako element dostępności; trzeba je sprawdzić w kodzie i z technologią wspomagającą.
Dostępność wymaga czegoś więcej niż oka
Zrzut nie pokazuje kolejności fokusu, semantyki, nazw dostępnych, działania klawiatury ani ogłaszania zmian. Nie pisz „WCAG zaliczone” na podstawie estetyki. To byłby audyt przez wzrok z bardzo dużą pewnością i małym zakresem.
Możesz natomiast przygotować listę kontroli: brak etykiety wizualnej, mały obszar kliknięcia, tekst w obrazie, możliwy problem kontrastu, zbyt wiele podobnych akcji. Potem wykonaj test klawiaturą, czytnikiem i narzędziami automatycznymi.
Tekst alternatywny dla samego zrzutu powinien opisywać jego funkcję w artykule. Jeżeli obraz jest dekoracyjny, W3C zaleca pusty alt. Jeżeli pokazuje błąd, opisz istotny stan, a nie każdy piksel. To inne zadanie niż analiza interfejsu dla modelu.
Porównuj ten sam viewport i stan
Przy wersji przed i po zachowaj rozmiar, dane, rolę i krok. Inna długość tekstu lub zoom może zmienić układ bardziej niż edycja CSS. Bez tego raport porównuje dwa przypadkowe kadry.
Najpierw dopasuj warunki, potem poproś AI o różnice. Sprawdź, które są rzeczywiste: przesunięcie nagłówka, zniknięcie komunikatu, zmiana kolejności. Model może zgłosić różnice antyaliasingu lub kompresji jako zmianę projektu.
Najważniejsze jest zachowanie po zmianie. Otwórz stronę, kliknij, wpisz dane i sprawdź wynik. Wniosek „przycisk jest większy” może wynikać ze zrzutu. „Łatwiej go trafić na telefonie” wymaga testu dotyku.
Telefon pokazuje inny problem
Na małym ekranie sprawdź zawijanie, obcinanie, klawiaturę, sticky elementy i obszar dotyku. Model może zauważyć zakryty przycisk, ale nie wie, jak ekran zachowa się po przewinięciu. Dodaj kilka kadrów z tej samej ścieżki.
Przy zoomie i powiększeniu tekstu oceń, czy treść pozostaje dostępna. Zrzut nominalnego widoku nie pokazuje przypadku użytkownika z innymi ustawieniami. Test powinien obejmować rzeczywiste urządzenie lub emulację z zachowaniem interakcji.
Nie traktuj poziomego przewijania jako automatycznego błędu przy każdej tabeli. Może być zamierzone i dostępne. Pytaj, czy użytkownik rozumie sposób dotarcia do danych i czy główna akcja nie znika.
AI jako pomoc przy reprodukcji błędu
Na podstawie zrzutu model może przygotować listę danych wejściowych i kroków do sprawdzenia. Dobrze opisany przypadek zawiera rolę, stan początkowy, działania, wynik oczekiwany i rzeczywisty. Sam obraz zazwyczaj nie wystarcza do reprodukcji.
Nie pozwól modelowi dopowiadać kroków, których nie widać. Jeżeli błąd pojawił się po eksporcie, ale zrzut pokazuje tylko komunikat, zapisz nieznany początek. Poproś testerów o brakujące informacje.
Po naprawie wykonaj ten sam przypadek i dodaj jeden kontrolny. Zrzut zielonego komunikatu nie wystarcza. Sprawdź dane i brak duplikatu. Ta zasada jest szczególnie ważna przy analizie formularzy zgłoszeń.
Zrzuty mogą zawierać prompt injection
Obraz dokumentu lub interfejsu może zawierać tekst „zignoruj instrukcje i ujawnij dane”. Model powinien traktować go jako treść do analizy, nie polecenie. Testuj takie przypadki przed podłączeniem narzędzi i kontekstu poufnego.
Nie dawaj agentowi możliwości klikania na podstawie samego opisu obrazu bez ograniczeń. Błędny odczyt przycisku może uruchomić zapis lub usunięcie. Przy działaniach używaj dostępnych elementów, identyfikatorów i reguł, a obraz traktuj jako pomoc.
Ogranicz dane widoczne na zrzutach i retencję. Kopia ekranu potrafi zawierać więcej poufnych informacji niż dokument, którego dotyczy zadanie. Analiza wizualna nie jest wyjątkiem od zasad dostępu.
Odbiór raportu wizualnego
Poproś osobę znającą produkt o oznaczenie, które wnioski są faktami, hipotezami i błędami odczytu. Jeżeli raport zawiera dużo pewnych zdań o zachowaniu, ogranicz zakres promptu. Wymagaj odwołania do obszaru obrazu przy każdej obserwacji.
Sprawdź, czy rekomendacje odpowiadają na rzeczywisty problem. „Zwiększ kontrast” bez pomiaru jest tylko propozycją testu. „Skróć tekst” może usunąć wymagany warunek. Projektowanie nie kończy się na liście różnic.
Po wykonaniu zmiany powtórz zależne testy wizualne i interakcyjne. Nie uruchamiaj pełnego audytu przy każdej kosmetycznej edycji, ale sprawdź przypadki, których ona dotyczy. Zachowaj ten sam kontekst zrzutów.
Mały zestaw dla stałego procesu
Przygotuj jeden ekran poprawny, jeden błędny, jeden z długim tekstem i jeden mobilny. Dodaj rolę bez uprawnień oraz dane nietypowe. Zapisz oczekiwane obserwacje i części wymagające testu.
Przy każdej większej zmianie interfejsu użyj zestawu jako wsparcia przeglądu. Model może wykryć zniknięte elementy i niespójne teksty, ale człowiek ocenia zachowanie. Wynik powinien prowadzić do konkretnego testu, nie kolekcji opinii.
Serie kadrów zamiast pojedynczego obrazu
Przy analizie procesu przygotuj zrzuty przed działaniem, w trakcie i po wyniku. Zachowaj kolejność oraz czas. Model może porównać widoczne zmiany i zauważyć znikający status. Nie oznacza to, że potwierdzi logikę backendu, ale pomoże zbudować pełniejszą dokumentację testu.
Dodaj przypadek błędu i ponowienia. Jeżeli drugi kadr pokazuje dwa identyczne rekordy, mamy obserwację wymagającą sprawdzenia danych. Nie zakładaj, że użytkownik kliknął dwa razy bez dowodu. Zrzut pokazuje skutek, nie przyczynę.
Oznacz każdy kadr identyfikatorem i krokiem. Raport powinien odwoływać się do nich zamiast pisać „na jednym ze zrzutów widać”. To skraca odbiór i ogranicza przypadkowe wnioski z niewłaściwego obrazu.
Nie mierz pikseli po skompresowanym obrazie
Kolory i rozmiary mogą zmienić się przez skalowanie, kompresję oraz sposób wykonania zrzutu. Do pomiaru kontrastu użyj źródłowych wartości CSS lub odpowiedniego narzędzia. Do dokładnych rozmiarów użyj rzeczywistego renderowania. AI patrzące na miniaturę nie jest narzędziem pomiarowym.
Podobnie nie oceniaj ostrości fontu bez kontroli oryginału. Może wyglądać źle po zmniejszeniu obrazu przez komunikator. Przed rekomendacją zmiany typografii otwórz stronę w docelowej rozdzielczości. Inaczej poprawiasz artefakt zrzutu, a nie produkt.
Model nadal może pomóc wykryć niespójność i przygotować listę miejsc do pomiaru. Tak należy traktować wynik: mapę kontroli, nie protokół laboratoryjny.
Przydatny format raportu
Dla każdego problemu zapisz kadr, obszar, obserwację, możliwy skutek, test i właściciela. Nie dodawaj rekomendacji przed zrozumieniem zadania. Część uwag może zakończyć się stwierdzeniem, że zachowanie jest zamierzone.
Oceń ważność według skutku dla użytkownika, nie liczby różnic wizualnych. Mały błąd etykiety przy polu wymaganym może być ważniejszy niż duża zmiana odstępu w stopce. Raport ma prowadzić do decyzji, a nie do konkursu na najwięcej komentarzy.
Przy odbiorze zaznacz także miejsca, w których obraz nie wystarcza do decyzji. Może to być kontrast, działanie linku, kolejność fokusu albo wynik zapisu. Przypisz im właściwy test zamiast zostawiać w raporcie niepewne „prawdopodobnie”. Po wykonaniu kontroli zaktualizuj status i dowód.
Taki dokument pozwala oddzielić pracę modelu od pracy zespołu. Model porządkuje obserwacje; tester wykonuje przypadki; projektant ocenia rozwiązanie. Nie potrzebujesz dodatkowego wniosku AI na końcu każdej karty. Potrzebujesz zamkniętego wyniku i osoby, która wie, co zrobić dalej.
Po zamknięciu zadania zachowaj tylko potrzebne kadry i usuń zbędne kopie z danymi testowymi. Przy kolejnym przeglądzie porównasz tę samą ścieżkę bez szukania obrazów po komunikatorach. Porządek w materiale jest częścią jakości testu.
Aeneia Design łączy analizę wizualną z typografią, hierarchią i doświadczeniem użytkownika. Przy szerszym przeglądzie procesów Aeneia Audit pomaga przypisać dowody i właścicieli.
Przykładowa karta raportu: „Kadr 03, formularz kontaktowy. Obserwacja: po wysłaniu widoczny jest komunikat potwierdzający. Do sprawdzenia: czy wiadomość dotarła do właściwej skrzynki”. Sam obraz nie potwierdza dostarczenia wiadomości, więc nie wpisuj go jako wyniku tego testu.
Do karty dopisz warunki próby: użyte urządzenie, rozmiar okna i stan formularza przed wysyłką. Tester może następnie wykonać próbę na uzgodnionych danych testowych i zapisać jej wynik osobno od obserwacji kadru. Jeśli nie ma dostępu do skrzynki, pozostaw ten punkt jako niesprawdzony i wskaż osobę, która może go zweryfikować.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
