Bir internet sitesi üzerinde planlı bakım çalışması yapılırken ziyaretçi yalnızca “biraz sonra tekrar deneyin” mesajını görmemelidir. Hangi işlemin geçici olarak kullanılamadığı, başka hangi bölümün çalışmaya devam ettiği, gönderdiği bir formun kayda geçip geçmediği ve ne zaman yeniden kontrol edebileceği anlaşılmalıdır. Suadiye Web Tasarım arayışındaki işletmeler için bu rehber, planlı bakım sırasında ziyaretçi iletişimini ve güvenli yeniden deneme kararını tasarlamaya odaklanır. Suadiye’de belirli bir işletme, ofis veya hizmet durumu bulunduğu iddia edilmez; anlatılanlar farklı iş türlerine uyarlanabilecek bir tasarım çerçevesidir.

Planlı bakım ekranı teknik nottan önce kullanıcı yoludur

Bakım çoğunlukla siteyi güncelleyen veya işleten ekibin iç planında başlar. Ziyaretçi ise çalışmanın nedenini değil, kendi işine etkisini anlamaya çalışır: bilgi sayfasını okuyabilecek mi, talep formu gönderebilecek mi, hesabına erişebilecek mi, satın alma adımını tamamlayabilecek mi? Bu soruların her biri farklı bir kullanıcı yoluna karşılık gelir. Tek bir genel uyarı, kullanılabilen sayfaları da gereksiz yere kapatabilir; çalışmayan bir işlemi kullanılabilir gibi göstermekse yanlış beklenti doğurur. Tasarım kararı, bakım kapsamını ve gerçekten etkilenmiş işleri birlikte açıklamalıdır.

İlk adım, hangi sayfa veya işlevlerin etkileneceğini işletme sorumlusuyla yazılı biçimde doğrulamaktır. Kapsam bilinmiyorsa tüm sitenin kapalı olduğunu varsaymak ya da hiçbir şey etkilenmiyormuş gibi davranmak doğru değildir. Belirsiz kalan işlevi ayrıca işaretleyin ve ziyaretçiye onu kullanmasını önermeyin. Bir bakım bildirimi teknik ekibin iç notunu olduğu gibi yayımlamak için değil, ziyaretçiye güvenilir bir sonraki adım göstermek için vardır.

Önce etkilenen işlemi ve sınırı belirleyin

Bakım bütün siteyi kapsayabilir veya yalnızca tek bir alanı etkileyebilir. Örneğin içerik sayfaları okunabilirken iletişim formu, ödeme, hesap girişi ya da belge indirme geçici olarak kullanılamayabilir. Bu nedenle bakım planında etkilenen adresleri, işlevleri ve kullanıcı gruplarını ayrı ayrı kaydedin. “Site kapalı” gibi geniş bir ifade yerine hangi işlemin durduğunu ve hangi bölümün erişilebilir olduğunu doğrulayın. Çalışma sırasında kapsam değişirse ekibin yeni bilgiyi kimin onaylayacağı da önceden belirlenmelidir.

Ardından her işlem için ziyaretçinin ne yapabileceğini kararlaştırın. Yalnızca bilgi okunuyorsa uyarı gerekmeyebilir. Form gönderilemiyorsa güncel ve doğrulanmış alternatif iletişim yolu gösterilebilir. Ödeme sonucu belirsizse ziyaretçiye aynı işlemi art arda göndermesini söylemek yerine sipariş veya işlem durumunu kontrol edebileceği güvenli yol tarif edilmelidir. Böyle bir yol yoksa bunu varmış gibi göstermeyin; işletmenin destek kanalı ve inceleme sorumlusu bakım öncesinde tanımlanmalıdır.

Mesaj dört pratik soruya cevap versin

Bakım bildirimi kısa olabilir; ancak önemli bilgiyi saklamamalıdır. Ziyaretçi metni okuduğunda şu sorulara cevap bulabilmelidir:

Hangi sayfa ya da işlem geçici olarak kullanılamıyor?
İşletmenin doğruladığı başlangıç ve tahmini bitiş zamanı nedir?
Ziyaretçi bekleyebilir, başka bir bölümü kullanabilir ya da destek isteyebilir mi?
Gönderim veya ödeme yaptıysa işlemin sonucunu nereden kontrol etmelidir?

