Dlaczego brzydkie UI to realny problem testerski?

1. Brzydkie UI wprowadza chaos. A chaos to wróg testera.

Pierwsza sprawa: kiedy interfejs jest niespójny, chaotyczny, wygląda inaczej na każdej podstronie – to jako tester masz realny problem. Bo nie wiesz, czy coś jest błędem, czy tak miało być.

Na jednej stronie przyciski są zaokrąglone, na innej kanciaste. Tu odstępy są 16px, tam 4px. Tu input ma placeholder, tam nie. I teraz pytanie: czy to bug? Czy ktoś po prostu zapomniał stylu? A może to nowy design, ale wdrożony tylko częściowo?

W dobrze zaprojektowanym UI od razu widać, że coś się „rozjechało”. W brzydkim – wszystko wygląda dziwnie, więc nic nie rzuca się w oczy.

Efekt? Testujesz i co chwilę się zastanawiasz: zgłaszać to czy nie? A jak już zgłosisz, to dostajesz odpowiedź: „tak miało być”. I potem zaczynasz się bać zgłaszać drobiazgi, bo nie chcesz wyjść na czepialskiego. A stąd już tylko krok do pomijania realnych błędów, bo… „pewnie znowu tak miało być”.

2. Użytkownicy gubią się w brzydkim interfejsie. I zgłaszają „błędy”, których nie ma.

To jeden z moich ulubionych przypadków. Testujemy funkcjonalność, wszystko działa. Ale po uruchomieniu produkcji – support ma zalew zgłoszeń: „Nie mogę znaleźć opcji X”, „Nie działa przycisk Z”, „Nie da się dodać danych”.

I co się okazuje? Wszystko działa. Ale użytkownik nie widzi opcji, bo UI jest nieintuicyjne. Przycisk jest – ale wygląda jak tekst. Albo umieszczony jest w takim miejscu, że nikt tam nie zajrzy. Albo kolor jest tak słaby, że na jasnym ekranie go nie widać. Klasyka.

I znowu – kto się tym zajmuje? Tester. Bo zanim ktokolwiek zacznie analizować UX, ktoś musi sprawdzić, czy to przypadkiem nie bug techniczny.

A przecież to nie był problem z backendem, tylko z designem. Ale to tester siedzi i analizuje, odtwarza kroki, testuje na różnych urządzeniach. I traci czas na coś, co nie powinno się wydarzyć, gdyby UI był dobrze przemyślany.

3. Brzydki UI to często efekt… braku procesu

Nie oszukujmy się: brzydkie UI to nie tylko kwestia gustu. To często symptom braku procesu. Brak design systemu, brak dokumentacji komponentów, brak osoby odpowiedzialnej za frontend.

Kiedy każdy dev styluje po swojemu, bo „szybciej tak niż prosić grafika” – powstaje potworek. I ten potworek trafia potem do testowania.

A teraz postaw się na miejscu testera, który ma przetestować 20 widoków, z czego każdy wygląda inaczej, używa innych klas CSS, inne ma przyciski, inne fonty, inne zachowania po kliknięciu.

Jak masz w takiej sytuacji napisać sensowne testy regresji? Jak zautomatyzować coś, co nie ma wspólnego wzorca? Każdy widok trzeba obsłużyć osobno. Każdy element znaleźć inaczej. Koszty testowania rosną, a morale spadają.

4. Testy wizualne w takim UI? Powodzenia…

Jeśli ktoś kiedyś próbował robić snapshot testing w środowisku z chaotycznym UI, to wie, o czym mówię.

Narzędzia takie jak Percy, Applitools, czy po prostu screenshot comparison w Playwright lub Cypress – świetne rozwiązania. Ale tylko wtedy, gdy layout jest stabilny. Gdy elementy nie skaczą o 2px w górę przy każdym buildzie. Gdy nie ma randomowego generowania ID w HTML. Gdy cienie, spacingi, wysokości są trzymane w ryzach.

W przeciwnym razie – snapshoty świecą się na czerwono po każdym deployu, nawet jeśli nic się nie zmieniło funkcjonalnie. I znowu – tester siedzi, przegląda różnice, zatwierdza zmiany, bo „tym razem cień się wygładził bardziej niż wczoraj”. Zamiast testować rzeczy ważne – gasi pożary stylów.

5. Złe UI to złe UX. A złe UX to błędy, które nie wyglądają jak błędy

W projektach, gdzie UI kuleje, często kuleje też UX. A to oznacza, że użytkownik nie wie, co ma robić. I podejmuje złe decyzje. Kliknie nie tam, gdzie trzeba. Przejdzie przez formularz bez uzupełnienia ważnych danych. Zinterpretuje komunikat błędu inaczej, niż autor miał na myśli.

To wszystko kończy się „dziwnym” zachowaniem aplikacji. Czyli – z punktu widzenia testera – potencjalnymi błędami. I znowu: odtwórz to, zrozum, czy tak miało być, dopytaj zespół, wpisz zadanie, opisz… a wystarczyło zaprojektować to z głową.

Dobry UI to taki, który prowadzi użytkownika za rękę. Brzydki i zły UI to taki, który zostawia użytkownika w ciemnym pokoju z dziesięcioma drzwiami i żadną wskazówką, które są otwarte.

6. Brzydkie UI zniechęca do testowania

To może brzmieć trywialnie, ale jest cholernie prawdziwe. Jeśli dostaję do testów aplikację, która wygląda jak zrobiona w MS Paint, to… nie mam motywacji. Testowanie to często żmudna robota, wymagająca skupienia i dokładności. A jak UI odrzuca już na wejściu – to testowanie staje się jeszcze bardziej męczące.

I jasne, profesjonalizm to jedno – ale jesteśmy tylko ludźmi. Jeśli aplikacja jest estetyczna, przejrzysta, przyjemna – to i testuje się ją lepiej. A jak masz poczucie, że testujesz coś, czego nikt nie dopracował, to masz wrażenie, że Twoja praca też pójdzie w powietrze.

To co, tester ma być grafikiem?

Nie. Ale tester powinien umieć zauważyć, kiedy UI jest problemem jakościowym, a nie tylko „kwestią gustu”. Nie chodzi o to, żebyśmy robili review kolorów i gradientów – ale żebyśmy potrafili wyłapać rzeczy, które mogą wprowadzać użytkownika w błąd, powodować frustrację, albo wpływać na funkcjonalność aplikacji.

Jeśli przycisk wygląda jak etykieta – to jest problem.
Jeśli formularz wygląda inaczej na każdej stronie – to jest problem.
Jeśli tooltip zasłania pół ekranu – to też jest problem.

Co można z tym zrobić?

1. Feedback w code review – nawet jeśli nie jesteś frontendowcem, możesz dodać komentarz typu „czy to UI na pewno jest zgodne z resztą widoków?”.

2. Zgłaszaj problemy jako UX bugs – nie bój się wpisywać takich rzeczy do backlogu. Nawet jeśli nie są krytyczne technicznie, to wpływają na odbiór.

3. Proś o design system / figmę / referencję – warto mieć punkt odniesienia, żeby wiedzieć, jak coś powinno wyglądać.

4. Edukacja zespołu – jeśli widzisz, że frontend leży, warto porozmawiać. Może brakuje zasobów, może nie ma UI designera – a może nikt wcześniej nie zwrócił na to uwagi.