UX Writing Nedir? Ziyaretçiyi Harekete Geçiren Web Metinleri Nasıl Yazılır?

UX writing, bir web sitesindeki buton, form etiketi, hata mesajı ve boş ekran gibi küçük metinlerin ziyaretçiyi yormadan doğru adıma taşımasını sağlayan yazım disiplinidir. Bu yazıda bu mikro metinleri tek tek ele alıyorum. Amacım size kuram değil, yarın sabah sitenizde uygulayabileceğiniz somut bir çalışma düzeni vermek.

UX writing nedir, web sitesinde neyi kapsar?

UX writing, kullanıcı arayüzündeki mikro metinleri (buton, form etiketi, yardım notu, hata mesajı, boş durum ve onay metni) ziyaretçinin görevini hızlı, hatasız ve güvenle tamamlaması için tasarlama işidir. Ölçütü güzel cümle değil, tamamlanan görevdir: form gönderildi mi, sepet onaylandı mı, kullanıcı takıldı mı?

Kapsamı çoğu işletmenin sandığından geniştir. Ana sayfadaki büyük başlık bir pazarlama metnidir; ancak o başlığın altındaki "Teklif iste" butonu, formdaki "Telefon numaranız" etiketi ve yanlış girişte çıkan kırmızı uyarı UX writing alanına girer. Yani ziyaretçinin bir şey yapmak üzere olduğu her noktada karşısına çıkan kelimeler bu işin konusudur.

2012'den beri kurduğum ve denetlediğim sitelerde en az emek verilen metinler de tam olarak bunlar oluyor. Tasarımcı kutuyu çiziyor, geliştirici içine geçici bir kelime koyuyor ve o kelime yıllarca canlıda kalıyor. Bu nedenle UX writing bana göre bir süsleme değil, arayüzün ta kendisidir.

UX writing ile metin yazarlığı arasındaki fark nedir?

İkisi de kelimeyle çalışır, fakat hedefleri farklıdır. Metin yazarlığı ilgiyi çeker ve ikna eder; UX writing ise ikna olmuş kişinin yolunu açar. Birincisi "neden bizi seçmelisiniz?" sorusuna, ikincisi "şimdi ne yapmalıyım?" sorusuna cevap verir. Aşağıdaki tablo farkı günlük işte nasıl gördüğümü özetliyor.

Kısacası iki disiplin birbirini tamamlar. Güçlü bir tanıtım metni ziyaretçiyi forma kadar getirir, ama formdaki belirsiz bir etiket o emeği son adımda boşa çıkarabilir. Öte yandan marka sesi ve ton konusu ayrı bir başlıktır; bu yazıda yalnızca işlevsel metne odaklanıyorum.

Mikro metin neden dönüşümü bu kadar etkiler?

Çünkü mikro metin, kararın verildiği anda okunur. Ziyaretçi uzun tanıtım paragrafını çoğu zaman tarar, ama tıklayacağı butonun üstündeki iki kelimeyi mutlaka okur. O iki kelime belirsizse tereddüt başlar; tereddüt ise terk etmenin ilk adımıdır.

Sahada en sık gördüğüm senaryo şöyle: işletme reklam bütçesini artırıyor, trafik geliyor, fakat form tamamlanmıyor. Isı haritasına baktığımızda ziyaretçinin formun belirli bir alanında durduğunu görüyoruz. Çoğu zaman sorun tasarım değil, o alanın ne istediğini açıklamayan bir etikettir. Dolayısıyla metni düzeltmek, en ucuz dönüşüm iyileştirmelerinden biridir.

Bu durum, arayüz tasarımındaki UX hatalarının satışı nasıl düşürdüğünü anlattığım yazıdaki bulgularla da örtüşür. Görsel hatalar dikkat çeker, metin hataları ise sessizce ziyaretçi kaybettirir. Üstelik metin değişikliği genellikle geliştirici için dakikalar süren bir iştir; yani risk düşük, öğrenme hızı yüksektir.

İyi bir mikro metnin dört ölçütü nelerdir?

Yazdığım her mikro metni dört süzgeçten geçiririm. Bu süzgeçler bir kural kitabı değil, masada hızla karar vermenizi sağlayan bir kontrol aracıdır. Sırası da önemlidir: netlik her zaman kısalıktan önce gelir.

