Web Sitesi İçeriğini Yazmadan Önce Sayfa Amacı Özeti Nasıl Hazırlanır?

Yazı görevi vermeden önce tek sayfalık bir karar kaydını tamamlayın: hedef kitle, kullanıcı sorusu, sayfanın rolü, ana mesaj, gerekli kanıt, istenen sonuç, format, içerik sahibi ve gözden geçirme tarihi. Ardından talebi mevcut site ve kullanıcı yolculuğuyla karşılaştırın. Bu çalışma otomatik olarak yeni bir sayfaya çıkmaz; doğru karar mevcut içeriği güncellemek, parçaları birleştirmek, eski adresi yönlendirmek, talebi reddetmek veya gerçekten yeni bir sayfa oluşturmak olabilir.

Metne başlamadan önce sayfanın amacı neden kararlaştırılmalı?

Amaç önce kararlaştırılmalıdır; çünkü talep edilen başlık veya format yalnızca önerilen bir çözümdür, yeni bir sayfanın gerekli olduğunun kanıtı değildir. Bu karar alınmadan başlayan çalışmada yazar hedef kitleyi, kullanıcı sorusunu, kanıt düzeyini, beklenen sonucu ve mevcut içerikle ilişkiyi kendi başına yorumlamak zorunda kalır. Ortaya konu hakkında doğru cümleler çıksa bile sayfanın yolculuktaki işi belirsiz kalabilir ve başka bir içerikle aynı ihtiyaba cevap verme riski doğabilir.

GOV.UK kullanıcı ihtiyacı rehberi, yayımlanan içeriğin geçerli bir ihtiyaca dayanmasını; muhtemel kullanıcıların, yapmak istedikleri işin, destekleyici kanıtların ve kabul ölçütlerinin kaydedilmesini ister. Buradaki dokuz alan ise hiçbir kaynağın resmî standardı değildir. Kullanıcı ihtiyacı, üretim öncesi planlama ve yaşam döngüsü yönetişimini uygulanabilir bir editoryal kayıtta buluşturan bir sentezdir. Ekip, daha sonra taslağı kişisel beğeniyle değil üzerinde anlaşılmış amaç ve kabul koşullarıyla değerlendirebilir.

Yeni bir sayfa onaylanmadan önce ekip neyi kontrol etmeli?

Ekip önce mevcut siteyi ve ilgili kullanıcı yolculuğunu taramalıdır. Aynı soruyu yanıtlayan sayfaları, parçalı rehberleri, araçları, işlem adımlarını ve destek gibi diğer kanalları birlikte inceleyin. GOV.UK rehberleri yeni içerikten önce güncellenebilecek sayfaların, tekrarların ve eksik görev bilgilerinin belirlenmesini önerir. Benzer sayfalar hangi kaynağın yetkili olduğunu belirsizleştirebilir; ancak bu, aynı konuya dokunan her içeriğin düşünmeden tek sayfaya sıkıştırılması gerektiği anlamına gelmez.

• Güncelle: Mevcut sayfa ihtiyabın ve rolün zaten sahibiyse onu geliştirin.
• Birleştir: Dağınık parçalar aynı yanıtı bölüyor veya birbiriyle yarışıyorsa tek bir yetkili yapı kurun.
• Yönlendir: Eski sayfa artık geçerli değilse kullanıcıyı yetkili kaynağa götürün ve uygun olduğunda eski içeriği kaldırın.
• Reddet: İhtiyaç, kanıt veya farklı bir rol gösterilemiyorsa yeni sayfa talebini üretime almayın.
• Oluştur: İhtiyaç, rol, kanıt, sonuç, format, sahiplik ve inceleme planı birlikte tutarlıysa yeni sayfayı onaylayın.

Bu kontrol yalnızca URL envanteri değildir. Kullanıcının soruyu yolculuğun hangi noktasında sorduğunu ve doğru yanıtın nerede bulunması gerektiğini değerlendirin. Bir işlem sırasında kısa bir hatırlatma yararlı olabilir; bu sınırlı tekrar, iki ayrı sayfanın aynı konuda yetkili kaynak gibi davranmasıyla aynı değildir. Sorunu bir araç değişikliği, işlem iyileştirmesi veya web dışı kanal daha iyi çözüyorsa karar kaydı bunu açıkça söylemelidir.

Yazardan bir sayfa üretmesini istemeyin; önce kurumdan o sayfanın görevini gerekçelendirmesini isteyin.

Hedef kitle ve kullanıcı sorusu nasıl tanımlanır?

Hedef kitleyi, sayfanın görevini değiştiren durum veya bilgi düzeyiyle; kullanıcı sorusunu da bu kitlenin tanıyacağı, kanıtlanmış bir görev cümlesiyle tanımlayın. “Tüm müşteriler” gibi sınırsız bir etiket karar vermeye yardımcı olmaz. Bunun yerine “desteklenen bir entegrasyonu ilk kez yapılandırmaya hazırlanan müşteri yöneticileri” ifadesi, hangi ön bilgilerin gerekli olduğunu ve hangi ayrıntıların başka bir sayfaya bırakılacağını belirginleştirir. Tek bir merkezî soru, aynı ihtiyaba bağlı yakın alt soruları içerebilir.

