Web tasarım projesinde revizyon, “tasarım kötü oldu, baştan yapalım” anlamına gelmez. Doğru yönetildiğinde revizyon; hedef, kullanıcı, marka tonu ve teknik uygulanabilirlik arasında daha net bir karar vermeyi sağlar. Yanlış yönetildiğinde ise proje takvimi uzar, ekipler yorulur ve asıl problem çözülmeden ekranda sürekli küçük değişiklikler yapılır.
Web tasarım ajansı ile revizyon süreci, proje başlamadan önce nasıl yürütüleceği konuşulması gereken bir iş akışıdır. Kaç tur revizyon yapılacak, yorumlar nereden toplanacak, hangi değişiklik kapsam içinde sayılacak, hangi karar kim tarafından onaylanacak? Bu sorular net değilse tasarım ne kadar iyi olursa olsun süreç gereksiz gerilim üretir.
Özellikle web tasarım projelerinde revizyonun kalitesi, yalnızca ajansın tasarım gücüne bağlı değildir. Müşterinin geri bildirimi nasıl verdiği, karar vericilerin ne zaman sürece dahil olduğu ve proje hedeflerinin ne kadar net tanımlandığı da sonucu doğrudan etkiler.
Revizyon süreci neden proje başında konuşulmalı?
Revizyon, tasarım ekranı geldikten sonra doğaçlama yönetilecek bir konu değildir. Projenin başında beklenti seti oluşturulmazsa ilk tasarım sunumunda herkes farklı şeye bakar. Pazarlama ekibi dönüşüm alanına, yönetici kurumsal algıya, satış ekibi iletişim butonlarına, teknik ekip ise uygulanabilirliğe odaklanabilir.
Bu farklı bakışlar değerlidir; fakat tek bir yorum havuzunda dağınık biçimde birleşirse karar almak zorlaşır. Nielsen Norman Group, tasarım eleştirisinin yalnızca tasarımı yargılamak değil, tasarımın hedefleri karşılayıp karşılamadığını analiz etmek olduğunu belirtir Nielsen Norman Group. Bu yaklaşım revizyon süreci için de doğrudur: yorum kişisel zevkten çok hedefe bağlanmalıdır.
Revizyon ile yeni talep arasındaki fark nedir?
En çok karışan nokta budur. Revizyon, onaylanan kapsam içindeki bir tasarım veya içerik kararının iyileştirilmesidir. Yeni talep ise proje kapsamına sonradan eklenen yeni modül, yeni sayfa, yeni entegrasyon veya farklı iş hedefidir.
Örneğin ana sayfa hero alanındaki başlığın daha net yazılması revizyondur. Fakat projede olmayan “müşteri paneli de ekleyelim” talebi revizyon değil, yeni kapsam maddesidir. Aynı şekilde renk tonunun marka kılavuzuna yaklaştırılması revizyondur; fakat kurumsal kimliğin baştan tasarlanması ayrı bir hizmettir.
| Talep örneği | Revizyon mu? | Neden? | Nasıl yönetilmeli? |
|---|---|---|---|
| Hero başlığını daha net ve kısa yapmak | Evet | Aynı alan içinde içerik iyileştirmesidir. | Revizyon turuna dahil edilir. |
| Buton metnini “Teklif Al” yerine “Projemi Değerlendir” yapmak | Evet | CTA metni aynı işlevi korur. | Hedefe göre test edilir. |
| Ana sayfaya yeni bir fiyat hesaplama modülü eklemek | Hayır | Yeni fonksiyon ve yazılım kapsamı doğurur. | Ek kapsam olarak tekliflendirilir. |
| Mobil menüde taşma sorununu düzeltmek | Evet | Mevcut tasarımın kullanım hatasıdır. | Öncelikli teknik revizyon yapılır. |
| Onaylanan tasarım dilini tamamen farklı bir stile çevirmek | Duruma bağlı | Brief değiştiyse revizyon değil yön değişikliğidir. | Karar ve kapsam yeniden netleştirilir. |
| Projeye blog modülü eklemek | Hayır | Başta planlanmamış yeni yapı eklenir. | Yeni iş kalemi olarak ele alınır. |
İyi bir revizyon yorumu nasıl yazılır?
Revizyon yorumunun iyi olması için uzun olması gerekmez. Net, konumlu ve gerekçeli olması yeterlidir. “Bu alanı değişelim” yerine hangi alanın, hangi ekranda, hangi gerekçeyle değişmesi gerektiği yazılmalıdır. Böylece ajans yorumu yorumlamak için ekstra toplantı yapmak zorunda kalmaz.
Örnek iyi yorum formatı şu şekilde olabilir: “Ana sayfa hero alanındaki ana başlık, yazılım hizmetimizi fazla genel anlatıyor. Burada ‘işletmeye özel CRM ve süreç otomasyonu’ ifadesi geçerse hedef müşteriye daha net konuşur.” Bu yorumda alan, problem ve çözüm yönü vardır.
Örnek revizyon yorumları
- Zayıf yorum: “Bu bölüm içime sinmedi.”
- Daha iyi yorum: “Hizmet kartları arasında görsel hiyerarşi zayıf; kullanıcının hangi hizmetten başlaması gerektiği anlaşılmıyor.”
- Zayıf yorum: “Renkleri biraz değiştirsek?”
- Daha iyi yorum: “CTA butonu arka planla yeterince ayrışmıyor; teklif alma aksiyonu daha görünür olmalı.”
- Zayıf yorum: “Bunu daha modern yapalım.”
- Daha iyi yorum: “Referans alanında kartlar çok sıkışık görünüyor; daha ferah boşluk ve daha okunabilir logo yerleşimi istiyoruz.”
Revizyon yorumunun amacı tasarımcıya emir vermek değil, problemi tarif etmektir. Çözüm önerisi verilebilir; fakat tasarım kararını hedefe göre birlikte değerlendirmek daha sağlıklıdır.
Revizyonları tek merkezde toplamak neden önemli?
WhatsApp, e-posta, telefon, toplantı notu ve ayrı ayrı PDF yorumları aynı anda kullanılırsa revizyon süreci dağılır. Bir kişi başlığı değiştir derken başka biri aynı başlığı beğenebilir. Ajans tarafında hangi yorumun son karar olduğu belirsizleşir.
Bu yüzden projede tek bir revizyon kanalı seçilmelidir. Bu kanal Figma yorumu, ortak doküman, proje yönetim paneli veya düzenli revizyon tablosu olabilir. Önemli olan herkesin aynı listeye bakması ve her yorumun durumu net görülmesidir.
Bir kurumsal web tasarım ajansı ile çalışırken en verimli yöntem genellikle şudur: İç ekip önce kendi içinde yorumları toplar, çelişen kararları temizler, ardından ajansa tek bir revizyon listesi gönderir. Böylece ajans tasarımı geliştirmeye odaklanır; karar karmaşasını çözmeye değil.
Örnek revizyon takip tablosu nasıl olmalı?
Aşağıdaki yapı, kurumsal web sitesi projelerinde kullanılabilecek sade bir revizyon takip örneğidir. Karmaşık yazılım şart değildir; başlangıçta ortak bir tablo bile süreci ciddi şekilde rahatlatabilir.
| Sayfa / Alan | Geri bildirim | Gerekçe | Öncelik | Durum |
|---|---|---|---|---|
| Ana sayfa hero | Başlık daha sonuç odaklı yazılsın | İlk ekranda hizmet net anlaşılmıyor | Yüksek | Ajansa iletildi |
| Hizmet kartları | Kart açıklamaları 1 cümle kısaltılsın | Mobilde kartlar fazla uzuyor | Orta | Düzenlenecek |
| Referans alanı | Logo yerine proje çıktısı görseli denensin | Güven kanıtı daha somut olmalı | Orta | Tasarım önerisi bekleniyor |
| İletişim formu | Telefon alanı zorunlu kalsın, şirket adı opsiyonel olsun | Form sürtünmesi azaltılmak isteniyor | Yüksek | Onaylandı |
| Mobil menü | Alt hizmetler iki satıra taşmadan gösterilsin | Kullanıcı erişimi zorlaşıyor | Yüksek | Test edilecek |
Kaç tur revizyon sağlıklıdır?
Her proje için tek sayı doğru değildir; fakat kurumsal web sitesi projelerinde genellikle iki veya üç planlı revizyon turu yeterli olur. İlk turda büyük yapı kararları, ikinci turda görsel ve içerik detayları, son turda ise kontrol ve küçük düzeltmeler ele alınabilir.
Beşinci veya altıncı revizyon turuna gelindiğinde çoğu zaman tasarım problemi değil karar problemi vardır. Hedef kitle değişmiş, marka tonu netleşmemiş, karar verici sürece geç dahil olmuş veya ilk brief eksik hazırlanmış olabilir. Bu durumda revizyon sayısını artırmak yerine brief ve onay mekanizmasını yeniden ele almak daha doğru olur.
Hangi revizyonlar öncelikli ele alınmalı?
Tüm revizyonlar aynı ağırlıkta değildir. Logo boyutunun birkaç piksel büyümesi ile iletişim formunun mobilde çalışmaması aynı öncelikte olamaz. Bu yüzden revizyon listesi “kritik, önemli, düşük” gibi önceliklere ayrılmalıdır.
Kritik revizyonlar genellikle kullanıcı aksiyonunu, erişilebilirliği, mobil kullanılabilirliği, teknik çalışabilirliği veya marka güvenini etkiler. W3C’nin WCAG kaynakları; erişilebilirlik standartlarının görme, işitme, hareket ve bilişsel farklılıkları olan kullanıcılar için web içeriklerini daha kullanılabilir hale getirmeyi hedeflediğini açıklar W3C WAI. Bu yüzden okunabilirlik, kontrast, buton erişimi ve form hataları yalnızca estetik detay gibi görülmemelidir.
- Kritik: Form çalışmıyor, mobil menü açılmıyor, CTA görünmüyor, sayfa taşma yapıyor.
- Önemli: Hizmet mesajı net değil, referans alanı güven vermiyor, görsel hiyerarşi zayıf.
- Orta: İkon stili tutarsız, bazı metinler fazla uzun, boşluklar dengelenmeli.
- Düşük: Küçük hizalama farkları, minör görsel tercihleri, son yazım düzeltmeleri.
Ajans ve müşteri tarafında roller nasıl ayrılmalı?
Revizyon sürecinde müşteri tarafı iş hedefini, marka önceliğini ve karar yetkisini getirir. Ajans tarafı ise tasarım, UX, teknik uygulanabilirlik ve dönüşüm mantığını masaya koyar. Sağlıklı süreçte iki taraf birbirinin rolünü ezmez.
Müşteri “bu butonu buraya koy” diyebilir; fakat daha iyi yorum “kullanıcının teklif butonunu ilk ekranda daha hızlı görmesini istiyoruz” şeklindedir. Ajans da bu hedefe göre konum, renk, metin veya sayfa akışı önerebilir. UI/UX tasarım hizmeti açısından iyi sonuç, yalnızca güzel ekran değil, kullanıcının görevini daha rahat tamamlamasıdır.
Teknik tarafta da ajansın sınırları açıkça belirtmesi gerekir. Örneğin animasyonun kullanıcı deneyimini yavaşlatacağı, yeni bir filtre yapısının ekstra yazılım gerektirdiği veya bazı görsel efektlerin mobil performansı etkileyebileceği net anlatılmalıdır. Google’ın JavaScript SEO dokümantasyonu, modern sitelerde JavaScript kullanımının arama motoru tarafından işlenmesiyle ilgili teknik dikkat noktalarını açıklar Google Search Central. Bu nedenle teknik revizyonlar yalnızca “görünüş” kararı değildir.
Revizyon sürecini uzatan hatalar
Revizyon sürecini en çok uzatan hata, karar vericinin en sona bırakılmasıdır. Tasarım ekibi, pazarlama ekibi ve ajans iki hafta çalışır; son gün yönetici farklı bir yön isterse süreç doğal olarak geri sarılır. Bu durum ajansın hızından bağımsız olarak zaman kaybettirir.
İkinci hata, tek tek kişisel yorum toplamaktır. “Muhasebe birimi bu rengi sevmedi”, “satış ekibi butonu başka istedi”, “yönetici daha premium olsun dedi” gibi yorumlar hedefe bağlanmadığında tasarım kararı alınamaz. Üçüncü hata ise her revizyonda brief’i değiştirmektir; proje başta kurumsal bir siteyken sonradan e-ticaret, portal veya kampanya landing page beklentisine dönüşebilir.
- Karar vericiyi ilk tasarım sunumundan önce sürece dahil edin.
- Yorumları tek bir dosyada toplayın; WhatsApp mesajlarını ana kaynak yapmayın.
- Her yorumun hangi sayfa ve hangi alanla ilgili olduğunu yazın.
- “Böyle olsun” yerine “şu problem çözülmeli” şeklinde geri bildirim verin.
- Kapsam dışı talepleri revizyon listesine karıştırmayın.
- Mobil görünümü ayrı değerlendirin; masaüstü onayı tek başına yeterli değildir.
- Son revizyon turunu yazım, link, form ve teknik kontrol için ayırın.
Revizyon bitince nasıl onay verilmeli?
Revizyon tamamlandığında yalnızca “tamamdır” demek yerine onay kapsamı net yazılmalıdır. Hangi sayfaların onaylandığı, hangi maddelerin sonraki faza bırakıldığı, hangi içeriklerin müşteri tarafından teslim edileceği ve yayına hazırlık için hangi teknik kontrollerin yapılacağı belirtilmelidir.
Örneğin iyi bir onay notu şöyle olabilir: “Ana sayfa, hizmetler, hakkımızda ve iletişim tasarımları onaylandı. Referans görselleri müşteri tarafından 12 Haziran’a kadar iletilecek. Blog listeleme alanı ikinci fazda değerlendirilecek. Mobil form ve WhatsApp tıklaması yayından önce tekrar test edilecek.” Bu not, sonraki anlaşmazlıkların büyük kısmını önler.
Sonuç: iyi revizyon, tasarımı değil kararı iyileştirir
Web tasarım ajansı ile revizyon süreci iyi yönetildiğinde proje daha hızlı, daha net ve daha az sürtüşmeyle ilerler. Bunun yolu yorumları kişisel zevkten çıkarıp hedef, kullanıcı, teknik uygulanabilirlik ve marka algısı üzerinden değerlendirmektir.
Doğru revizyon kültürü, ajansın tasarımı savunması veya müşterinin her detayı dikte etmesi üzerine kurulmaz. İki tarafın da aynı hedefe bakması gerekir: kullanıcı neyi anlayacak, hangi aksiyonu alacak, marka nasıl algılanacak ve site yayına çıktığında neyi daha iyi yapacak?
Sıkça Sorulan Sorular
Web tasarım projesinde revizyon ne anlama gelir?
Revizyon, proje kapsamında zaten planlanmış bir sayfa, bölüm, içerik veya görsel kararın iyileştirilmesidir. Örneğin başlığın netleştirilmesi, CTA butonunun daha görünür hale getirilmesi, mobil menü taşmasının düzeltilmesi veya hizmet kartlarının okunabilirliğinin artırılması revizyon sayılabilir. Ancak projede olmayan yeni sayfa, yeni modül, özel yazılım özelliği veya entegrasyon talebi genellikle revizyon değil, yeni kapsam maddesidir.
Web tasarım ajansına revizyon yorumu nasıl verilmeli?
Revizyon yorumu net, konumlu ve gerekçeli olmalıdır. “Bu alanı beğenmedim” demek yerine hangi sayfada, hangi bölümde, hangi problemin görüldüğü açıklanmalıdır. Örneğin “Ana sayfa hero başlığı hizmetimizi çok genel anlatıyor; kullanıcıya özel CRM ve süreç otomasyonu sunduğumuzu daha net söylemeliyiz” yorumu daha uygulanabilirdir. Böylece ajans yalnızca zevki değil, çözülmesi gereken problemi görür.
Kaç tur revizyon normal kabul edilir?
Kurumsal web tasarım projelerinde genellikle iki veya üç planlı revizyon turu sağlıklı kabul edilir. İlk turda sayfa yapısı, mesaj ve ana tasarım dili; ikinci turda görsel detaylar, içerik ve CTA alanları; son turda ise mobil görünüm, yazım hataları, linkler ve teknik kontroller ele alınabilir. Çok fazla revizyon turu gerekiyorsa çoğu zaman tasarım yerine brief, hedef veya karar mekanizması yeniden değerlendirilmelidir.
Revizyon ile kapsam dışı talep nasıl ayırt edilir?
Revizyon mevcut kapsam içindeki bir alanın iyileştirilmesidir; kapsam dışı talep ise projeye yeni iş yükü veya yeni fonksiyon ekler. Örneğin iletişim formundaki alanların sadeleştirilmesi revizyon olabilir. Fakat yeni bir müşteri paneli, fiyat hesaplama aracı, blog modülü veya ödeme entegrasyonu eklemek yeni kapsam sayılır. Bu ayrım proje takvimini, maliyeti ve beklentiyi korumak için baştan netleştirilmelidir.
Revizyonlar WhatsApp üzerinden gönderilebilir mi?
Küçük notlar WhatsApp üzerinden paylaşılabilir; fakat ana revizyon listesi için tek merkezli bir kanal kullanmak daha sağlıklıdır. WhatsApp, e-posta, toplantı notu ve ayrı PDF yorumları aynı anda kullanılırsa hangi yorumun son karar olduğu karışabilir. En iyi yöntem, iç ekip yorumları önce kendi içinde netleştirip ajansa tek bir revizyon dokümanı, proje yönetim kartı veya Figma yorum seti olarak iletmektir.
Revizyon süreci bittikten sonra nasıl onay verilmeli?
Onay verirken yalnızca “tamamdır” demek yerine hangi sayfaların, hangi ekranların ve hangi maddelerin onaylandığı yazılmalıdır. Ayrıca sonraki faza bırakılan işler, müşteri tarafından teslim edilecek içerikler ve yayına kadar tekrar test edilecek teknik alanlar belirtilmelidir. Bu netlik, yayına hazırlık aşamasında yanlış anlaşılmaları azaltır ve ajansın son kontrol listesini daha güvenli şekilde tamamlamasını sağlar.