• Net: Okuyan kişi metni tek anlamla yorumlar. "Gönder" neyi gönderiyor, açıkça belli olmalı.
• Kısa: Anlamı bozmadan atabileceğiniz her kelimeyi atarsınız. Ancak kısalık uğruna bilgi kaybetmezsiniz.
• Yararlı: Metin, kullanıcının bir sonraki adımını kolaylaştırır. Bilgi vermeyen nezaket cümleleri yer kaplar.
• Tutarlı: Aynı eyleme her yerde aynı adı verirsiniz. Bir sayfada "Sepet", diğerinde "Alışveriş çantası" yazmazsınız.

Örneğin "Hata oluştu" metni kısa, ama net ve yararlı değil. "Kart numarası 16 haneli olmalı" ise dört ölçütün hepsini karşılar. Bu yüzden bir metni değerlendirirken önce "okuyan kişi şimdi ne yapacağını biliyor mu?" diye sorarım; cevap hayırsa kelime sayısının hiçbir önemi kalmaz.

Buton metnini nasıl yazmalısınız?

Buton metnini, tıklandığında olacak şeyin adı olarak yazarsınız. "Tamam", "Gönder", "İleri" gibi genel fiiller ziyaretçiye sonucu anlatmaz. Bunun yerine "Teklifimi al", "Randevuyu onayla" veya "Faturayı indir" gibi eylem ile nesneyi birlikte söyleyen ifadeler kullanırsınız.

Bu yazıda buton metninin ikna ve dönüşüm tarafına girmeyeceğim; renk, konum ve örnekleri CTA butonu örnekleri yazısında ayrıntılı anlattım. Burada mikro metin açısından üç kuralı öne çıkarıyorum:

1. Butonu, kendisinden önce okunan başlıkla tutarlı yazarsınız. Başlık "Ücretsiz keşif görüşmesi" diyorsa buton "Satın al" demez.
2. Geri alınamaz eylemleri açıkça adlandırırsınız: "Sil" yerine "Hesabı kalıcı olarak sil".
3. İki butonlu pencerelerde ikisini de fiille yazarsınız. "Evet / Hayır" yerine "Taslağı sil / Düzenlemeye dön" kararı kolaylaştırır.

Ayrıca butondaki metin ile sonraki sayfanın başlığı birbirini tutmalı. Kullanıcı "Fiyatları gör" butonuna basıp bir iletişim formuyla karşılaşırsa size olan güvenini kaybeder. Kısacası buton, küçük ama bağlayıcı bir sözdür.

Form etiketleri ve yardım metinleri nasıl olmalı?

Form etiketi, alanın ne istediğini tek bakışta söyler ve alan doldurulduktan sonra da görünür kalır. En yaygın hata, etiketi alanın içine gri yer tutucu metin olarak koymaktır. Kullanıcı yazmaya başladığında bu metin kaybolur, sonra neyi doldurduğunu hatırlamak için alanı silmek zorunda kalır.

W3C'nin erişilebilirlik standardı WCAG, kullanıcıdan veri isteyen içerikte etiket veya talimat bulunmasını bir başarı kriteri olarak tanımlar. Google'ın web.dev form rehberi de her alan için görünür bir etiket kullanmayı önerir. Bu nedenle etiketi her zaman alanın üstüne yazarım.

Yardım metnini ise yalnızca gerçekten gerektiğinde eklerim. Örneğin "Vergi numarası" alanının altına "Şahıs şirketiyseniz TC kimlik numaranızı yazabilirsiniz" notu, pek çok telefon görüşmesini önler. Zorunlu ve isteğe bağlı alanları da açıkça ayırırsınız. Randevu, teklif ve demo formlarının kurgusunu ise form tasarımı yazısında ayrıca ele aldım.

Hata mesajını nasıl yazmalısınız?

İyi bir hata mesajı üç şey yapar: neyin yanlış gittiğini söyler, nasıl düzeleceğini anlatır ve suçu kullanıcıya yüklemez. WCAG'nin hata tanımlama kriteri, otomatik olarak tespit edilen giriş hatasının metinle belirtilmesini ister. Yani yalnızca kırmızı çerçeve yetmez.