Kanıt; analitik verilerinden, çağrı merkezi veya destek kayıtlarından, önceki kullanıcı araştırmalarından ve ilgili dış verilerden gelebilir. Her kaynağın yeterliliği soruya göre değerlendirilmelidir: yüksek trafik insanların sayfaya neden geldiğini ya da ihtiyaçlarının karşılandığını tek başına göstermez. Paydaşın sevdiği bir başlık, video talebi veya ürün ekibinin yayın isteği de kullanıcı ihtiyacı kanıtı değildir. Varsayımı, karar verilmeden önce eldeki farklı sinyallerle sınayın.

• Kitle tanımında görevi etkileyen durum, sorumluluk veya bilgi düzeyini kullanın.
• Merkezî soruyu kullanıcının söyleyebileceği açık bir görev ya da soru şeklinde yazın.
• Kanıtın neyi gösterdiğini ve neyi göstermediğini kayda ekleyin.
• Yakın alt soruları yalnızca aynı tutarlı ihtiyabı birlikte çözüyorlarsa kapsamda tutun.

Sayfanın rolü, ana mesaj ve gerekli kanıt nasıl birlikte çalışır?

Bu üç alan birlikte sayfanın yolculuktaki özgün işini, kullanıcının çıkaracağı temel sonucu ve bu sonucu destekleyecek ispatı tanımlar. Önce rolü bir içerik türü olarak değil, yapılacak iş olarak yazın: Sayfa belirsizliği mi azaltacak, seçenekleri mi karşılaştıracak, bir işlem öncesi koşulları mı açıklayacak? Ardından mevcut bir sayfanın, aracın, işlem adımının veya başka bir kanalın bu işi neden daha iyi yapamadığını belirtin.

Ana mesaj, hedef kitlenin sayfadan aklında tutması gereken temel sonuçtur ve görevle ilgili özü destekleyici ayrıntılardan önce getirir. Gerekli kanıt alanı ise iki ayrı soruyu kapsar: Sayfaya ihtiyaç olduğunu hangi veriler gösteriyor ve yayımlanacak iddialar hangi güncel kaynak, kayıt, gösterim ya da uzman doğrulamasıyla desteklenecek? İhtiyaç kanıtı, ürün özelliğinin doğru çalıştığını; ürün belgesi de insanların o açıklamaya ihtiyaç duyduğunu otomatik olarak kanıtlamaz.

Örneğin bir destek açıklayıcısı, müşteri yöneticisinin yapılandırma aracına girmeden önce erişim, uyumluluk ve gerekli kayıtları doğrulamasına yardım edebilir. Yapılandırmayı yine araç yürütür; açıklayıcı sayfa işlemi taklit etmez. Taslak hazırlandığında başlık, ana sayfa başlığı ve açılış bölümü özetteki mesajla karşılaştırılmalıdır. WCAG 2.4.2, sayfa başlığının konuyu veya amacı açıklamasını ister; ancak yalnızca bu kontrol, sayfanın bütünüyle erişilebilir olduğunu göstermez.

İstenen sonuç içerik formatını nasıl belirlemeli?

İstenen sonuç, kullanıcının sayfadan sonra neyi anlayabileceğini, bulabileceğini, karşılaştırabileceğini, kararlaştırabileceğini, yapabileceğini veya hangi adıma ulaşabileceğini belirtmelidir. Bu sonuç içerik için pratik bir kabul koşuluna dönüştürülebilir; mutlaka form gönderimi, satış fırsatı ya da satın alma değildir. “Gerekli koşulları kontrol edip yapılandırmaya hazır olup olmadığına karar verebilir” ifadesi, belirsiz bir “daha fazla bilgi edinir” hedefinden daha kullanışlı bir üretim ölçütüdür.

Format ancak ihtiyaç, rol ve yolculuk netleştikten sonra seçilmelidir. Kısa rehber, karşılaştırma, referans, açıklayıcı içerik, işlem adımı, araç veya video farklı işler yapar; kaynaklar kurumsal siteler için evrensel bir format sınıflandırması sunmaz. Ekip bu nedenle “paydaş video istedi” diye başlamamalı, kullanıcının sonucu hangi biçimde ve hangi noktada en güvenilir biçimde elde edeceğini sormalıdır. Daha iyi çözüm bir araç ya da işlem değişikliyse yeni sayfa üretmemek de geçerli karardır.

• Önce kullanıcı sonucunu açık bir fiille yazın.
• Sonucun ticari dönüşüm olması gerektiğini varsaymayın.
• Formatı yolculuktaki işe, bilgi yoğunluğuna ve kanıtın nasıl sunulacağına göre gerekçelendirin.
• Bir başka kanal işi daha iyi yapıyorsa bunu karar kaydına geçirin.

Sayfanın sahibi kim olmalı ve ne zaman gözden geçirilmeli?