Tahmini bitiş kesin bir açılış sözü değildir. Süre net değilse “şu saatte kesin açılacak” demek yerine bir sonraki bilgi güncellemesinin ne zaman yapılacağını yazın. Mesajda tarih, saat ve saat dilimini açıkça belirtmek, farklı konumdan veya daha sonra gelen ziyaretçilerin zamanı yanlış anlamasını azaltır. İçerik değiştiğinde eski duyurunun kaldırılması veya yeni bilgiyle değiştirilmesi için sorumlu atayın.

Bakım öncesi, bakım sırası ve yeniden açılış farklı durumlardır

Tek bir statik uyarı yerine üç aşamayı düşünün. Çalışma başlamadan önce ziyaretçiye hangi işlemin ne zaman etkileneceğini anlatın; ancak süreyi yalnız işletmenin onayladığı bilgiye göre verin. Çalışma sırasında ekranda “devam ediyor” bilgisi ve bir sonraki güncelleme zamanı bulunabilir. İşlev geri geldiğinde de sayfanın güncel durumu doğrulanmadan eski mesajı kaldırmayın. Yeniden açılış ifadesi, işletme ekibinin yaptığı kontrolün yerine geçmez; yalnızca ziyaretçiye doğrulanmış durumun aktarılmasını sağlar.

Her aşama için kullanılacak metni ve değişikliği yayımlayacak kişiyi önceden belirleyin. Bakım beklenenden uzun sürerse duyurunun zamanı, etkilenen alanı ve alternatif adımı tekrar gözden geçirilmelidir. Süre değişikliğini fark eden ziyaretçiden eski bir mesajı okumasını beklemeyin. Ekran tasarımında başlık, kısa açıklama, durum bilgisi ve destek seçeneği görsel hiyerarşiyle ayrılabilir. Ancak renk veya simge tek başına anlam taşımamalı; metin de durumu açıklamalıdır.

Form ve ödeme adımında sonucu bilinmeyen işlemi ayırın

En hassas an, ziyaretçinin gönder düğmesine bastıktan sonra sonucu görememesidir. Formun ulaşıp ulaşmadığı ya da ödemenin tamamlanıp tamamlanmadığı bilinmiyorsa ekran “başarılı” veya “başarısız” diye tahmin yürütmemelidir. Ziyaretçi aynı işlemi tekrarladığında ikinci bir kayıt veya ödeme oluşup oluşmayacağı işletmenin kullandığı sisteme bağlıdır; bunu tasarımcı varsayamaz. Bu durum için önce teknik ve operasyon ekiplerinden doğrulanmış bir kontrol yolu isteyin. Mevcut kayıt bulunamıyorsa, soruyu kime ve hangi bilgilerle ileteceği açıklanabilir.

Yeniden deneme düğmesi de yalnızca tekrarın güvenli olduğu doğrulanmışsa gösterilmelidir. Aksi durumda “işleminiz kontrol ediliyor” gibi açık bir ara durum, tahmini bir başarı mesajından daha dürüst olabilir. Ziyaretçiden şifre, tam ödeme bilgisi veya gereksiz kişisel ayrıntı istemeyin. İletişim formu üzerinden takip yapılacaksa hangi referans bilgisinin yeterli olduğunu işletme belirlesin. Ödeme entegrasyonu ve sipariş durumlarının ayrı doğrulanması için ödeme entegrasyonu rehberini inceleyebilirsiniz.

Bilgi güncellemesini ve alternatif yolu sahiplenin

Bir bakım bildiriminin yararlı olması, ziyaretçiye yalnızca sorun bulunduğunu söylemesine değil, sonraki adımı göstermesine bağlıdır. İşletme bir telefon, e-posta veya başka bir destek kanalı sunuyorsa bu yolun çalıştığı ve güncel olduğu doğrulanmalıdır. Geçici bir iletişim seçeneği belirlenmediyse ekranda hayalî bir numara veya yanıt süresi yazmayın. Alternatif kanalın hangi talep türlerini karşıladığı ve kim tarafından izleneceği açık olmalıdır. Ziyaretçiden aynı açıklamayı birden fazla yere göndermesini isteyen tasarımlar ekipte yinelenen kayıtlar oluşturabilir.