İngiltere hükümetinin GOV.UK tasarım sisteminde hata mesajları için açık bir rehber var; kısa, düz ve teknik jargondan uzak dil önerir. Ben kendi projelerimde şu sırayı izlerim:

1. Hatayı alanın hemen yanında gösterirsiniz, sayfanın tepesinde kaybolmasına izin vermezsiniz.
2. Sorunu somut yazarsınız: "Geçersiz giriş" yerine "E-posta adresinde @ işareti eksik".
3. Çözümü aynı cümlede verirsiniz: "Şifre en az 8 karakter olmalı".
4. "Hatalı işlem yaptınız" gibi suçlayıcı kalıpları kullanmazsınız.
5. Kullanıcının yazdığı veriyi silmezsiniz; düzeltmesi için yerinde bırakırsınız.

Sunucu tarafı hatalarda da aynı ilke geçerli. "Hata 500" kullanıcıya hiçbir şey anlatmaz. Bunun yerine "Şu an bağlantı kuramadık. Bilgileriniz kayıtlı, birkaç dakika sonra tekrar deneyebilirsiniz" gibi bir metin hem durumu açıklar hem de kaygıyı azaltır.

Boş durum ekranlarında ne yazmalısınız?

Boş durum, listede henüz hiçbir şey olmadığında görünen ekrandır: boş sepet, sonuç çıkmayan arama, henüz sipariş vermemiş bir müşteri paneli. Pek çok sitede burada yalnızca "Kayıt bulunamadı" yazar. Oysa bu ekran, kullanıcıya ne yapacağını göstermek için çok değerli bir fırsattır.

İyi bir boş durum metni iki parçadan oluşur: durumu açıklayan kısa bir cümle ve bir sonraki adımı sunan bir eylem. Örneğin boş sepette "Sepetiniz boş. En çok tercih edilen ürünlere göz atabilirsiniz" yazıp altına bir buton koyarsınız. Arama sonucunda ise yazım önerisi veya popüler kategoriler sunarsınız.

• İlk kullanım: Kullanıcının burada ne göreceğini ve nasıl başlayacağını anlatırsınız.
• Sonuçsuz arama: Aranan ifadeyi tekrar gösterir, alternatif yollar önerirsiniz.
• Temizlenmiş liste: Görevin bittiğini olumlu bir cümleyle bildirirsiniz.

Öte yandan boş durumu esprili yazma isteği sık gelir. Bir kez okunan bir espri hoş olabilir; ancak her gün aynı ekranı gören bir müşteri için çabucak yorucu hale gelir. Bu yüzden espriyi değil, yönlendirmeyi öne alırım.

Onay ve başarı mesajları neden bu kadar önemlidir?

Kullanıcı formu gönderdiğinde aklındaki ilk soru "gerçekten gitti mi?" olur. Belirsiz bir onay ekranı, aynı formun ikinci kez gönderilmesine veya telefonla teyit aramalarına yol açar. Bu nedenle onay mesajı, sürecin en az önemsenen ama en çok okunan metinlerinden biridir.

Güçlü bir onay mesajı şu soruları cevaplar: ne oldu, bundan sonra ne olacak ve ne zaman? "Teşekkürler" tek başına yetmez. Bunun yerine "Talebiniz bize ulaştı. İş günlerinde aynı gün içinde size e-posta ile dönüş yapıyoruz" gibi somut bir beklenti yazarsınız. Söz verdiğiniz süreyi de gerçekten tutabileceğiniz bir süre olarak seçersiniz.

Ayrıca onay sayfası, ölçüm açısından da önemlidir. Dönüşüm takibini çoğu zaman bu sayfaya bağlarım; dolayısıyla metni ile ölçümü birlikte planlarsınız. Hangi eylemin dönüşüm sayılacağını belirlemek için dönüşüm hedefi belirleme yazısına göz atabilirsiniz.

Yükleme ve bekleme anlarında kullanıcıya ne söylemelisiniz?

Bekleme anı, kullanıcının sistemin çalışıp çalışmadığından emin olmadığı andır. Dönen bir simge tek başına belirsizlik yaratır; özellikle ödeme veya dosya yükleme gibi hassas işlemlerde kullanıcı sayfayı yenileyebilir ya da butona tekrar basabilir. Kısa bir durum metni bu riski azaltır.

