Ters Piramit: Web Metninde Ne Zaman İşe Yarar, Ne Zaman Yaramaz

Ters piramit, sonucu başa alıp destekleyici bilgiyi aşağı bırakan bir kurgu. Web metinlerinde neredeyse refleks haline geldi, ama sık verilen gerekçesi aslında matbaadan kalma bir alışkanlık. Yapının hangi metinde işe yaradığı, hangisinde okuru kaçırdığı ve şablonun onu nerede sessizce bozduğu ayrı ayrı konular.

Gazeteden kalan gerekçe web'de geçmiyor

Ters piramidin klasik savunması şu: metni sondan kesebilirsiniz, anlam bozulmaz. Bu, sayfa yerleşiminin fiziksel olarak sınırlı olduğu bir dünyada gerçek bir kazançtı. Editör sütuna sığmayan son paragrafları atardı, haber yine ayakta kalırdı.

Web sayfasında kesilecek bir alt sınır yok. Yazı istediği kadar uzayabilir. Dolayısıyla "aşağıdan feragat edebilirsiniz" argümanı web için bir avantaj değil, sadece devralınmış bir cümle. Yapıyı ayakta tutan tek gerçek sebep okuma davranışı: insanlar sayfayı okumuyor, tarıyor, ve ilk ekranda cevabı göremezse geri dönüyor.

Yapı iyi kurulur, şablon bozar

Ters piramidi doğru uygulamış bir yazının, listeleme ekranında hâlâ bir işe yaramadığını görebilirsiniz. Sebep genelde metinde değil, o metnin nereden kesildiğinde.

Çoğu içerik yönetim sistemi kart ve arama sonucu özetini otomatik üretir: ilk paragrafın ilk 150 ila 200 karakteri alınır, gerisi üç noktayla kapatılır. Bu davranışla ters piramit iyi anlaşır, çünkü ikisi de en değerli cümlenin başta olmasını varsayar. Uyuşmadığı yer, yazarın ilk paragrafa ısınma cümlesi koymasıdır.

Bir yardım merkezinde arama sonuçlarının açıklama satırını ilk paragraftan çektiğimiz için, "Bu yazıda X konusunu ele alacağız" diye başlayan otuz kadar döküman sonuç listesinde birbirinin tıpatıp aynısı görünüyordu.

Kontrol etmesi kolay: kendi listeleme sayfanızı açın, kartların ilk satırlarını okuyun. Birbirinin kopyası gibi duruyorlarsa sorun tasarımda değil, yazının ilk cümlesinde.

Aynı özeti üç kere vermeyin

Ters piramit özyinelemeli uygulanınca kendi kendini yiyor. Sayfa başında özet kutusu, her h2 zaten sonucu söyleyen bir başlık, altında yine sonucu tekrarlayan ilk cümle. Okur aynı bilgiyle üç kez karşılaşıyor ve metnin ilerlemediğini hissediyor.

Pratikte biri fazla. Uzun ve referans amaçlı bir metinse baştaki özet kutusu kalsın, bölüm girişleri doğrudan detaya girsin. Kısa bir yazıda özet kutusuna gerek yok, zaten giriş paragrafı o işi yapıyor.

Nerede bırakmak gerekir

Yardım dökümanı, hata mesajı açıklaması, duyuru, ürün sayfasının üst bölümü: buralarda tartışma yok, cevap ilk cümlede olacak. Kullanıcı zaten bir sorunla geldi, hikâye dinlemeye niyeti yok.

Buna karşılık bir vaka çalışması ya da bir tasarım kararının gerekçesini anlatan yazı, sonucu başa koyduğunuzda değerini kaybeder. "Menüyü değiştirdik, dönüşüm arttı" cümlesini ilk satırda okuyan kişi gerisini okumaz, çünkü aradığı şey sonuç değil, o sonuca hangi yoldan gidildiği. Böyle metinlerde kronolojik anlatı ters piramitten daha iyi çalışır. Karar kuralı basit: okur cevabı mı arıyor, akıl yürütmeyi mi? Birincisinde ters piramit, ikincisinde değil.

Uygulama

Yazıyı bitirdikten sonra ilk paragrafı silin ve ikinciden başlayıp okuyun. Çoğu zaman metin hiçbir şey kaybetmez, hatta hızlanır. Kaybediyorsa ilk paragrafınız gerçekten iş yapıyordur, geri koyun.

Başlıklar için de aynısı geçerli. "Yöntem" değil, o yöntemin ne yaptığını söyleyen bir başlık yazın. Kullanıcı içindekiler listesini okumuyor, tarıyor, ve tek gördüğü şey başlıklar oluyor.