Bu yazıda

Web site yaptırmak, tasarım seçip yayına alınmasını beklemekten daha fazla karar içerir. Metinler, ürün bilgileri, formlar ve hesap erişimleri farklı kişilerin katkısını gerektirebilir. Bunlardan biri geciktiğinde güzel hazırlanmış ekranlar tek başına projeyi tamamlamaz. Bu yazı, başlangıç görüşmesinden teslim kontrolüne kadar kurumun ve üretim ekibinin üstleneceği işleri görünür hale getirir. Böylece neyin hazır olduğu, neyin beklendiği ve hangi koşullarda yayına çıkılacağı ortak bir listeden takip edilebilir.

Kısa cevap

Web site yaptırırken amaç, sayfa türleri, içerik sorumluları ve gerekli entegrasyonlar tanımlanmalıdır. Tasarım onayı, geliştirme, içerik yerleştirme, test ve hesap teslimi ayrı aşamalardır. Tamamlanmış proje yalnızca açılan sayfalardan oluşmaz; kullanıcı görevlerinin çalışması, bilgilerin doğru olması ve kurumun yayın sonrası yönetim için gerekli erişimi alması gerekir. Kabul koşullarını üretim başlamadan belirlemek yararlıdır.

Sayfa listesini hazırlık tablosuna dönüştürün

Her sayfanın hangi soruyu yanıtladığını yazın. Hizmet sayfasında kapsam, çalışma biçimi ve teklif adımı bulunacaksa bunların metnini kimin hazırlayacağını belirleyin. Mevcut broşürleri doğrudan aktarmak yerine ekran üzerinde okunacak bilgi sırasını değerlendirin. İçerik tablosunda kaynak dosya, sorumlu kişi, onay durumu ve eksik görseller yer alsın. Tasarım onayı bütün iddiaların onaylandığı anlamına gelmez. Ürün ölçüleri, hizmet koşulları ve ekip bilgileri kurum tarafından kontrol edilmelidir. Eski sitenin korunacak bilgilerini ve artık geçerli olmayan metinleri de aynı tabloda işaretleyin.

Entegrasyonları görevleriyle anlatın

Teklife form veya rezervasyon yazmak yeterince açık olmayabilir. Formun hangi adrese gideceği, zorunlu alanlar ve gönderim sonrası mesaj tanımlanmalıdır. Harici sisteme bağlanılacaksa hesap erişimi, test ortamı ve sağlayıcıyla görüşme sorumlusu belirlenmelidir. Varsayımsal bir eğitim işletmesinde kullanıcı program seçip başvuru talebi gönderiyor olsun. Kurum sonrasında uygunluk görüşmesi yapıyorsa bu akış otomatik kontenjan ayıran bir kayıt sistemiyle aynı değildir. İkisini ayırmak geliştirme kapsamını ve ziyaretçiye verilecek sözü netleştirir. Erişilemeyen harici hizmetlerin bağlantısını kimin sağlayacağını da başlangıçta açıklayın.

Tasarımı gerçek içerikle değerlendirin

Kısa örnek başlıklarla güzel görünen ekran, uzun hizmet adları geldiğinde değişebilir. En uzun başlığı, az görselli sayfayı ve yoğun bilgi içeren örneği onaydan önce görün. Mobil menünün, alt başlıkların ve iletişim adımlarının nasıl çalıştığını değerlendirin. Geri bildirimleri tek sorumlu üzerinden toplayın. Beğeni kadar hangi kullanıcı görevinin zorlaştığını açıklamak da değerlidir. Fiyat kapsamı bulunamıyor veya formun sonraki adımı anlaşılmıyorsa düzeltmenin amacı somutlaşır. Yeni özellik isteğini mevcut kapsamın düzeltmesinden ayrı takip edin; ikisi aynı üretim ihtiyacını ifade etmeyebilir.

Kabul kontrolünü senaryolarla yapın

Test listesi yalnızca sayfaların açılmasını içermemelidir. Hizmet seçip talep gönderme, dil değiştirerek aynı içeriğe ulaşma ve mobil telefonda arama bağlantısını kullanma gibi görevler yazın. Her senaryoda beklenen sonucu ve kontrol edecek kişiyi belirleyin. W3C form rehberi anlaşılır etiketler, yönergeler ve hata bildirimlerini açıklar. Örnek gönderimlerde zorunlu alan boş bırakıldığında mesajın anlaşılmasını kontrol edin. Başarılı gönderim de fark edilmelidir. Birkaç örneğin denenmesi bütün erişilebilirlik gereksinimlerinin doğrulandığı anlamına gelmez; kontrol kapsamını açık tutun ve kalan kontrollerin sorumlusunu belirleyin.

Yayın ile teslimi ayrı düşünün

Yayına geçişte alan adı yönetimi, yönlendirmeler ve eski içeriklerin durumu konuşulmalıdır. Mevcut site yenileniyorsa önemli eski adresleri listeleyin; taşınacak içerikleri kararlaştırın. Yayın sonrasında ilk gerçek taleplerin doğru kişiye ulaştığını kontrol edin. Teslimde hesap yetkileri, içerik düzenleme yöntemi ve destek kanalı paylaşılmalıdır. Kurumdan bir kişinin örnek metin güncellemesi yapması, yalnızca anlatımı dinlemekten daha açıklayıcıdır. Yeni geliştirme taleplerinin nasıl değerlendirileceğini bilmek proje kapanışındaki belirsizliği azaltır. Teslimi bir dosya gönderimi kadar, kurumun günlük kullanımına hazırlık olarak değerlendirin.

Akılda kalacaklar

  • Her sayfanın içeriğine hazırlayan ve onaylayan atayın.
  • Entegrasyonları gerçek kullanıcı görevleriyle tanımlayın.
  • Kabul kararına görev testlerini ve erişim teslimini dahil edin.

Sık sorulan sorular

İçerikler hazır olmadan başlanabilir mi?

Planlama başlayabilir. Ancak metin ve görselleri kimin hazırlayacağı belirlenmelidir. Eksiklerin takvime etkisini konuşun; örnek metinlerin kendiliğinden son içerik olacağını varsaymayın. Onay sorumluluğunu başlangıçta açık tutun.

Bütün sayfaları kontrol etmeli miyiz?

Kritik bilgiler kurum tarafından gözden geçirilmelidir. Farklı sayfa türleri ve temel görevler test edilmelidir. Çok sayıda benzer ürün varsa içerik doğrulama yöntemini ayrıca planlayın; şablon kontrolü bütün ürünleri doğrulamaz.

Teslimde hangi erişimler istenir?

Yapıya göre yayın platformu, alan adı, içerik yönetimi ve bağlı hizmetlerin yetkileri gerekebilir. Kurumun yapacağı işlemlere uygun erişim verilmelidir. Hesap sahibi ile teknik destek rolünü ayırın.

Kaynaklar ve ek okuma