UX writing po polsku: co psuje interfejsy i jak to naprawić

Strona, której użytkownicy nie rozumieją, ma ten sam problem co strona, której nie widać w Google. W obu przypadkach ktoś nie dotarł tam, gdzie miał dotrzeć. Tyle że złe pozycjonowanie jest mierzalne w Analytics, a tekst "Wystąpił błąd. Spróbuj ponownie." nikt nie raportuje jako problem.

UX writing to teksty, które interfejs wyświetla zamiast ciebie: przyciski, komunikaty błędów, etykiety pól, tooltopy, stany ładowania, puste ekrany. Każdy z nich to punkt, w którym użytkownik albo rozumie, co ma zrobić, albo nie. Nie ma tu miejsca na "mniej więcej". Tekst, który wprowadza wątpliwość, robi to zawsze.

Dlaczego to ważniejsze niż się wydaje

Nawet dobrze zaprojektowany interfejs nie ratuje się sam, jeśli tekst na przycisku mówi nie to, co powinien. Design usuwa tarcie wizualne. Tekst usuwa tarcie poznawcze. Jedno bez drugiego jest tylko połową roboty.

Zasady użytecznych komunikatów sformalizowane przez Nielsen Norman Group są proste: tekst interfejsu powinien pomagać użytkownikom rozpoznać problem, zrozumieć go i wiedzieć, co dalej zrobić. Heurystyka nr 9 w standardowej liście ocen UX opisuje to wprost jako "Help users recognize, diagnose, and recover from errors" i obowiązuje jako standard oceny interfejsów od dekad.

W praktyce: użytkownik, który dostaje komunikat "Błąd" bez żadnego kontekstu, nie wraca do zadania. Wychodzi. Użytkownik, który widzi przycisk "Wyślij" tuż przed wysłaniem formularza rejestracyjnego, nie wie, co się stanie po kliknięciu. Niepewność przed podjęciem nieodwracalnej akcji to jeden z podstawowych powodów porzucania procesów w połowie drogi.

Skąd się bierze problem

Najczęstszy scenariusz wygląda tak: designer projektuje ekrany z Lorem Ipsum w miejscu tekstów, bo treść "dorzuci się później". Programista dodaje etykiety przycisków z głowy, bo trzeba coś wpisać. Jeśli w firmie jest ktoś od marketingu, dorzuca opis powitalny w stylu "Cieszymy się, że jesteś z nami." Nikt tego nie czyta razem, zanim trafi do użytkownika, i nikt nie sprawdza, czy trzy osoby piszące do jednej strony piszą w tym samym tonie.

Efekt jest przewidywalny. Strona, która w menu mówi "Twoje konto", w stopce "Zapraszamy serdecznie", a w formularzu "Proszę podać adres email", brzmi jak trzy różne firmy sklejone w jedno. Użytkownik tego nie analizuje, ale czuje, że coś nie gra.

Do tego dochodzi tłumaczenie z angielskiego. Polskie produkty startują często z angielskich wzorców i są lokalizowane zdanie po zdaniu, bez zatrzymania się nad tym, co wynika z języka polskiego. Angielski ma jedno "you". Polski ma "ty" i "Pan/Pani", i decyzja między nimi musi zapaść raz, na początku, dla całego produktu. Kiedy nie zapada, na każdej podstronie wychodzi inaczej.

Co z tego wynika w praktyce

Weźmy jeden konkretny przykład. Wypełniasz formularz zamówienia, klikasz przycisk i zamiast potwierdzenia pojawia się komunikat: "Błąd. Operacja nie powiodła się." Co się stało? Nie wiadomo. Co zrobić? Też nie wiadomo. Większość ludzi w tym miejscu zamyka zakładkę i nie wraca.

Ten sam komunikat napisany inaczej: "Nie udało się przetworzyć płatności. Sprawdź, czy numer karty ma 16 cyfr." Sytuacja jest identyczna, ale użytkownik ma coś, czego wcześniej nie miał: instrukcję. To jest różnica między tekstem, który opisuje stan systemu, a tekstem, który mówi człowiekowi, co ma zrobić.

Dokładnie ten sam schemat działa w każdym innym miejscu interfejsu. Pusty ekran z napisem "Brak danych" wygląda jak awaria dla kogoś, kto właśnie założył konto. "Tu pojawią się twoje zamówienia, kiedy złożysz pierwsze." to nie jest więcej informacji, to po prostu informacja podana z kontekstem. Przycisk "Wyślij" przed formularzem ofertowym mówi tyle co nic, bo nie wiadomo, co się wyśle i co dostaniesz w odpowiedzi. "Zamów bezpłatną wycenę" usuwa tę niepewność jednym słowem. Okienko z pytaniem "Czy na pewno chcesz usunąć?" i przyciskami "Tak" i "Nie" zmusza do przetłumaczenia abstrakcyjnego pytania na konkretną decyzję. "Usuń na zawsze" i "Wróć" tego nie wymagają.

To nie są rzeczy, które użytkownicy zauważają i komentują. To rzeczy, które po prostu działają albo nie.

Jak to naprawić

Pierwsza zmiana jest procesowa. Teksty interfejsu muszą być częścią projektu od początku, nie czymś, co wpisuje się na koniec, kiedy grafiki są już zatwierdzone. Kiedy ktoś projektuje ekran, powinien od razu wiedzieć, co się na nim pojawi, nie zostawiać "Lorem ipsum" z nadzieją, że ktoś uzupełni.

Zaczyna się od jednej decyzji: czy mówimy do użytkownika "ty" czy "Pan/Pani". Brzmi banalnie, ale jeśli nie ustalicie tego zanim zaczniesz budować, każdy pisze po swojemu. Do tego dodaj kilka terminów: jak nazywacie główny obiekt w systemie, jakich słów unikacie, czego nie piszecie nigdy. To nie musi być długi dokument. Dwie strony A4 wystarczą, żeby wszyscy pisali tym samym głosem.

Potem, przy każdym ekranie, który może pokazać coś innego niż "wszystko działa" -błąd, pustą listę, potwierdzenie usunięcia, stan ładowania -zaplanuj tekst tak samo jak planuje się układ. Co widzi użytkownik? Co mu to mówi? Jaki ma kolejny krok? Jeśli to jest zapisane w projekcie, ktoś to napisze z głową. Jeśli nie, ktoś wpisze pierwszą rzecz, jaka przyjdzie mu do głowy.

I ostatnia rzecz, bez której reszta się nie utrzyma: musi być jedna osoba, która odpowiada za to, co jest napisane w interfejsie. Nie musi to być specjalista od UX writingu, może to być designer albo PM. Ważne, że ktoś ma ostatnie słowo. Bez tego każda zmiana tekstu to decyzja podejmowana od nowa, przez kogoś innego, za każdym razem.

Interfejs bez właściciela tekstów zawsze to widać. I zawsze to czuć.