Bir tasarım sunumundan sonra satış ekibi düğmenin daha görünür olmasını, yönetim daha sade bir sayfa hazırlanmasını, ürün sorumlusu ise teknik bilgilerin artırılmasını isteyebilir. Bu yorumlar farklı mesajlarda ve farklı ekran görüntüleri üzerinde toplandığında ajansın hangi kararı uygulayacağı belirsizleşir. Aynı bölüm birkaç kez değiştirilir; son sürümün hangisi olduğu ve kimin onay verdiği unutulabilir. Revizyon sürecini düzenlemek, bu kararları uygulanabilir ve izlenebilir hale getirmektir.
Bir web tasarım ajansı ile çalışırken iyi geri bildirim vermek için tasarımcı olmanız gerekmez. Sorunun yerini, ziyaretçiye etkisini ve beklediğiniz sonucu açıkça anlatmanız gerekir. Bu rehberde revizyon turunun nasıl hazırlanacağını, yorumların hangi şablonla iletileceğini, kapsam değişikliklerinin nasıl değerlendirileceğini ve düzeltmenin hangi kanıtla kapatılacağını ele alıyoruz. Örnekler varsayımsal proje senaryolarıdır; gerçek müşteri deneyimi veya sonuç iddiası içermez.
Revizyon Başlamadan Önce Ortak Bir Referans Belirleyin
Değerlendirme, projenin başında kabul edilen hedeflere dayanmalıdır. Hangi ziyaretçiye hitap edildiği, hangi sayfaların hazırlanacağı, hangi işlemlerin destekleneceği ve marka dilinin nasıl kullanılacağı net değilse her yorum yeni bir başlangıca dönüşebilir. Kurumsal web tasarım briefi, bu ortak referansı oluşturmak için kullanılabilir. Revizyon listesinde gerektiğinde ilgili hedefe veya kabul ölçütüne atıf yapın; ekibin önceki kararları yeniden tahmin etmesini beklemeyin.
Örneğin ana sayfanın amacı teknik teklif talebine yönlendirmekse ilk ekranı bu görev üzerinden inceleyin. “Sayfa biraz boş” yorumu yerine, ziyaretçinin sunulan hizmeti anlayıp anlayamadığını ve ilgili adıma ulaşıp ulaşamadığını değerlendirin. Böylece tartışma kişisel beğenilerle sınırlı kalmaz. Yeni bir iş hedefi ortaya çıktıysa bunu da açıkça belirtin; başlangıçtaki hedef değişmişken yalnız yerleşim üzerinde küçük düzeltmeler yapmak yeterli olmayabilir.
Hata, Revizyon ve Yeni Talebi Birbirinden Ayırın
Onaylanan davranışın çalışmaması, mevcut tasarım içinde iyileştirme istenmesi ve yeni bir işlev eklenmesi aynı iş değildir. Formun gönderim hatası, kartların sırasının değiştirilmesi ve üyelik sistemi eklenmesi farklı değerlendirmeler gerektirir. Bir talebi hangi başlık altında ele alacağınızı, yalnızca yazılan cümlenin uzunluğuna göre belirlemeyin. “Bir alan daha ekleyelim” ifadesi veri kaydı, bildirim ve raporlama değişiklikleri doğurabilir.
Revizyon turunun ve kapsam içindeki düzeltmelerin tanımı proje teklifinde açık olmalıdır. Her ajans için geçerli sabit bir revizyon sayısı veya evrensel uygulama varsaymayın. Web tasarım tekliflerini karşılaştırırken, teslimlerin yanında değerlendirme turlarının kapsamını, karar beklemelerini ve sonradan gelen taleplerin nasıl ele alınacağını da inceleyin. Amaç yorumları engellemek değil, yapılacak işin etkisini görünür kılmaktır.
Yorum Verecek Kişileri ve Karar Sorumlusunu Belirleyin
Ürün bilgisini teknik sorumlu, marka dilini iletişim ekibi, satış akışını satış yöneticisi değerlendirebilir. Herkesin uzmanlık alanı farklıdır; bütün yorumların eşit biçimde doğrudan uygulamaya dönüşmesi gerekmez. Proje tarafında yorumları birleştiren ve çelişkili isteklerde karar veren bir sorumlu belirleyin. Bu kişi tek başına bütün bilgiyi üretmez; doğru kişilerden gelen görüşlerin ortak bir karara bağlanmasını sağlar.
Ajansa iletilmeden önce tekrar eden yorumları birleştirin ve birbirini dışlayan talepleri çözün. Aynı alan için hem daha fazla metin hem de daha kısa ekran isteniyorsa hangi bilginin öncelikli olduğuna karar verilmelidir. Ajans alternatif önerebilir; ancak işletmenin ürün veya hizmet önceliğini tahmin etmek zorunda kalmamalıdır. Karar verilemeyen konu, uygulamaya hazır talep olarak değil, cevap bekleyen soru olarak kaydedilsin.
Geri Bildirimi Doğru Aşamada ve Tek Listede Toplayın
Sayfa yapısı, görsel tasarım, içerik, çalışan önizleme ve yayın öncesi kontrol farklı değerlendirme aşamalarıdır. İlk aşamada ana sayfanın bölüm sırası konuşulurken son aşamada eksik belge bağlantısı kontrol edilebilir. Onaylanmış temel yerleşimin geliştirme tamamlandıktan sonra yeniden açılması daha geniş etki yaratabilir. Bu nedenle tur başında hangi sürümün, hangi kapsamla değerlendirileceğini ve yorumların ne zamana kadar toplanacağını yazın.
Web tasarım teslim takvimi, bu değerlendirme pencerelerini geliştirme adımlarıyla birlikte planlamak için kullanılabilir. Bir turu, aynı sürüm üzerinde toplanmış ve işletme içinde uzlaştırılmış yorum paketi olarak tanımlayabilirsiniz. Yeni sürüm gösterildikten sonra önceki mesajlardan unutulmuş yorumların eklenmesi gerekiyorsa bunları ayrı kayıtla ilişkilendirin; listenin sessizce değişmesi uygulamayı takip etmeyi zorlaştırır.
Kopyalayıp Kullanabileceğiniz Revizyon Kaydı
Geri bildirim kaydı uzun olmak zorunda değildir. Ajansın sorunu bulmasını, nedenini anlamasını ve tamamlandığında neyi kontrol edeceğini bilmesini sağlamalıdır. Her talebe sabit bir numara verin; aynı kaydın yeni yorumlarla güncellenmesini sağlayın. Aşağıdaki alanlar bir ortak tabloya veya kullanılan proje aracına taşınabilir. Bir ekran görüntüsü ekliyorsanız, hangi sürüm ve sayfaya ait olduğunu ayrıca belirtin.
- Kayıt ve konum: Talep numarası, sayfa adresi veya ekran adı, bölüm başlığı ve incelenen sürüm.
- Mevcut durum: Görülen davranış veya anlaşılmayan bilgi; gerekiyorsa sorunu tekrar oluşturma adımları.
- Etkisi ve gerekçesi: Hangi kullanıcı görevinin zorlaştığı veya hangi onaylı bilginin yanlış aktarıldığı.
- Beklenen sonuç: Tercih edilen çözümün yanında, çözülmesi gereken asıl ihtiyacın açık tanımı.
- Öncelik ve kapsam: Yayını engelleyip engellemediği, başka sayfalara etkisi ve karar bekleyen konu.
- Sorumlu ve kapanış: Kararı verecek kişi, uygulanan sürüm ve doğrulamayı yapacak kişi.
Belirsiz Bir Yorumu Uygulanabilir Talebe Çevirin
“Hizmet alanını daha profesyonel yapalım” yerine şu kayıt hazırlanabilir: “REV-12, bakım hizmeti sayfası, kapsam bölümü, üçüncü önizleme. Açıklama, sahada kontrol ile parça değişimini aynı hizmet gibi gösteriyor. Ziyaretçi hangi işin dahil olduğunu anlayamıyor. Onaylı kapsam metni iki ayrı başlıkla gösterilmeli; kapsam dışı işler ilgili açıklamayla ayrılmalı. Ürün sorumlusu metni, proje sorumlusu yerleşimi kontrol edecek.” Bu anlatım, estetik tercihin arkasındaki bilgi ihtiyacını da görünür kılar.
Hizmet sayfası hazırlama rehberinde ele alınan kapsam, teslim ve süreç ayrımı, böyle bir talebin gerekçesini destekleyebilir. Talep, belirli bir tasarım çözümüne erken bağlanmak zorunda değildir. İşletme neyin anlaşılması gerektiğini belirtir; ajans iki başlık, açıklama kutusu veya farklı bir içerik düzeni önerebilir. Son karar, alternatifin kullanıcı sorusunu karşılayıp karşılamadığına bakılarak verilir.
Görsel Tercihi Ölçülebilir Sorundan Ayırın
Renk, boşluk ve görsel seçimi marka kimliğinin parçasıdır; bu konularda tercih belirtmek doğaldır. Ancak tercih ile kullanım sorununu aynı gerekçeyle sunmayın. “Bu rengi sevmiyorum” ile “bu açıklama arka plan üzerinde okunmakta zorlanıyor” farklı geri bildirimlerdir. İlkinde marka yönü ve alternatifler konuşulur; ikincisinde metin, arka plan ve görüntüleme koşulları birlikte incelenir. İki durumda da değişikliğin hangi öğeye uygulanacağı belli olmalıdır.
W3C metin kontrastı açıklaması, metin ile arka plan arasındaki kontrastın değerlendirilmesine somut bir temel sunar. Okunabilirlik yorumunu yalnız ekran görüntüsünün görünüşüne bırakmak yerine kullanılan renkler ve metnin özellikleri üzerinden kontrol etmek mümkündür. Bu, tek bir ölçümün bütün erişilebilirlik değerlendirmesini tamamladığı anlamına gelmez; ilgili sorunu kişisel beğeniden ayırmaya yardımcı olur.
Ana sayfada hangi bölümün öne çıkacağı da benzer biçimde gerekçelendirilmelidir. Ana sayfa içerik planı, ziyaretçinin izleyeceği yol üzerinden değerlendirme yapılmasını sağlar. Her bölümün ilk ekranda görünmesini istemek yerine hangi bilginin önce anlaşılması gerektiğini belirleyin. Bir modülü büyütmenin diğer içeriği aşağı taşıyacağını ve mobil sıralamayı etkileyebileceğini değerlendirme sırasında göz önünde bulundurun.
İçerik Düzeltmelerini Onaylı Metinle İletin
Bir başlığı veya hizmet açıklamasını değiştirmek istediğinizde yeni metni kayda ekleyin. “Burayı satış ekibi düzeltecek” notu, tasarım uygulamasını tamamlanabilir hale getirmez. Metnin kimin tarafından doğrulandığı, hangi sürümün kullanılacağı ve hangi sayfalarda tekrar ettiği belirtilmelidir. Şirket adresi, ürün özelliği veya kapsam bilgisi gibi ayrıntılarda ajansın eksik kısmı kendi yorumuyla doldurmasını beklemeyin.
Metin ve görsel teslim paketinin hazırlanması, revizyon sırasında da geçerlidir. Yeni fotoğrafı doğru dosya adıyla eşleyin; kırpılmaması gereken bölümü ve kullanım yerini belirtin. Değişen metin bir kartı, menüyü ve iç sayfayı birlikte etkiliyorsa ilişkili alanları listeleyin. Böylece yalnız ekranda görünen ilk örnek düzeltilip diğer kopyaların eski kalması önlenebilir.
Mobil Sorunlarda Koşulları ve Adımları Kaydedin
“Telefonda bozuk” ifadesi yerine cihazı, tarayıcıyı, ekran yönünü, sayfa adresini ve yapılan adımları yazın. Sorun her açılışta mı ortaya çıkıyor, menü açıldığında mı oluşuyor, klavye görünürken mi yaşanıyor? Ekran görüntüsünde sadece sonucu göstermek yerine mümkünse önceki adımı da açıklayın. Kişisel bilgi içeren form veya hesap ekranı paylaşılıyorsa gereksiz ayrıntıları kapatarak yalnız sorunun anlaşılmasına yetecek kanıtı iletin.
Chrome DevTools cihaz modu belgesi, masaüstündeki cihaz benzetiminin yaklaşık bir değerlendirme olduğunu ve gerçek mobil cihazın bütün özelliklerini temsil etmediğini açıklar. Bu nedenle gerçek telefonda görülen bir sorunu, masaüstü önizlemede oluşmadığı için kapanmış saymayın. Mobil form ve menü kontrol listesi, geri bildirimi gerçek görev adımlarına bağlamak için kullanılabilir. Düzeltmeden sonra aynı koşullarda yeniden deneyin.
Kapsam Değişikliğinin Etkisini Karardan Önce Görünür Kılın
Mevcut bir butonun metnini değiştirmekle, butonun arkasına başvuru takibi eklemek farklı teslimler doğurur. Yeni istekte hangi ekranların, verilerin, yetkilerin, içeriklerin ve testlerin etkilendiğini değerlendirin. Ajans, bu etkiyi ve varsa ek çalışma ihtiyacını açıklayabilmelidir. İşletme de yeni talebin mevcut yayından önce mi yapılacağını, sonraki aşamaya mı bırakılacağını veya başka bir işin yerine mi geçeceğini belirlemelidir.
Web yazılım kapsamı içeren değişikliklerde yalnız görünen ekranı değerlendirmek yeterli olmayabilir. Örneğin bir form alanı rapora, e-postaya ve dış sisteme aktarılıyorsa değişiklik bu noktalara da yansır. Yeni talep için alınan kararın tarihini ve güncel teslim listesini kaydedin. Onaylanmadan uygulamaya geçen bir değişikliğin ardından takvim veya maliyetin farklılaşması, tarafların aynı beklentiyle ilerlemesini zorlaştırır.
Önceliği “Acil” Etiketiyle Sınırlamayın
Her talebi acil olarak işaretlemek, gerçekten yayını engelleyen konuyu görünmez hale getirir. İşlemin tamamlanmasını durduran hata, yanlış ticari bilgi, kullanım güçlüğü ve görsel tercih için farklı öncelik gerekçeleri yazılabilir. Bu sınıflandırma örnektir; projeye göre uyarlanmalıdır. Bir düzeltmenin beklemesi mümkünse hangi tarihe veya sürüme bırakıldığını belirtin. Belirsiz bir “sonra bakılır” notu, tamamlanmış karar gibi görünmemelidir.
Düzeltmeyi Yalnız Uygulandı Mesajıyla Kapatmayın
Ajansın “uygulandı” bildirimiyle kontrol eden kişinin “doğrulandı” kararı farklı aşamalardır. Talebi açan kişi yeni sürümde ilgili bölümü yeniden incelemeli, beklenen sonucun gerçekleştiğini kaydetmelidir. Sorun sürüyorsa aynı kayda açıklama eklenebilir; yeni numarayla tekrar açılarak geçmişi koparmak gerekmez. Kapanışta hangi sürümün, hangi koşullarda ve kimin tarafından kontrol edildiği görünür olsun.
Yazılım geliştirmede kalite güvencesi, değişiklikten etkilenen yakın alanların da değerlendirilmesini gerektiren bir çerçeve sunar. Bir kartın metni kısaltıldığında bağlantı hedefi; form düğmesi değiştiğinde hata ve başarı mesajı; menü öğesi taşındığında mobil gezinme yeniden kontrol edilebilir. Revizyonun kapatılması için aşağıdaki sorular kullanılabilir.
- İstenen sonuç, talepte belirtilen sayfa ve sürümde gerçekten sağlandı mı?
- İlgili metin, görsel ve bağlantı hedefleri onaylı malzemeyle eşleşiyor mu?
- Değişiklik, ortak kullanılan başka sayfa veya bileşenlerde beklenmeyen sonuç yarattı mı?
- Sorun mobilde bildirildiyse aynı cihaz ve adımlarla yeniden kontrol edildi mi?
- Kapsam dışına bırakılan işler açıkça sonraki sürüme veya ayrı karara bağlandı mı?
- Doğrulayan kişi, kontrol tarihi ve kapanış kararı kayıt üzerinde görülebiliyor mu?
Örnek Bir Revizyon Turunu Baştan Sona İzleyin
Varsayımsal bir makine üreticisinin ikinci önizlemesinde satış ekibi ürün kartlarına teknik değerlerin eklenmesini, marka ekibi ise kartların sadeleşmesini istiyor olsun. Proje sorumlusu iki yorumu doğrudan ajansa iletmek yerine kullanım amacını netleştirir: Ziyaretçi ürün ailesini seçebilmeli, ayrıntılı ölçüleri ilgili iç sayfada inceleyebilmelidir. Ortak karar, kartta ayırt edici tek özellik ve iç sayfa bağlantısı gösterilmesidir. Bu kararın gerekçesi, ilgili talebin açıklamasına eklenir.
Ajans üçüncü önizlemede bu düzeni uygular ve kayıt numarasıyla kontrol ister. Satış sorumlusu teknik ifadenin doğruluğunu, marka sorumlusu görsel düzeni, proje sorumlusu bağlantının doğru iç sayfaya ulaştığını inceler. Aynı turda gelen ürün karşılaştırma aracı isteği ise ayrı kapsam değerlendirmesine alınır. Böylece kart düzeltmesinin kabulü, yeni işlev kararı beklenirken gereksiz yere açık kalmaz. Örnekteki sürüm sırası bir işleyiş gösterimidir; sabit teslim süresi veya zorunlu tur sayısı değildir.
Bu yöntem, sonradan gelen yorumların kaybolmasını da önler. Kapatılmış bir kayıttaki karar yeniden değişecekse neden değiştiği ve etkilenen sürüm belirtilir. Önceki onayın silinmesi yerine yeni karar onunla ilişkilendirilir. Projeyi devralan bir kişi, yalnız son ekranı değil, o ekranın hangi ihtiyaç ve karar sonucunda oluştuğunu da anlayabilir.
Yayın Onayını ve Sonraki İşleri Ayrı Kaydedin
Bir tasarım ekranına verilen onay, çalışan sitenin bütün içerik ve işlevlerinin kontrol edildiğini tek başına göstermez. Yayın öncesinde açık talepleri gözden geçirin; engelleyici sorun, ertelenmiş iyileştirme ve cevap bekleyen kararları ayırın. Kurumsal web sitesi teslim ve destek kapsamı, hangi çıktının teslim alınacağı konusunda tamamlayıcıdır. Kabul edilen sürümü ve varsa bilinen açıkları birlikte kaydedin.
Yayın sonrasındaki hata bildirimi, içerik güncellemesi ve yeni geliştirme isteklerinin hangi kanaldan iletileceği de belli olmalıdır. Site sahipliği ve destek sorumlulukları değerlendirilirken bu işleyişi somutlaştırın. Toplantıda verilen önemli kararları ortak kayda aktarın; konuşmanın yapılmış olması tek başına uygulanacak iş listesinin güncel olduğu anlamına gelmez.
Web Tasarım Sistemleri olarak revizyon görüşmelerinin ortak hedef, açık gerekçe ve doğrulanabilir sonuç etrafında yürütülmesini öneriyoruz. Projenizde yorumlar farklı kanallara dağılıyorsa önce tek liste, bir karar sorumlusu ve anlaşılır kapanış ölçütleri oluşturun. Mevcut sayfa yapınızı ve örnek taleplerinizi paylaşarak revizyon sürecini bizimle değerlendirebilirsiniz. Düzenli geri bildirim, daha çok yorum üretmekten çok, doğru kararın doğru sürümde uygulanmasını sağlamaktır.
Bu makalenin uzunluğu 1831 kelimedir.
Bu makale 2026-10-19 tarihinde yayınlanmıştır.