UX writing

UX writing to projektowanie tekstów interfejsu tak, by prowadziły użytkownika w sposób jasny i naturalny.

UX writing jako warstwa interfejsu

UX writing oznacza projektowanie i redagowanie tekstów, które występują bezpośrednio w interfejsie aplikacji, systemu operacyjnego, strony internetowej albo urządzenia. Dotyczy między innymi etykiet przycisków, nazw pól formularzy, komunikatów walidacyjnych, instrukcji wyświetlanych podczas konfiguracji, opisów ustawień, powiadomień oraz ekranów błędów. Tekst nie jest tu dodatkiem do grafiki. Razem z układem elementów, ikonami, kolorami i zachowaniem programu tworzy mechanizm, za pomocą którego użytkownik rozpoznaje dostępne działania i przewiduje ich skutki.

Podstawowym celem jest zmniejszenie niepewności podczas wykonywania operacji. Etykieta „Zapisz kopię” wskazuje inną czynność niż „Zapisz”, a „Usuń konto” jest bardziej jednoznaczne niż samo „Kontynuuj” na ekranie trwałego usuwania danych. Dobry tekst interfejsu opisuje działanie z perspektywy użytkownika, używa czasowników oznaczających konkretną czynność i zachowuje spójność nazewnictwa w całym produkcie. Jeżeli w jednym miejscu funkcja nazywa się „Ustawienia sieci”, a w innym „Konfiguracja połączenia”, użytkownik może nie rozpoznać, że chodzi o ten sam obszar systemu.

Komunikaty, formularze i obsługa błędów

UX writing ma szczególne znaczenie w formularzach, ponieważ tekst wpływa na to, czy użytkownik poprawnie poda dane i zrozumie wymagania techniczne. Pole wyboru pliku może określać dozwolone rozszerzenia, a pole hasła może informować o konieczności użycia określonych znaków, jeżeli takie ograniczenie rzeczywiście wynika z implementacji. Komunikat walidacyjny powinien wskazywać problem w konkretnym miejscu, na przykład informować, że adres e-mail nie zawiera wymaganej części domenowej, zamiast wyświetlać ogólne „Wprowadzono nieprawidłowe dane”. Tekst powinien pojawić się w sposób powiązany z odpowiednim polem, aby także użytkownik korzystający z czytnika ekranu mógł ustalić, czego dotyczy błąd.

Komunikat o awarii powinien rozdzielać informację o stanie systemu od instrukcji dalszego działania. Zdanie „Nie udało się pobrać aktualizacji. Sprawdź połączenie z internetem i spróbuj ponownie” jest użyteczne tylko wtedy, gdy ponowienie operacji faktycznie może rozwiązać problem. Jeżeli aplikacja udostępnia identyfikator błędu, numer zgłoszenia lub szczegóły diagnostyczne, należy opisać ich przeznaczenie i sposób skopiowania. Nie powinno się zastępować komunikatu technicznym kodem wyjątku, ścieżką pliku konfiguracyjnego ani surowym komunikatem biblioteki, jeżeli nie pomagają one użytkownikowi podjąć właściwej decyzji. Jednocześnie tekst nie może obiecywać wykonania czynności, której program nie przeprowadził, na przykład wyświetlać „Plik zapisano”, gdy zapis dopiero się rozpoczyna.

Spójność tekstu z działaniem programu

Projektowanie tekstów interfejsu wymaga współpracy z projektem wizualnym, programistami, testerami i osobami odpowiedzialnymi za dostępność. Każdy komunikat powinien mieć określony warunek wyświetlenia, źródło danych oraz możliwe następne kroki. Dla operacji asynchronicznych trzeba rozróżnić stan oczekiwania, powodzenie, częściowe wykonanie, anulowanie i błąd. Przykładowo aplikacja synchronizująca folder może pokazywać, że pliki są analizowane, że synchronizacja została zakończona albo że część plików pominięto z powodu konfliktu nazw. Sam napis „Gotowe” nie przekazuje, czy wszystkie elementy zostały przetworzone.

Teksty powinny być przygotowane z uwzględnieniem lokalizacji i zmian długości po tłumaczeniu. Polskie sformułowania często zajmują więcej miejsca niż ich angielskie odpowiedniki, dlatego przyciski i komunikaty nie mogą zależeć od jednej, sztywnej szerokości. Daty, godziny, jednostki i formaty liczb muszą odpowiadać ustawieniom regionalnym, a tłumaczenie nie powinno zmieniać znaczenia operacji. Ważne jest także rozróżnienie tekstu widocznego od etykiet używanych przez technologie asystujące. Ikona kosza może mieć wizualne znaczenie dla osoby widzącej, ale przycisk powinien posiadać tekstową nazwę, na przykład „Usuń plik”, przekazaną do warstwy dostępności. Weryfikacja obejmuje więc nie tylko poprawność językową, lecz także zgodność z rzeczywistym stanem aplikacji.

UX writing w codziennym użytkowaniu komputera

Na laptopie i komputerze PC teksty interfejsu pojawiają się podczas instalowania sterowników, konfigurowania drukarki, łączenia z siecią bezprzewodową, przywracania systemu, zmiany uprawnień oraz rozwiązywania problemów z urządzeniami. Jasny komunikat powinien wskazywać, czy użytkownik ma wykonać czynność w ustawieniach systemu, podłączyć przewód, ponownie uruchomić urządzenie, czy skontaktować się z administratorem. Nie należy utożsamiać UX writingu z samym upraszczaniem języka. Równie istotne jest zachowanie precyzji: określenie „sterownik karty sieciowej” może być potrzebne, gdy użytkownik musi odróżnić go od sterownika modułu Bluetooth albo kontrolera dźwięku.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a poprawnie opisane komunikaty mogą ułatwić przekazanie informacji o objawach, etapach uruchamiania systemu lub treści błędu. Podczas zgłoszenia warto podać dokładny tekst komunikatu, moment jego wystąpienia oraz czynność, po której się pojawia, zamiast ograniczać opis do stwierdzenia, że komputer „nie działa”. Takie dane pomagają odróżnić problem z aplikacją od kłopotu ze sterownikiem, konfiguracją systemu, połączeniem urządzenia lub samym komponentem. UX writing pozostaje zatem częścią projektowania interakcji, ale jego skutki widać również w sposobie diagnozowania problemów i komunikowania stanu urządzenia.