Örneğin ödeme adımında "Ödemeniz işleniyor, lütfen sayfayı kapatmayın" yazmak, çift çekim şikayetlerini önlemeye yardım eder. Dosya yüklemede ise yüzde veya adım bilgisi verirsiniz: "3 dosyadan 2'si yüklendi". Böylece kullanıcı ne kadar bekleyeceğini tahmin eder.

Bu metinler, site hızının yerini tutmaz. Yavaş bir sayfayı güzel bir bekleme cümlesiyle kurtaramazsınız; önce hızı düzeltirsiniz. Performansı nasıl ölçtüğümü Lighthouse ile site performans testi yazısında anlattım. Yine de kaçınılmaz beklemelerde doğru kelime, kullanıcının sabrını belirgin biçimde uzatır.

Mobilde UX writing nasıl değişir?

Mobilde ekran dar, parmak geniştir ve dikkat bölünmüştür. Bu üç koşul, mikro metni daha da kısaltmanızı gerektirir. Masaüstünde tek satıra sığan bir buton metni, telefonda iki satıra kırılıp okunmaz hale gelebilir. Bu yüzden her metni en dar ekran genişliğinde kontrol ederim.

Ayrıca mobilde klavye tipi de metnin bir parçasıdır. Telefon alanında sayısal klavye, e-posta alanında @ işaretli klavye açılmalı. Bunu HTML'deki giriş türü ve autocomplete özellikleriyle sağlarsınız; web.dev form rehberi de bu özellikleri kullanmayı önerir. Doğru klavye, kullanıcının yanlış veri girme ihtimalini azaltır ve dolayısıyla hata mesajı ihtiyacını da düşürür.

Mobil tasarım sırasını anlattığım mobil öncelikli tasarım yazısındaki ilke burada da geçerlidir: önce en küçük ekran için yazarsınız, sonra büyük ekrana genişletirsiniz. Tersini yaptığınızda kısaltma sırasında anlam kaybolur.

Erişilebilirlik ile UX writing nasıl birleşir?

Erişilebilir metin, ekran okuyucu kullanan, renk ayırt edemeyen veya dili ikinci dili olarak konuşan kişilerin de görevi tamamlayabilmesini sağlar. Bu grupların ihtiyacı, aslında herkesin ihtiyacının abartılmış halidir. Dolayısıyla erişilebilirlik için yaptığınız düzeltmeler tüm ziyaretçilere yarar.

• Hatayı yalnızca renkle göstermezsiniz; mutlaka metinle de yazarsınız.
• "Buraya tıklayın" gibi bağlamsız link metinleri yerine linkin nereye gittiğini söylersiniz.
• Simge butonlarına ekran okuyucunun okuyacağı bir ad verirsiniz.
• Kısaltma ve iç jargon kullanmazsınız; kullanıcının kendi kelimesini seçersiniz.

Örneğin bir kargo takip ekranında "GTS" gibi bir iç kısaltma, sizin ekibiniz için anlamlıdır ama müşteri için değildir. Ayrıca cümleleri kısa tutmak, okuma güçlüğü yaşayan kişiler kadar telefonda hızla göz gezdiren herkes için de işe yarar.

UX writing SEO'yu etkiler mi?

Doğrudan bir sıralama faktörü olarak değil; ancak dolaylı yoldan evet. Google, arama sonuçlarında kullanıcıya yararlı ve iyi bir deneyim sunan sayfaları öne çıkarmayı hedeflediğini sayfa deneyimi dokümanında açıkça yazar. Anlaşılır mikro metinler de bu deneyimin bir parçasıdır.

Pratikte şunu görüyorum: ziyaretçi aradığını bulamadığında ya da formda takıldığında sayfadan ayrılır. Bu davranış doğrudan bir sinyal olmasa bile, işletme açısından kaybedilmiş bir müşteridir. Ayrıca iç linklerdeki açıklayıcı metinler hem kullanıcıya hem de arama motoruna sayfanın konusunu anlatır.

