E-posta Konu Satırı: Gelen Kutusu Bir Liste Arayüzüdür

Gelen kutusu bir mesaj yığını değil, sıralanmış bir liste arayüzü. Kullanıcı o listeyi satır satır tarar ve her satırda önüne üç parça gelir: gönderen, konu, önizleme. Konu satırını yazarken metin yazmıyorsun, bu arayüzün orta sütununu tasarlıyorsun. Fark önemsiz görünüyor ama kararların çoğunu değiştiriyor.

Konu satırı bir başlık değil, bir etiket

Listedeki bir satır okunmaz, taranır. Kullanıcı gözünü aşağı kaydırırken her satıra bir saniyeden az ayırır ve iki şeye bakar: bunu kim gönderdi, açarsam ne bulurum. İlk sorunun cevabı gönderen sütununda zaten var. Geriye konu sütununun tek işi kalıyor.

Buradan bakınca "Haziran Bülteni" gibi başlıkların neden çalışmadığı daha net görünüyor. O ifade bir dosya adı, bir vaat değil. "Haziran'da fiyat listesi değişti" ise açma kararını verebileceğin bir bilgi taşır. Konu satırının okuyucuya borcu, iletiyi açmanın karşılığında ne alacağını söylemektir.

Kesilme noktası sabit bir sayı değil

"Konu satırı 40 karakteri geçmesin" tavsiyesi her yerde dolaşıyor. Peki o 40 nereden geliyor? Belli bir istemcinin, belli bir pencere genişliğinde, belli bir yazı tipi boyutunda gösterdiği yerden. Kullanıcının ekran genişliği, arayüz yoğunluk ayarı, yazı tipi ölçeklemesi ve önizleme panelinin açık olup olmaması bu sayıyı sürekli oynatır. Sabit bir eşiğe güvenmek, tek bir cihazda test edip bitmiş saymakla aynı şey.

Daha dayanıklı bir kural şu: ilk otuz karakterde tek başına ayakta duran bir anlam kur. Devamı kesilirse bir şey kaybetmezsin, kesilmezse üstüne bonus olur. Yani başlığı kısaltmaya değil, önemli olanı öne almaya çalış.

Ya söylenecek şey gerçekten uzunsa? O zaman kalanı ön izleme metnine (preheader) taşı. Çoğu istemci konudan sonra iletinin ilk satırını gri renkte gösterir ve orası da senin kontrolünde. İki alanı birlikte tasarlarsan tek bir cümleyi sıkıştırmak zorunda kalmazsın.

Test etmenin en ucuz yolu da burada: kampanyayı kendi adresine gönder, telefonu eline al ve iletiyi açmadan listeye bak. Açtığın anda test bitmiş olur, çünkü kullanıcının gördüğü ekran o değil.

Gönderen sütununu konuda tekrarlamak

"Acme Bülten: Acme'den yenilikler" tarzı başlıklar aynı bilgiyi iki sütunda gösterir. Bu bir üslup meselesi değil, bilgi mimarisi hatası. Marka adı zaten gönderen alanında duruyor, konuda tekrarlandığında ekranda görünen sınırlı alanın önemli bir kısmı hiçbir yeni şey söylemeden yanıyor. Kurumsal kimlik kaygısı varsa çözüm başlıkta değil: gönderen adını doğru yapılandırmak ve sabit bir adresten göndermek işi görür.

İsimle hitabın sınırı

Konu satırında alıcının adını kullanmak uzun süredir standart tavsiye. Ama bu tavsiye, veri tabanındaki ad alanının temiz olduğunu varsayıyor. Gerçekte o alanda ne var? Bazı kayıtlarda tümü büyük harfle yazılmış bir ad, bazılarında soyadıyla birlikte girilmiş bir metin, bazılarında boşluk. Kişiselleştirme, listenin en özensiz kaydı kadar iyi çalışır.

Kişiselleştirme kullanacaksan yedek değeri şablonu yazmadan önce belirle ve boş alanla bir test gönderimi yap. Yedek değer "Değerli Müşterimiz" olmak zorunda değil; ismin hiç geçmediği, kendi başına anlamlı ikinci bir başlık çoğu zaman daha iyi durur.

Emoji, sembol ve büyük harf

Emoji kullanımı dikkat çekme numarası olarak sunuluyor ama listede yarattığı etki göründüğü kadar masum değil. Ekran okuyucu emojiyi atlamaz, Unicode adını seslendirir. Konu satırının başındaki bir ateş simgesi, ekran okuyucu kullanan biri için başlıktan önce duyulan fazladan bir kelimedir. Aynı simge farklı işletim sistemlerinde farklı çizilir, bazı kurumsal istemcilerde hiç çizilmez ve boş kutu olarak kalır.

Konu satırındaki emojiyle ön izleme metnini karşılaştırırsam ön izleme metnini açık ara daha güvenilir bulurum: aynı ekran alanında çok daha fazla bilgi taşır, ekran okuyucuda anlamlı okunur ve istemciler arasında sürpriz çıkarmaz. Dikkat çekmek istiyorsan ikinci satırı doldur, birinci satıra simge koyma.

Tümü büyük harfle yazmak da benzer bir bedelle geliyor. Büyük harfli metinde kelimelerin siluet farkı kaybolur, tarama yavaşlar; üstelik bazı ekran okuyucular tümü büyük yazılmış kelimeleri kısaltma sanıp harf harf okur. Listede hızlı taranmak isteyen bir metin için ikisi de ters yönde çalışıyor.

Ölçmenin sınırını bilmek

Konu satırlarını A/B test etmek doğru tavsiye ama uygulamanın iki ciddi sınırı var. Birincisi örneklem: açılma oranı bir oran ve iki oran arasındaki küçük farklar küçük listelerde gürültüden ayrılmaz. Birkaç yüz kişilik bir listede yüzde 20 ile yüzde 23 arasındaki farkı ölçtüğünü sanıyorsan büyük ihtimalle rastgeleliği ölçüyorsun; o boyutta ancak kaba farklar görünür.

İkincisi ölçümün kendisi. Açılma oranı, iletiye gömülen görünmez bir görselin yüklenmesiyle sayılır. Görselleri engelleyen istemciler bu sayıyı düşürür, gizlilik korumaları için iletiyi kullanıcı adına önden indiren sistemler ise açılmamış iletileri açılmış gibi işaretler. Apple'ın posta gizliliği korumasından sonra açılma oranı, karşılaştırma yapılabilecek bir metrik olmaktan büyük ölçüde çıktı.

Bu yüzden konu satırı kararlarını tıklama ve yanıt üzerinden değerlendirmek daha sağlam. İkisi de kullanıcının gerçekten yaptığı bir eylemi kaydeder, arka planda bir görselin yüklenip yüklenmediğini değil. Konu satırı açtırmayı hedefler ama başarısı, açtıktan sonra sözünü tutup tutmadığıyla ölçülür.