Güncelleme sorumlusu, işletmenin onayladığı bilgi kaynağını ve son kontrol zamanını kaydedebilir. Böylece bakım sürerken farklı ekranlarda eski ve yeni mesajların birlikte kalması daha kolay fark edilir. Ziyaretçiye gösterilen metin, sosyal medya duyurusu veya başka iletişim kanalıyla çelişiyorsa önce hangi kaydın güncel olduğunu işletme yetkilisi belirlemelidir. Bu rehber sosyal medya kriz yönetimini ya da teknik arıza giderme adımlarını anlatmaz; web sayfasındaki ziyaretçi bilgisinin anlaşılır ve güncel kalmasına odaklanır.

Yayından önce gerçek kullanıcı senaryolarıyla kontrol edin

Bakım ekranını yalnızca masaüstünde açıp metni okumak yeterli değildir. Telefonda başlık ve sonraki adım görünür mü? Klavye ile hareket eden biri destek bağlantısına ulaşabiliyor mu? Ekran okuyucu, durum değişikliğini anlaşılır bir sırada duyuruyor mu? Form yanıtı beklerken kullanıcı başka sayfaya geçtiğinde ne görür? Planlanan bakım iptal edilirse eski uyarı nasıl kaldırılır? Bunlar tasarım kararını etkileyen gerçek görev sorularıdır. Her senaryoyu ilgili işlevi bilen bir kişiyle deneyin ve sonucu kaydedin.

Kontrol sırasında çalışan bir sayfanın bakım metnine gereksiz yere yönlenmediğini, etkilenmiş bir işlevin de normalmiş gibi görünmediğini doğrulayın. Mesaj, dar ekranlarda kesilmemeli; bağlantı adı nereye götürdüğünü anlatmalıdır. Yalnız rengi değiştirerek “bekliyor” ile “tamamlandı” ayrımı yapmayın. Bakım bittiğinde hangi kişinin eski mesajı kaldıracağı, yeni durumun kim tarafından onaylanacağı ve ana sayfada kalan duyuruların nasıl bulunacağı iş akışında belirtilmelidir.

Bu kontrolü kısa bir senaryo kartına dönüştürmek ekipler arasında aynı ölçütü korur. Kartta test eden kişinin rolü, kullandığı sayfa, beklenen mesaj, görülen sonuç ve açık kalan soru bulunabilir. Kart kişisel veya ödeme bilgisi taşımak zorunda değildir. Tasarım onayı verilirken yalnız metnin güzel görünmesine değil, ziyaretçinin bakım sırasında hangi kararı verebildiğine bakın.

404 sayfası ve teknik bakım planıyla karıştırmayın

Bakım ekranı, bulunamayan bir adres için gösterilen 404 sayfasından farklıdır. 404 rehberi ziyaretçiyi doğru sonraki sayfaya yönlendirmeyi ele alır; planlı bakım ise mevcut bir işlevin geçici olarak neden kullanılamadığını ve ne zaman yeniden kontrol edileceğini anlatır. Benzer şekilde, yedekleme ve yazılım bakım planı teknik ekiplerin süreklilik çalışmalarına odaklanır. Bir ziyaretçi ekranı bunların yerine geçmez. İlgili temel konular için yazılım bakım planı rehberini ve 404 sayfası rehberini inceleyebilirsiniz.

Planlı bakımın neyi değiştireceği, sayfaların ne zaman ve hangi sırayla güncelleneceği proje kapsamına yazılmalıdır. Tasarım, geliştirmenin yerine geçmez; teknik ekip de ziyaretçiye gösterilecek dilin ve onay sorumlusunun kararını kendiliğinden veremez. Web sitesi tasarımı ve yazılımı hizmetinde proje görüşmesine mevcut bakım mesajını, etkilenen kullanıcı adımlarını ve işletmenin doğrulayabildiği alternatifleri getirebilirsiniz. Hizmet, belirli bir sonuç veya kesintisiz çalışma garantisi anlamına gelmez; gerekli teslim ve sorumluluklar görüşmede netleştirilmelidir.