SEO ile kullanıcı deneyiminin nerede çakışıp nerede ayrıldığını UX ve SEO dengesi yazısında ayrıntılı işledim. Kısacası UX writing, SEO çalışmanızın yerini tutmaz, ama SEO ile gelen trafiği kaybetmemenizi sağlar. Organik tarafı birlikte ele almak isterseniz SEO danışmanlığı sayfasına bakabilirsiniz.

Mikro metinleri nasıl test edersiniz?

Metni masada tartışmak yerine gerçek kullanıcıya gösterirsiniz. En basit yöntem, hedef kitleden beş kişiye ekranı gösterip "bu butona basınca ne olacağını düşünüyorsunuz?" diye sormaktır. Cevaplar sizin niyetinizden farklıysa metni değiştirirsiniz.

Trafiğiniz yeterliyse A/B testi de yapabilirsiniz; ancak mikro metinde farklar küçük olduğu için sonuca ulaşmak uzun sürebilir. Bu yüzden düşük trafikli kurumsal sitelerde önce nitel yöntemleri kullanırım: oturum kayıtları, destek taleplerinde tekrar eden sorular ve satış ekibinin telefonda en çok duyduğu cümleler.

Yazım tarafında ise iki basit araç işinizi kolaylaştırır. Metnin ne kadar kolay okunduğunu okunabilirlik analizi aracıyla, buton ve etiketlerin uzunluğunu kelime ve karakter sayacı ile kontrol edebilirsiniz. Özellikle mobil buton metinlerinde karakter sınırı koymak, tasarım kırılmalarını baştan önler.

Metin envanterini ve terim sözlüğünü nasıl hazırlarsınız?

Metin envanteri, sitenizdeki bütün mikro metinlerin tek bir tabloda toplandığı listedir. Sayfa, bileşen, mevcut metin, önerilen metin ve not sütunları yeterlidir. İlk kez çıkardığınızda aynı eylem için kaç farklı kelime kullandığınızı görüp şaşırabilirsiniz.

Envanteri çıkarırken şu sırayı izlerim:

1. Tüm formları, pencereleri ve uyarıları sayfa sayfa gezip ekran görüntüsü alırsınız.
2. Her metni tabloya yazar, bulunduğu yeri not edersiniz.
3. Aynı işi yapan farklı kelimeleri gruplar, tek bir terim seçersiniz.
4. Seçilen terimleri ekip içinde paylaşılan bir sözlüğe eklersiniz.
5. Geliştiriciyle birlikte metinleri tek bir dosyada toplar, sabit kodlamayı azaltırsınız.

Bu sözlük özellikle çok dilli sitelerde hayat kurtarır. Çeviri ekibi her terimin karşılığını tek yerden alır; böylece Türkçede "Teklif al" olan buton İngilizcede üç farklı ifadeye dönüşmez. Ayrıca yeni bir sayfa eklerken tasarımcı hangi kelimeyi kullanacağını tartışmaya gerek kalmadan bilir.

En sık gördüğüm UX writing hataları nelerdir?

Denetlediğim sitelerde aynı hatalar şaşırtıcı bir düzenlilikle tekrar ediyor. Aşağıdaki liste, sahadaki gözlemlerime dayanıyor; her sitede hepsini görmezsiniz ama birkaçını mutlaka bulursunuz.

• Geliştirme sırasında konmuş "Submit", "Lorem ipsum" veya "Button" gibi geçici metinlerin canlıda kalması.
• Türkçe sitede İngilizce sistem uyarılarının görünmesi.
• Etiket yerine yalnızca yer tutucu metin kullanılması.
• "Bir hata oluştu" gibi hiçbir çözüm sunmayan genel mesajlar.
• Formdan sonra hiçbir onay göstermeyen, sayfayı yalnızca yenileyen akışlar.
• Aynı eyleme farklı sayfalarda farklı adlar verilmesi.

Bu hataların ortak noktası, metnin tasarım sürecinin sonuna bırakılmasıdır. Bu nedenle ben yeni bir projede metni tasarımın başına alırım: kutuyu çizmeden önce içine ne yazacağımızı konuşuruz. Figma ile arayüz tasarımı yaparken de gerçek metinle çalışmak, sonradan çıkan taşma ve kırılma sorunlarını önler.

Çok adımlı formlarda ilerleme metni nasıl olmalı?

