Nazwij obiekt i skutek działania, wyjaśnij nietypowe dane wejściowe przed wystąpieniem błędu, a po każdym wyniku powiedz, co się stało i co użytkownik może zrobić dalej.
Mikroteksty (microcopy) to krótkie teksty przy elementach sterujących i stanach: nazwa przycisku, etykieta, zdanie pomocnicze, komunikat błędu, potwierdzenie lub ostrzeżenie. Są krótkie, ale decydują o tym, czy użytkownik rozumie skutek działania. Ogólne „Kontynuuj”, „Nieprawidłowe” czy „Gotowe” często przerzucają odpowiedzialność za interpretację na użytkownika.
Dobre mikroteksty wynikają z rzeczywistego procesu i używają tych samych pojęć na stronie, w e-mailach i w obsłudze klienta. Nie mogą ukrywać ceny, zgody ani ryzyka i nie powinny manipulować poczuciem winy. Tekst projektuje się razem z interfejsem, stanami technicznymi oraz treściami prawnymi lub specjalistycznymi, a nie jako ostatnią dekorację przed uruchomieniem.
Słownik produktu zapewnia, że jedno pojęcie nie zmienia znaczenia
Utwórzcie listę kluczowych obiektów, działań i stanów: zapytanie, zamówienie, projekt, wersja robocza, wysłanie lub publikacja. Wybierzcie nazwy zrozumiałe dla użytkowników i napiszcie ich definicje. Jeśli „anuluj” raz oznacza zamknięcie okna dialogowego, a innym razem zakończenie subskrypcji, interfejs tworzy niebezpieczną dwuznaczność.
Te samo słownictwo należy stosować w nawigacji, przyciskach, potwierdzeniach, e-mailach i wsparciu. Tłumacz potrzebuje kontekstu, limitu i zmiennych, a nie wyizolowanego ciągu znaków. Należy unikać składania zdań z fragmentów, które w innym języku zmienią szyk lub gramatykę. Właściciel słownika zatwierdza nowe terminy i synonimy.
- jednolita nazwa obiektu w całym procesie
- czasownik odpowiadający rzeczywistej akcji
- zdefiniowane stany i przejścia między nimi
- kontekst dla tłumaczenia i odmiany
Przycisk nazywa rezultat, a nie nieokreślony ruch
Zamiast ogólnego „Tak” lub „OK” użyjcie „Usuń fakturę”, „Zapisz wersję roboczą” lub „Wyślij zapytanie”. W procesie wieloetapowym odróżniajcie przejście do kolejnego kroku od ostatecznego potwierdzenia zobowiązania. Przycisk główny i dodatkowy powinny mieć wyraźnie różne skutki, a nie tylko inny kolor.
Akcja destrukcyjna wymaga precyzyjnie wskazanego obiektu, a w zależności od ryzyka możliwości cofnięcia lub potwierdzenia. Nie używaj okna potwierdzenia przy każdym drobiazgu, bo stanie się rutyną. Jeśli operacja trwa, etykieta lub stan informują o postępie, a przycisk zapobiega ponownemu uruchomieniu, nie udając przy tym zakończenia.
Tekst pomocniczy zapobiega błędom i wyjaśnia wrażliwe pytanie
Label nazywa pole, a tekst pomocniczy uzupełnia format, zakres lub powód. Przykład warto podać tylko wtedy, gdy zmniejsza niejasność, i nie zapisywać go jako wartości domyślnej. Obowiązkowość i opcjonalność należy komunikować spójnie. Przy danych wrażliwych cel trzeba wyjaśnić bezpośrednio przy polu i odesłać do szczegółów bez przeciążania ekranu.
Instrukcję napisz przed interakcją, a nie dopiero w komunikacie o błędzie. Unikaj wewnętrznych kodów i warunków typu „musi spełniać regex”. Jeśli kilka formatów jest prawidłowych, akceptuj je lub jasno wyjaśnij ograniczenie. Mikrocopy nie może żądać danych, których system nie potrzebuje, tylko dlatego, że tekst potrafi uzasadnić ich zbieranie.
- przeznaczenie pola zrozumiałe z etykiety
- format i ograniczenie wyjaśnione z wyprzedzeniem
- powód zbierania bardziej wrażliwych danych
- przykład, którego nie można pomylić z wartością
Komunikaty o błędzie i potwierdzenia odnoszą się do konkretnego zadania
Komunikat o błędzie nazywa problem i sposób naprawy: które pole, jaki format lub dlaczego akcja jest niedostępna. Nie należy obwiniać użytkownika ani używać humoru przy utracie danych, płatności lub problemie z bezpieczeństwem. Szczegóły techniczne należą do logu; użytkownik może otrzymać bezpieczny kod referencyjny dla działu wsparcia.
Po sukcesie proszę potwierdzić obiekt, status i kolejny krok. Jeśli wysłane dane wciąż czekają na przetworzenie, nie należy pisać „Gotowe”. W przypadku e-maila proszę podać adres, na który został wysłany, tylko jeśli jego wyświetlenie jest bezpieczne, ewentualnie częściowo go zamaskować. Komunikat powinien pozostać widoczny wystarczająco długo i zostać ogłoszony w dostępny sposób.
Test mikrocopy sprawdza zrozumienie bez naprowadzania
Proszę pokazać interfejs i zapytać, co stanie się po aktywacji, jakie dane są potrzebne i jak użytkownik poprawiłby błąd. Nie należy pytać jedynie o opinię, czy tekst się podoba. Warto obserwować błędne interpretacje, wahania i powroty. Test A/B kliknięć nie może usprawiedliwiać manipulacyjnego tekstu ani ukrytych konsekwencji.
Należy rejestrować zmiany wraz z ich przyczyną, stanem interfejsu i właścicielem. Warto śledzić powtarzające się pytania do wsparcia, błędne dane wejściowe i rezygnacje, chroniąc przy tym dane osobowe. Jeśli tekst ma znaczenie prawne lub specjalistyczne, powinna go sprawdzić osoba o odpowiednich kwalifikacjach. Jasność i prawdziwość mają pierwszeństwo przed krótkotrwałym wzrostem jednego wskaźnika.
- użytkownik potrafi przewidzieć skutek działania
- rozumie powód i format wymaganej informacji
- potrafi wskazać naprawę po błędzie
- potwierdzenie odpowiada rzeczywistemu stanowi systemu
- ta sama terminologia w interfejsie, e-mailach i wsparciu
Najczęstsze pytania
Czy tekst przycisku powinien być zawsze jak najkrótszy?
Nie. Powinien być zwięzły, ale na tyle precyzyjny, by skutek był zrozumiały. Kilka dodatkowych słów jest lepsze niż niejednoznaczne „OK” przy ważnej akcji.
Czy humor w komunikacie o błędzie jest odpowiedni?
Tylko przy niskim ryzyku i bez bagatelizowania problemu. Przy utracie pracy, płatności, prywatności lub bezpieczeństwie tekst powinien być rzeczowy i empatyczny.
Czy AI może tworzyć mikrocopy?
Może zaproponować warianty, ale przed publikacją człowiek musi zweryfikować proces, terminologię, dostępność, prawdziwość i wrażliwe konsekwencje.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