Sık sorulan sorular

Planlı bakım sırasında bütün siteyi kapatmak gerekir mi?

Her bakım bütün sayfaları etkilemez. Hangi işlevlerin çalıştığını, hangilerinin durduğunu teknik ve işletme sorumlularıyla ayrı ayrı doğrulayın. Kullanılabilen bilgi sayfalarını kapatmak ziyaretçiye gereksiz engel çıkarabilir; çalışmayan bir işlemi açık bırakmak da yanlış beklenti yaratabilir.

Tahmini bitiş saati kesin değilse ne yazmalıyız?

Onaylanmamış bir saati kesin açılış sözü gibi göstermeyin. İşletmenin doğruladığı tahmini aralığı ve bir sonraki bilgilendirme zamanını ayrı yazın. Süre belli değilse bunu açıkça söylemek, eski veya gerçekçi olmayan bir geri sayımdan daha yararlıdır.

Formu gönderdikten sonra bakım başladıysa ziyaretçi ne yapmalı?

Formun ulaştığı doğrulanamıyorsa başarı mesajı göstermeyin. İşletmenin gerçekten kullanabildiği kontrol veya destek yolunu açıklayın; ziyaretçiden aynı formu tekrar göndermesini ancak tekrarın güvenli olduğu doğrulanmışsa isteyin. İşletme kaydını kimin inceleyeceğini ve ziyaretçiye ne zaman yanıt verileceğini de netleştirin. Ekran, belirsizliği gizlememelidir.

Ödeme ekranında sonuç görünmüyorsa yeniden dene düğmesi koyabilir miyiz?

Tekrarın yeni bir işlem oluşturup oluşturmayacağını kullandığınız ödeme ve sipariş akışı belirler. Teknik sorumlu bunu sınamadan yeniden deneme düğmesi göstermeyin. Önce işlem durumunu kontrol etme yolu sunun; doğrulanmış bir yol yoksa ziyaretçiye işletmenin gerçek destek kanalını gösterin.

Bakım mesajında çalışma nedenini açıklamak zorunlu mu?

Her teknik ayrıntıyı paylaşmanız gerekmez. Ziyaretçinin anlayacağı biçimde hangi işlemin etkilendiğini, kullanılabilir bir alternatif olup olmadığını ve güncellemenin nerede görüleceğini söyleyin. Açıklama eksikse kime danışılacağını da belirleyin. Güvenlik veya işletme açısından paylaşılmaması gereken iç ayrıntıları yayımlamayın.

Bakım uzarsa eski mesajı ne zaman güncellemeliyiz?

Önceden belirlenmiş bir sonraki kontrol zamanında veya etki kapsamı değiştiğinde mesajı tekrar inceleyin. Yeni bitiş tahmini yetkili kişi tarafından doğrulanmadan yayımlanmamalıdır. Güncelleme sorumlusu ve kullanılacak bilgi kaynağı bakım başlamadan önce belirlenirse tutarsız duyuru riski azalır.

Bakım sona erince duyuru hemen kaldırılmalı mı?

Önce etkilenen işlevin gerçekten kullanılabilir olduğu ilgili ekipçe doğrulanmalıdır. Sonra bakım mesajı kaldırılır veya tamamlandığını açıklayan kısa bir bilgiye çevrilir. İşlem hâlâ mümkün değilse alternatif kanal da yeniden kontrol edilir. Yalnız takvimdeki saatin gelmesi, hizmetin yeniden açıldığını kanıtlamaz; sayfanın son durumu kontrol edilmelidir.

Web tasarım projesinde bu çalışmanın kapsamı nasıl tanımlanır?

Etkilenen sayfaları, gösterilecek durumları, mesajı onaylayacak kişiyi, alternatif iletişim yolunu ve bakım bitişinde yapılacak kontrolü ayrı maddeler olarak yazın. Teknik bakım ve kesintisiz erişim garantisi varsaymayın. Tasarım ile yazılım teslimlerinin ve sorumlulukların teklifte açıkça ayrılmasını isteyin.