Uzun bir başvuru veya teklif formunu adımlara bölmek, kullanıcının yükünü hafifletir. Ancak bu yapı, iyi bir ilerleme metni olmadan kafa karıştırır. Kullanıcı kaç adım kaldığını bilmezse, ikinci ekranda formu yarıda bırakabilir.

İlerleme metnini iki bilgi üzerine kurarım: bulunduğunuz adım ve toplam adım. "Adım 2 / 4: İletişim bilgileri" gibi bir başlık hem konumu hem içeriği söyler. Ayrıca her adımın adı, o adımda istenen bilgiyi önceden haber verir; böylece kullanıcı hazırlıksız yakalanmaz.

• Adım adlarını isimle yazarsınız: "Proje bilgileri", "Bütçe", "İletişim".
• Geri dön butonunda kullanıcının girdiği verinin korunacağını belirtirsiniz.
• Son adımda özet ekranı gösterir, "Bilgileri düzenle" seçeneği sunarsınız.

Örneğin bütçe adımında "Kesin rakam gerekmez, yaklaşık bir aralık seçebilirsiniz" notu, pek çok ziyaretçinin çekincesini giderir. Sahada gördüğüm kadarıyla bütçe sorusu, formların en çok terk edilen alanlarından biridir; bu nedenle yanındaki metne özellikle özen gösteririm.

Ödeme adımında hangi mikro metinler kritiktir?

Ödeme ekranı, kullanıcının en çok tereddüt ettiği yerdir. Kart bilgisini yazmadan önce aklında birkaç soru vardır: toplam tutar ne, kargo ücreti eklenecek mi, iade mümkün mü, bilgilerim güvende mi? Bu soruların cevabını mikro metinle, tam ihtiyaç duyulan yerde verirsiniz.

Toplam tutarın hemen altına vergi ve kargo bilgisini yazarım. Kart alanının yanına, ödemenin hangi altyapı ile alındığını anlatan kısa bir not eklerim. Ayrıca ödeme butonunda tutarı da gösteririm: "1.250 TL öde" gibi bir metin, kullanıcıyı son anda sürprizle karşılaşma korkusundan kurtarır. Buradaki tutar yalnızca örnek bir değerdir.

Öte yandan ödeme hatalarında metin daha da önemli hale gelir. "İşlem başarısız" yerine "Bankanız işlemi onaylamadı. Kart limitinizi kontrol edebilir veya farklı bir kartla deneyebilirsiniz" yazmak, kullanıcıya yol gösterir. E-ticaret sitelerinde bu akışı uçtan uca ele almak isterseniz e-ticaret danışmanlığı kapsamında birlikte çalışabiliriz.

Türkçe mikro metinde nelere dikkat etmelisiniz?

Türkçe, ekleri ve uzun kelimeleriyle mikro metinde kendine özgü sorunlar çıkarır. İngilizce bir şablondan çevrilen buton metni, Türkçede çoğu zaman iki kat uzar. Bu yüzden tasarımı İngilizce örnek metinle değil, doğrudan Türkçe metinle kurarsınız.

İkinci konu hitap biçimidir. "Sen" ve "siz" arasında bir seçim yapar, sitenin tamamında o seçime sadık kalırsınız. Bir sayfada "Hesabını oluştur", diğerinde "Şifrenizi girin" yazmak, özensizlik izlenimi yaratır. Ayrıca büyük harf kullanımında da tutarlı olursunuz; buton metinlerini ya yalnızca ilk harf büyük ya da her kelimenin ilk harfi büyük yazarsınız.

Son olarak Türkçe karakterleri kontrol edersiniz. Bazı hazır temalar veya eklentiler "ı", "ş" ve "ğ" harflerini hatalı gösterir ya da büyük harfe çevirirken "i" harfini yanlış dönüştürür. Metinleri toplu olarak düzeltirken büyük küçük harf dönüştürücü aracı bu işi hızlandırır. Kısacası Türkçe metni, yayından önce mutlaka gerçek ekranda okursunuz.

İzin ve onay kutularında metni nasıl yazmalısınız?

Çerez bildirimi, bülten onayı veya kişisel veri izni gibi kutular, kullanıcının hukuki bir tercih yaptığı yerlerdir. Bu yüzden buradaki metin hem anlaşılır hem de dürüst olmak zorundadır. Kullanıcıyı yanıltan ya da reddetmeyi zorlaştıran ifadeler kısa vadede onay sayısını artırabilir; ancak güveni uzun vadede zedeler.

