Ai două variante de text pentru un buton, un mesaj de eroare sau ecranul de plată, iar ambele par corecte. Alegerea bună nu ține doar de gust: contează ce încearcă să facă utilizatorul, cât știe deja despre produs și ce se întâmplă după ce apasă. Iată cum poți evalua textele pentru o aplicație înainte să ajungă la toți clienții.
Pornește de la acțiunea utilizatorului
Un text de interfață are o treabă precisă. Butonul trebuie să spună ce urmează, mesajul de eroare să explice ce nu a mers, iar confirmarea să arate dacă acțiunea s-a încheiat. Dacă două variante sunt la fel de plăcute la citit, dar una lasă loc de interpretări, pentru produs este mai slabă.
Să presupunem că ai o aplicație în care utilizatorii pot salva o ofertă. Pentru un buton, „Salvează oferta” descrie rezultatul. „Continuă” nu spune dacă oferta se salvează, dacă se deschide alt ecran sau dacă utilizatorul trebuie să mai facă un pas. A doua variantă poate fi potrivită într-un flux cu pași succesivi, dar nu dacă butonul încheie acțiunea.
Înainte să alegi formularea, notează ce trebuie să înțeleagă omul în acel moment. Nu ce știe echipa despre funcție, ci ce vede utilizatorul pe ecran și ce decizie are de luat. E o diferență mică în ședința de produs, dar vizibilă când cineva încearcă să finalizeze o comandă de pe telefon.
Ce face o variantă mai potrivită decât alta
Începe prin a verifica dacă textul este clar fără explicații din partea unui coleg. Apoi uită-te la lungime, ton și context. Un buton de trei cuvinte poate încăpea pe desktop și se poate rupe în două rânduri pe un telefon mai mic. Un mesaj prietenos poate suna nepotrivit când utilizatorul tocmai a pierdut date sau nu își poate accesa contul.
Contează și consecința acțiunii. Dacă utilizatorul șterge un document, formularea trebuie să facă limpede ce va dispărea și dacă există o cale de revenire. Dacă își schimbă parola, mesajul de confirmare ar trebui să spună dacă modificarea a fost făcută sau dacă mai trebuie să verifice e-mailul. Ambiguitatea nu este un detaliu stilistic când poate duce la o acțiune nedorită.
Un criteriu util este să citești textul împreună cu ecranul, nu separat, într-un document de lucru. Uită-te la titlu, câmpuri, butoane și mesajele din jur. „Trimite” poate fi suficient dacă formularul este clar și acțiunea evidentă. În alt loc, „Trimite cererea” îi oferă utilizatorului mai multă siguranță. Contextul decide, nu regula că textele trebuie să fie mereu cât mai scurte.
Vocea produsului trebuie să rămână consecventă, dar asta nu înseamnă că toate mesajele au același ton. O confirmare poate fi caldă și scurtă; o eroare de plată are nevoie de calm și de instrucțiuni precise. În munca editorială se vede des că echipele discută mult despre cuvinte și prea puțin despre momentul în care apare fiecare mesaj. Tocmai acel moment schimbă felul în care este înțeles textul.
Verifică textul în interfață, nu doar în document
Textele se schimbă când intră în produs. Butonul se poate îngusta, titlul poate ocupa două rânduri, iar o traducere poate fi mai lungă decât originalul. De aceea, verifică variantele în dimensiunile de ecran folosite de clienți și în limbile în care funcționează aplicația. Un text care pare firesc într-o machetă statică poate deveni greu de scanat într-un flux aglomerat.
Diacriticele sunt parte din lizibilitate și din felul în care se prezintă produsul. Dacă ai nevoie să pregătești temporar un text într-o formă fără diacritice, un instrument care elimină diacritice online poate ajuta la conversie, dar nu ar trebui să decidă forma finală a interfeței. Verifică apoi manual rezultatul: instrumentele de conversie nu pot ști dacă un termen, un nume propriu sau o formulare trebuie păstrate într-un anumit fel.
Mai sunt și constrângerile tehnice. Unele produse au limite de caractere, câmpuri cu lățime fixă sau componente care nu afișează bine anumite semne. Discută aceste limite cu echipa de design și de dezvoltare înainte să scurtezi textul. Tăierea automată a unei instrucțiuni poate elimina tocmai cuvântul care explică ce are de făcut utilizatorul.
Poți verifica și dacă textul are sens pentru cineva care nu cunoaște vocabularul intern al firmei. Termeni precum numele unei funcții, prescurtările sau formulările preluate din documentația tehnică pot părea firești echipei, dar nu și clientului. Dacă un utilizator trebuie să întrebe ce înseamnă butonul, e un semn că varianta merită revizuită.
Când merită să testezi două variante
Dacă textul apare într-un pas important, cum ar fi plata, crearea contului sau recuperarea accesului, nu te baza doar pe preferințele din ședință. Arată variantele unor persoane care seamănă cu publicul produsului și cere-le să spună ce cred că se va întâmpla după apăsare. Nu le explica înainte funcția: testul ar trebui să arate ce înțeleg din interfață, nu cât de bine pot urma instrucțiunile echipei.
Pentru schimbări cu impact mai mare, poți compara variantele în produs, dacă ai suficient trafic și o metodă de testare potrivită. Alege dinainte ce urmărești: finalizarea unei acțiuni, abandonul unui formular sau solicitările către serviciul de suport. Nu schimba simultan textul, designul și ordinea pașilor, fiindcă apoi nu vei ști ce a influențat rezultatul.
Un test nu transformă automat varianta cu cele mai multe apăsări în cea mai bună. Dacă un buton promite prea mult, poate atrage clicuri și totuși să îi dezamăgească pe utilizatori pe ecranul următor. Citește rezultatele împreună cu comportamentul de după acțiune și cu feedbackul primit de echipa de suport.
Ce faci când echipa nu se hotărăște
Scrie variantele una lângă alta și precizează pentru fiecare ce înțelege utilizatorul, ce ar putea interpreta greșit și cât spațiu ocupă în interfață. Discuția devine mai utilă când echipa compară efectele, nu preferințele personale. Dacă nimeni nu poate explica de ce o formulare este mai bună, probabil că mai lipsește context despre ecran sau despre public.
Într-o aplicație folosită de clienți foarte diferiți, este posibil să nu existe o formulare perfectă pentru toată lumea. Poți avea nevoie de termeni mai simpli, de explicații suplimentare într-un pas sensibil sau de mesaje diferite pentru situații distincte. Important este ca fiecare text să corespundă acțiunii și să nu lase utilizatorul să ghicească ce urmează.
Întrebări frecvente
Cât de lung ar trebui să fie textul unui buton?
Atât cât să descrie clar acțiunea, fără cuvinte de umplutură. Verifică-l în interfața reală, pe ecrane mici, nu doar într-un document.
Este mai bine să folosesc persoana a doua?
Depinde de vocea produsului și de situație. Păstrează aceeași perspectivă în mesaje similare și evită formulările care par prea familiare într-un moment sensibil.
Cine ar trebui să aprobe textele din aplicație?
De regulă, decizia implică produsul, designul și dezvoltarea, iar pentru fluxuri importante și echipa de suport. Un redactor sau specialist în conținut poate verifica limpezimea și consecvența.
Cea mai bună formulare nu este neapărat cea mai ingenioasă. Este cea care îl ajută pe utilizator să înțeleagă ce se întâmplă, să aleagă fără ezitare și să nu fie surprins de pasul următor.
Acest articol are scop informativ și editorial. Fiecare produs are propriile constrângeri, iar textele trebuie verificate în contextul interfeței și al publicului căruia i se adresează.
