Obietnica decyzji — dla kogo i co tu znajdziesz
Ten artykuł pozwoli Ci w 30–90 minut sprawdzić interfejs przed publikacją i podjąć decyzję: publikować teraz czy poprawić krytyczne rzeczy. Jeśli robisz landing, MVP albo update produktu bez dedykowanego QA — ten tekst jest dla Ciebie. Jeśli masz pełne testy automatyczne i zespół QA — potraktuj go jako szybką listę sanity-check.
4 pytania, na które odpowiesz po 15 minutach
Czy kluczowe flow działa bez błędów? Tak → publikuje; Nie → blokuj.
Czy użytkownicy z problemami widzą i obsłużą UI (dostępność AA)? Tak → okej; Nie → priorytet. ([a11yproject.com)
Czy teksty i stany błędów jasno tłumaczą, co użytkownik ma zrobić? Tak → zielone światło; Nie → popraw content.
Czy layout nie łamie się na kluczowych rozdzielczościach i przy wolnym łączu? Tak → fine; Nie → popraw responsywność/obrazki.
Czym jest audit UI (krótko)
Audit UI to szybki, manualny przegląd interfejsu skoncentrowany na największym ryzyku: pomyłkach użytkownika, błędach widocznych w krytycznych flow, brakach dostępności i niespójnościach wizualnych. W praktyce to lista pytań, które zadajesz jako ostatnie QA przed "go live". Narzędzia i wzorce pomocne przy audicie to m.in. checklisty WCAG, zestawy UX-checklist (np. [UXPin]) oraz uniwersalne narzędzia do kontrastu i testów manualnych. ([webaim.org)
Jak zacząć — prosta ścieżka 5–30 min
Otwórz najważniejszy flow (rejestracja/checkout) — to Twoje krytyczne ścieżki.
Sprawdź 5 punktów: formularze, walidacje, stan błędu, fokus klawiatury, komunikat sukcesu.
Odpal narzędzia: Lighthouse/Wave/kontrast checker (1–2 min).
Zanotuj 3 krytyczne błędy, które blokują publikację — reszta może iść jako backlog.
Przykład praktyczny: jeśli formularz nie wskazuje pola z błędem (brak aria-invalid lub label), to w praktyce część użytkowników nie dowie się co poprawić — traktuj to jako blocker. ([webaim.org)
Kategorie priorytetów (krótkie wyjaśnienie)
Krytyczne (blokujące): broken flow, brak informacji o płatności, brak focusa na błędzie.
Ważne (wysoki priorytet): niewystarczający kontrast, brak alt na kluczowych grafikach.
Kosmetyczne: drobne różnice w spacingu, nieidealne microcopy.
25 rzeczy do sprawdzenia przed publikacją
Poniżej 25 konkretnych punktów — jedno zdanie na punkt, abyś mógł/a odhaczyć szybko.
Formularze: pola mają label i powiązanie z input (id/for).
Walidacja: błędy są jasne i wskazują co poprawić.
Focus: tryb klawiatury przechodzi przez wszystkie kontrolki (tab order).
Czy stany przycisków (disabled, loading) są widoczne i oznaczone semantycznie.
Linki: otwieranie w nowej karcie oznaczone (jeśli wymagane).
Kontrast tekstu: minimum 4.5:1 dla tekstu funkcjonalnego. ([primer.style)
Obrazy: kluczowe grafiki mają opisowe alt.
Responsywność: krytyczne layouty na mobile, tablet, desktop.
Teksty: brak placeholderów zamiast etykiet (placeholder nie zastępuje label).
Microcopy: komunikaty CTA są jednoznaczne (np. "Kup teraz" vs "Kontynuuj").
Ładowanie: największy element wizualny (LCP) jest zoptymalizowany.
Błędy serwera: proste i przyjazne komunikaty, bez leakowania stack trace.
Linki dead: brak 404 w istotnych miejscach (footer, CTA).
Analytics: kluczowe cele/zdarzenia wysyłają się poprawnie.
SEO meta: tytuły i opisy unikają duplikatów.
Cookie banner: działa i nie blokuje sensownych elementów akcji.
Modal windows: zamknięcie ESC i fokus wraca do elementu źródłowego.
Animacje: nie wywołują mdłości, opcjonalnie reduce-motion.
Lokalizacja: jeśli jest i18n, teksty się mieszczą i tłumaczenia są kompletne.
Accessibility landmarks: role, aria labels, nagłówki logicznie zorganizowane. ([webaim.org)
Forms autosave / recovery: tam gdzie ważne (długi formularz).
Test przy wolnym łączu: obrazy placeholder, fallbacky.
Performance budget: krytyczne skrypty asynchroniczne.
Backup copy / rollback plan: wersjonowanie deployu (procedura awaryjna).
Cross-browser sanity: kluczowe zachowania w Chrome, Safari, Firefox (mobilne/desktopowe).
Tabela szybkich decyzji (kto powinien użyć auditu)
| Segment | Kiedy to stosować | Mini-werdykt |
|---|---|---|
| Startup / MVP | publikujesz szybko, brak dedykowanego QA | Użyj: krytyczne 1–10 |
| Marketing landing | cele konwersji, kampanie płatne | Użyj: 1–6, 10, 14, 15 |
| Duży produkt z QA | pełne testy automatyczne | Użyj: sanity-check, priorytetyzacja |
Fakt → Skutek → Werdykt
Fakt: brak kontrastu wpływa na osoby słabowidzące. Skutek: spadek dostępności i część użytkowników nie dokończy flow. Werdykt: jeśli zależy Ci na zgodności AA — popraw kontrast przed publikacją. ([primer.style)
Fakt: brak opisów w formularzu (label/aria) powoduje błędy dla screen readerów. Skutek: realne utrudnienie rejestracji. Werdykt: traktuj to jako blocker dla kluczowych formularzy. ([webaim.org)
Plusy i typowe skargi po wdrożeniach
Plusy auditu: szybko wykrywasz błędy, oszczędzasz kosztów poprawy po publikacji, poprawiasz konwersję i satysfakcję. Typowe skargi zespołów: "brak priorytetu" (zbyt dużo drobnych uwag), "niekompletne kryteria" (kto ocenia co jest krytyczne). Synteza: audyt działa, jeśli ustalisz regułę triage (blokery vs backlog).
Co jeśli czegoś nie wiesz — jak to szybko zweryfikować
Jeśli nie wiesz, czy twoja strona spełnia WCAG AA, użyj automatu do pierwszego screenu (np. Wave lub WebAIM tools) i ręcznie sprawdź 3 krytyczne elementy: kontrast, focus, alt. Link do praktycznej checklisty WCAG: WCAG checklist. Jeśli potrzebujesz pełnej zgodności prawnej, zleć audyt zewnętrzny. ([webaim.org)
Podsumowanie — kto powinien to zrobić i co dalej
Idealne dla: mały zespół produktowy, marketingowy właściciel landingów, PM szykujący release.
Będzie frustrować: zespoły z kompletnym, automatycznym QA (to tylko sanity-check).
Krótkie polecenie na teraz: odpal najważniejszy flow, przejdź listę 1–10, jeśli więcej niż 2 punkty to blocker — wstrzymaj publikację. Jeśli wszystkie krytyczne punkty są zielone — publikuj i monitoruj analytics przez 24–72 godziny.
Źródła i inspiracje: praktyczne checklisty dostępne publicznie, m.in. WebAIM (WCAG checklist), A11Y Project i przewodniki UX (np. UXPin). ([webaim.org)