İlk kural, onay kutusunun ne için olduğunu tek cümlede söylemektir. "Kampanya e-postaları almak istiyorum" net bir tercihtir. Buna karşılık "Pazarlama iletişimi kapsamında tarafıma ticari elektronik ileti gönderilmesini kabul ediyorum" gibi bir cümle, okuyanı yorar. Hukuki metni tamamen kaldırmazsınız; onu bir linkle ayrı bir sayfaya taşırsınız.

• Kabul ve ret seçeneklerini eşit görünürlükte sunarsınız.
• Olumsuz soru kalıbı kullanmazsınız: "İstemiyorsanız işaretlemeyin" gibi.
• Zorunlu onay ile isteğe bağlı onayı ayrı kutularda tutarsınız.

Hukuki içeriğin kendisi için mutlaka bir hukukçuya danışırsınız; benim burada anlattığım yalnızca metnin okunabilirliğidir. Yine de sahadaki gözlemim şu: kullanıcı neyi onayladığını anladığında, sonradan gelen şikayet ve abonelikten çıkma talepleri de azalır.

UX writing işini kime bırakmalısınız?

Küçük bir işletmede ayrı bir UX yazarı istihdam etmek çoğu zaman gerçekçi değildir. Bu durumda sorumluluğu tasarımcı ile ürün veya pazarlama sorumlusu arasında paylaştırırsınız. Önemli olan, metnin sahipsiz kalmamasıdır; birinin "bu ekrandaki kelimeler benim sorumluluğumda" demesi gerekir.

Daha büyük projelerde ise metni tasarım ekibinin bir parçası olarak ele alırım. Çünkü mikro metin, bileşenin davranışıyla doğrudan bağlantılıdır: hata ne zaman çıkıyor, buton ne zaman pasifleşiyor, onay nerede görünüyor? Bu soruların cevabını bilmeden iyi metin yazamazsınız.

Eğer sitenizi sıfırdan kuruyor veya yeniliyorsanız, metni baştan sürece dahil eden bir web tasarım çalışması sonradan yapılan düzeltmelerden çok daha az maliyetlidir. Tasarım hizmeti almadan önce sormanız gerekenleri de UI/UX tasarım hizmeti öncesi kritik noktalar yazısında listeledim.

Yayından önce hangi kontrol listesini kullanmalısınız?

Her yeni sayfayı veya formu yayına almadan önce aşağıdaki soruları sırayla sorarım. Listeyi bilerek kısa tuttum, çünkü uzun kontrol listelerini ekipte kimse sonuna kadar okumuyor. Hepsine "evet" diyebiliyorsanız mikro metinleriniz sağlam bir zeminde demektir.

• Her buton, tıklandığında ne olacağını söylüyor mu?
• Form alanlarının, yazmaya başladıktan sonra da görünen bir etiketi var mı?
• Her hata mesajı sorunu ve çözümü birlikte veriyor mu?
• Boş ekranlar kullanıcıya bir sonraki adımı gösteriyor mu?
• Onay mesajı, bundan sonra ne olacağını ve ne zaman olacağını anlatıyor mu?
• Aynı eylem, sitenin her yerinde aynı adla mı geçiyor?
• Metinleri en dar mobil ekranda kırılmadan okuyabiliyor musunuz?

Son olarak bu listeyi tek seferlik bir iş olarak görmezsiniz. Yeni bir kampanya, yeni bir ödeme yöntemi veya yeni bir form eklendiğinde listeyi yeniden çalıştırırsınız. Böylece UX writing, sitenizin kalıcı bir kalite alışkanlığına dönüşür.

Bu işe nereden başlayacağınızı bilmiyorsanız, en çok ziyaret alan formunuzla başlamanızı öneririm. Önce o formdaki bütün metinleri envantere yazın, ardından yukarıdaki yedi soruyu tek tek sorun. Tek bir formu baştan sona düzelttiğinizde, aynı yöntemi sitenin geri kalanına uygulamak çok daha kolay hale gelir. Kısacası küçük başlayın, ama düzenli devam edin.