Yeni bir ana sayfa, yanlış anlatılmış hizmeti veya kaybolan başvuruyu kendiliğinden düzeltmez. Yenileme brifinde yalnız beğendiğiniz siteler varsa, ekip görünümü tahmin eder; çözülmesi gereken işi değil. Önce mevcut sitenin görevlerini, gözlenen sorunlarını ve korunması gereken güçlü yanlarını bir sayfada toplayın.
1. Yenileme gerekçesini gözlenebilir bir soruna çevirin
“Site eski görünüyor” bir başlangıç olabilir; ancak teslimi değerlendirmek için yeterli değildir. Hangi sayfanın, hangi ziyaretçiye, hangi işi yaptırması gerektiğini yazın. Otel yöneticisinin prodüksiyon kapsamını anlaması ile bir ürün müşterisinin ölçü karşılaştırması aynı görev değildir.
Destek sorularını, ekip gözlemlerini ve varsa ölçüm verilerini yan yana koyun. “Fiyat kapsamı anlaşılmıyor” iddiasını gelen sorularla, “form kullanılamıyor” iddiasını tekrar edilebilir bir denemeyle destekleyin. Veri yoksa bunu açıkça yazın; varsayımı ölçülmüş sonuç gibi sunmayın. Her bulguya bir sorumlu, etkilenen sayfa ve tamamlanınca nasıl doğrulanacağı bilgisini ekleyin.
2. İçeriği ve ziyaretçinin yolunu birlikte inceleyin
Ana sayfa kim olduğunuzu ve kime ne sunduğunuzu anlaşılır biçimde anlatıyor mu? Hizmet sayfası teslim kapsamını, süreci ve karar vermek için gerekli örnekleri gösteriyor mu? “İletişime geçin” çağrısına gelmeden önce ziyaretçinin cevaplanmamış sorularını bulun. Eksik içerik bazen yeni bir arayüzden önce hazırlanmalıdır; boş alanları tasarım sonrasında doldurmak sayfa yapısını yeniden değiştirebilir.
Menü isimlerini şirket içi departmanlara göre değil, ziyaretçinin aradığı işe göre okuyun. Projelerde yalnız görsel göstermek yerine yapılan işi ve kapsamını açıklayın; kanıtlanmamış sonuçlar eklemeyin. Birden fazla dil varsa düğmelerin, hizmet metinlerinin ve hata mesajlarının aynı anlamı taşıdığını kontrol edin. Çalışan sayfaların adreslerini ve mevcut bağlantıları yenileme envanterine alın.
3. Hızı ve kullanılabilirliği gerçek görevlerle kontrol edin
Google’ın Web Vitals rehberi yükleme, etkileşime yanıt ve görsel kararlılığı ayrı değerlendirir. Laboratuvar testi geliştirme sırasında faydalıdır; gerçek ziyaretçi ölçümlerinin yerini tek başına tutmaz. Bir puanı bütün deneyimin özeti gibi kullanmayın.
Telefonda menüyü açın, bir hizmeti bulun, örnek işi inceleyin ve formu doldurun. Ağ yavaşladığında büyük video veya görsellerin bu yolu geciktirip geciktirmediğini gözleyin. İçerik yüklenirken düğmelerin yer değiştirmesini ve ekranı kaplayan katmanları kaydedin. Sorunu hangi cihazda ve hangi adımda gördüğünüz belli olsun; yalnız “mobil yavaş” notu çözümü yönlendirmez.
Aynı akışı klavyeyle ve metni büyüterek deneyin. Menü açılıp kapanmalı, odak görünmeli, hata mesajı okunabilmelidir. Yoğun hareket kullanan sayfalarda kullanıcının azaltılmış hareket tercihini de değerlendirin; MDN bu tercihin tarayıcıda nasıl algılandığını açıklar. Görsel kimliği korurken alternatif bir sakin görünüm planlayabilirsiniz.
4. Formu, kayıt ve geri dönüş süreciyle birlikte test edin
Örnek bir test senaryosu düşünün: Ziyaretçi gönder düğmesine basınca “Alındı” yazıyor, fakat sunucu talebi kaydetmemiş. Ekrandaki mesaj tek başına teslim kanıtı değildir. Başarı durumu, sunucunun kaydı kabul ettiğini doğrulayan yanıtla gösterilmelidir. E-posta uygulamasını açan bir bağlantı da mesajın gönderildiğini doğrulamaz; kullanıcıya o adımın ne yaptığı açık söylenmelidir.
Geçersiz bilgi, ağ kesintisi, sunucu hatası ve art arda tıklama senaryolarını deneyin. Hata olduğunda yazılanlar korunmalı, tekrar deneme anlaşılır olmalı ve aynı başvuru gereksiz yere çoğalmamalıdır. Kayıt oluştuktan sonra hangi ekip üyesinin bunu göreceğini, bildirimin ulaşmaması halinde nereden kontrol edileceğini ve geri dönüş sorumlusunu tanımlayın. Form, başarılı bir animasyonla değil, izlenebilir bir iş kaydıyla tamamlanır.
5. Onarım ile yeniden yapımı bulgulara göre ayırın
Yeni teknoloji seçimini ihtiyaç listesinden sonra yapın. Mevcut sistem içerik düzenlemeye ve güvenilir başvuru almaya elveriyorsa belirli bölümleri düzeltmek yeterli olabilir. Yönetim, entegrasyon veya bakım sınırları işi sürekli engelliyorsa altyapı değişikliği anlamlı hale gelir. Kararı, aşağıdaki gibi aşamalara bölün; her aşamanın çıkışı ve kabul koşulu yazılı olsun.
| Aşama | Ne zaman? | İlk teslim | Kabul koşulu |
|---|---|---|---|
| 1 · İşlevi onar | Başvuru veya temel gezinme bozuk | Çalışan form ve kritik bağlantılar | Başarı ve hata senaryoları doğrulandı |
| 2 · İçeriği düzenle | Hizmet ve kapsam anlaşılmıyor | Sayfa planı, metin ve örnek işler | Hedef kullanıcı temel sorularını yanıtlayabiliyor |
| 3 · Arayüzü yenile | İçerik doğru, kullanım zor | Öncelikli sayfaların mobil ve masaüstü tasarımı | Ana görevler iki görünümde tamamlanıyor |
| 4 · Altyapıyı değiştir | Bakım ve entegrasyon sınırları doğrulandı | Geçiş, veri taşıma ve geri dönüş planı | Kayıtlar, adresler ve sorumluluklar kontrol edildi |
6. Yayın kararını bu kontrol listesiyle verin
- Hedef kullanıcı, ana görev ve her sorunun kabul ölçütü yazılı mı?
- İçerik, örnek işler ve bütün dil sürümleri onaylandı mı?
- Mobil, klavye, büyütülmüş metin ve yavaş ağ senaryoları denendi mi?
- Formun başarı, hata ve tekrar gönderim davranışı doğrulandı mı?
- Eski bağlantılar, yeni adresler ve gereken yönlendirmeler kontrol edildi mi?
- İçerik güncelleme, yedekleme ve başvurulara geri dönüş sorumluları belli mi?
- Yayın sonrası sorun görülürse geri alınacak sürüm ve kontrol günü belirlendi mi?
Yenilemenin başarısını yalnız ekran görüntüsüyle değerlendirmeyin. Öncesi ve sonrası ölçümleri aynı görev ve karşılaştırılabilir koşullarla inceleyin; değişmeyen sorunları görünür bırakın. El Chedo ile kapsam oluştururken mevcut adresinizi, gözlediğiniz aksaklıkları ve sitenin yapmasını beklediğiniz işleri proje brifinde paylaşabilirsiniz.