UX Writing: Arayüz Metnini Tasarımdan Önce Yazmak

Arayüzdeki metin çoğu projede en sona kalır. Ekran çizilir, kutular yerleşir, sonra birine "şuraya bir şeyler yaz" denir. Böyle yazılan cümleler kullanıcının o an ne bilmediğini değil, kutunun kaç karakter aldığını anlatır. UX writing büyük ölçüde bu sıralamayı tersine çevirme işi.

Metin önce, kutu sonra

Lorem ipsum'la doldurulmuş bir ekran her zaman gerçek metinle doldurulmuş halinden daha ferah görünür. Sahte metnin uzunluğu tasarımcının seçtiği uzunluktur; gerçek metnin uzunluğu ürünün karmaşıklığından gelir. Peki ya bir ekranın metnini yazmaya çalışırken cümle bir türlü toparlanmıyorsa? Bu genelde yazım sorunu değildir. O ekranda kullanıcıdan aynı anda iki farklı karar isteniyor olabilir, ya da öncesinde açıklanmamış bir kavram ilk kez orada karşısına çıkıyordur.

Hata ve boş durum metinlerini genelde ekran çizilmeden önce yazarım; hangi ekranın aslında gereksiz olduğu en hızlı böyle ortaya çıkıyor. Boş durum metnini yazarken "burada henüz bir şey yok" demekten fazlası aklınıza gelmiyorsa, o ekranın kullanıcıya ne kazandırdığını yeniden düşünmek gerekir.

Tarayan gözle merak uyandırmak çelişir

Kullanıcıların ekranı baştan sona okumadığı, başlıklara ve satır başlarına takılarak ilerlediği yeterince bilinen bir şey. Buradan çıkarılan iki tavsiye ise birbirini yer: bir yanda "ilk kelimeler taşısın", diğer yanda "merak uyandıran başlıklar kullanın".

Tarayan bir gözün merak boşluğuna verdiği tepki tıklamak değil, geçmektir. Başlığın ilk iki kelimesi içeriğin ne olduğunu söylemiyorsa okuyucu o bölümü atlar, çünkü ne kaçırdığını bilmiyordur. Arayüzde bu daha da serttir. "Gönder" yazan bir buton neyi kime gönderdiğini söylemez; "Formu kaydet" ya da "Talebi destek ekibine ilet" söyler. Buton etiketi bir vaat değil, kullanıcının az sonra yapacağı şeyin adıdır.

Hata mesajının kısa olma zorunluluğu yok

Sadelik ilkesi arayüzün her yerinde aynı biçimde çalışmaz. Hata mesajının işi bilgi vermek değil, kullanıcıyı takıldığı yerden çıkarmaktır. Ne olduğunu ve bundan sonra ne yapılacağını söylemeyen mesaj kısa değil, eksiktir.

"Bir hata oluştu" cümlesi altı kelimelik bir sessizliktir. "Kart numarası 16 haneli olmalı, siz 15 hane girdiniz" daha uzundur ve kullanıcıyı ekranda tutar. Uzunluk sorunu değilse ne sorundur? Genellikle mesajın nereden geldiği.

Metin kodun neresinde duruyor

Bir hata metnini düzeltmek bazen beş dakikalık, bazen bir sürüm çıkmayı gerektiren iştir. Fark, o cümlenin nerede saklandığından gelir. Sunucu kodunun içine string olarak gömülmüş bir mesaj, yazarın dokunabileceği bir yerde değildir; çeviri anahtarıyla sözlük dosyasında duran mesaj ise ürün ekibinin gün içinde değiştirebileceği bir içeriktir. Metni ciddiye alan bir ekip, önce metnin nerede yaşadığına karar verir.

İngilizce şablonlardan devralınan çoğul kurgusu da aynı yerden patlar. {count} items deleted yapısı Türkçeye birebir taşındığında "3 öğeler silindi" çıkar, oysa Türkçede sayıdan sonra çoğul eki gelmez. Burada dil başına ayrı çoğul kuralı kurmaya da gerek yoktur, tek biçim yeter: {count} öğe silindi. Aynı dikkatsizlik zaman ifadelerinde, birim gösteriminde, cinsiyet varsayan zamirlerde tekrar eder.

Karakter uzunluğu da tasarımın işidir, yazarın değil sanılır. "Save" dört karakter, "Kaydet" altı, "Değişiklikleri kaydet" yirmi bir. Sabit genişlikte tasarlanmış bir buton üçüncüsünde taşar ya da metni keser. Arayüz metnini en uzun dilde denemeden bileşen genişliğini sabitlemek, sonradan mutlaka geri dönülen bir karardır.

Ton en çok kötü anda sınanır

Marka sesi dokümanı yazmak kolaydır, dört yüz ekrana tutarlı biçimde uygulamak zordur. Tonun gerçek olup olmadığı da işlerin yolunda gittiği ekranlarda anlaşılmaz. Şakacı bir ürünün ödeme başarısız mesajında şaka yapması, o tonun kullanıcı için değil ekip için seçildiğini gösterir. Kullanıcı para kaybetmekten korkarken esprili olmak, samimiyet değil sağırlıktır.

Metni test etmenin ucuz yolu

Arayüz metni için ayrı bir araştırma bütçesi çıkarmak çoğu ekipte mümkün olmuyor. Mevcut kullanılabilirlik testine iki soru eklemek ise bedavaya yakın. Ekranı beş saniye gösterip kapatın, sonra "bu butona basarsanız ne olur" ve "bu ekranda sizden ne isteniyor" diye sorun. Cevaplar birbirini tutmuyorsa sorun metindedir, kullanıcının dikkatinde değil.