Sayfanın doğruluğu ve bakımından hesap verecek tek bir kişi ya da ekip açıkça adlandırılmalı; katkı, uzman incelemesi ve onay sorumlulukları ayrıca kaydedilmelidir. İçerik sahibi konu uzmanından bilgi toplar, kararların izlenmesini sağlar ve bakımın sahipsiz kalmasını önler. Fakat erişilebilirlik uzmanının, hukuk veya mevzuat inceleyicisinin, teknik uygulayıcının ya da ürün uzmanının mesleki görevlerini kendi üzerine almaz. Bir kişinin her kontrolü yapması değil, sorumlulukların görünür ve koordine edilmiş olması gerekir.

Gözden geçirme tarihi bakım niyetini takvime bağlar; mümkünse tarihin yanında tetikleyici de yazılmalıdır. Ürün sürümü, politika değişikliği, veri kaynağının yenilenmesi, hizmet sürecindeki değişiklik veya doğruluğa ilişkin yeni kanıt uygun tetikleyiciler olabilir. Bütün sayfalara üç aylık ya da yıllık tek bir aralık dayatmayın. Zamanlamayı içeriğin değişkenliği, yanlış kalma riski, bilinen olaylar ve kuruluşun yayın taahhütleriyle belirleyin. Kontrol noktası bakım kararını mümkün kılar, bakımın gerçekleşeceğini garanti etmez.

• İçerik sahibi: doğruluk, kayıt ve bakım kararlarından hesap verir.
• Katkıda bulunanlar: gerekli bilgi ve belgeleri sağlar.
• İnceleyenler: konu, erişilebilirlik, teknik veya düzenlenmiş alan uzmanlığını uygular.
• Onaylayanlar: kuruluşun yayın yetkisine göre nihai kararı verir.
• Gözden geçirme kaydı: tarih, tetikleyici ve sonraki kararı görünür kılar.

Tamamlanmış dokuz alanlı bir özet nasıl görünür?

Tamamlanmış bir özet, dokuz alanın birbirini doğruladığı kısa bir karar kaydıdır; aşağıdaki varsayımsal B2B destek örneğinde ihtiyaç, sayfa rolü, kanıt ve bakım planı aynı öneriyi destekler. Bu örnek trafik, tamamlama oranı, dönüşüm veya maliyet tasarrufu iddiasında bulunmaz. Gerçek ekip, örnekteki varsayımları kendi ürün belgeleri, destek kayıtları, kullanıcı kanıtları ve sorumlu uzmanlarının doğrulamasıyla değiştirmelidir.

• Hedef kitle: Desteklenen bir entegrasyonu yapılandırmaya hazırlanan müşteri yöneticileri.
• Kullanıcı sorusu: “Yapılandırmaya başlamadan önce neleri doğrulamam gerekiyor?”
• Sayfanın rolü: Yapılandırma aracından önce kullanılan, ön koşulları açıklayan bir destek sayfası.
• Ana mesaj: Başlamadan önce erişimi, uyumluluğu ve gerekli kayıtları doğrulayın.
• Gerekli kanıt: Güncel ürün belgeleri, soruyu gösteren destek kayıtları ve sorumlu ürün uzmanının doğrulaması.
• İstenen sonuç: Kuruluşun hazır olup olmadığına karar vermek ve doğru araca ya da destek yoluna ilerlemek.
• Format: Kısa açıklama ve ön koşul kontrol listesi.
• İçerik sahibi: Adlandırılmış ürün ve erişilebilirlik inceleyicileriyle birlikte ürün destek içerik ekibi.
• Gözden geçirme tarihi: Belgelenmiş ürün sürümü tetikleyicisine bağlı bir sonraki planlı kontrol noktası.

Onay toplantısında her alanı ayrı ayrı doldurmak yetmez; aralarındaki mantığı sınayın. Hedef kitle ve soru için kanıt gösterilebiliyor mu? Güncelleme, birleştirme, yönlendirme, reddetme veya oluşturma kararı gerekçeli mi? Sayfanın rolü diğer kanallardan ayrılıyor mu? Ana mesajın dayanağı, anlamlı kullanıcı sonucu, format gerekçesi, hesap verebilir sahibi ve tarihli inceleme tetikleyicisi belli mi? Maddi bir yanıt hâlâ desteklenmiyor veya diğer alanlarla çelişiyorsa talebi araştırma ve düzeltme için geri gönderin.

Yazı görevini ancak ihtiyaç, seçilen karar, dokuz alan ve yaşam döngüsü taahhüdü birlikte tutarlı olduğunda onaylayın. Önerilen sayfa erişilebilirlik, hukuk, mevzuat, teknik uygulama, veri veya konu uzmanlığı gerektiren iddialar içeriyorsa ilgili yetkin uzmanları üretim ve onay sürecine katın. Hesap verebilir içerik sahibi bu çalışmayı koordine eder; uzman değerlendirmesinin yerine geçmez. Böylece özet bir anahtar kelime listesi ya da küçük bir taslak değil, üretimden önce alınmış izlenebilir bir kurumsal karar olur.