UX Audit Nedir, Nasıl Yapılır? Web Sitenizdeki Dönüşüm Engellerini Bulma Rehberi

Siteniz trafik alıyor ama form doldurulmuyor, sepetler yarıda kalıyor ve kimse nedenini bilmiyorsa, sıradaki adım yeni bir tasarım değil, bir UX audit olmalı. 2012'den beri kurumsal sitelerde ve e-ticaret projelerinde çalışıyorum; sorunun çoğu zaman tek bir yerde değil, küçük sürtünmelerin toplamında olduğunu gördüm. Bu yazıda denetimi kendi uyguladığım sırayla, adım adım anlatıyorum.

UX audit nedir ve ne işe yarar?

UX audit, bir web sitesinin kullanıcı deneyimini heuristik ilkeler, analitik veri, ısı haritası ve oturum kayıtlarıyla sistemli biçimde inceleyip dönüşümü engelleyen sorunları kanıtlarıyla listeleyen denetimdir. Çıktısı bir görüş yazısı değil; önem derecesine göre sıralanmış, her maddesi bir sayfaya ve bir veriye bağlı bulgu listesidir.

Yani UX audit sizin yerinize "güzel mi, çirkin mi" sorusunu cevaplamaz. Bunun yerine şu soruya odaklanır: ziyaretçi nerede takılıyor, neden takılıyor ve bunu düzeltmek ne kadar emek ister? Bu farkı baştan netleştirmek önemli, çünkü denetimin değeri tartışmayı zevkten veriye taşımasından gelir.

Bir denetim üç şey üretir: sorunların haritası, her sorunun kanıtı ve düzeltme sırası. Böylece ekip neyi neden düzelttiğini bilir ve sonuçları da ölçebilir.

UX audit ile UX hataları listesi arasındaki fark nedir?

İnternette "en sık yapılan UX hataları" türünde pek çok liste bulursunuz. Ben de sitemde satışı düşüren UX hatalarını ayrı bir yazıda anlattım. Ancak o yazı neyin yanlış olabileceğini söyler; UX audit ise sizin sitenizde neyin gerçekten yanlış olduğunu bulur.

Liste genel bir tahmindir, denetim ise yerel bir teşhistir. Örneğin uzun formun dönüşümü düşürdüğünü herkes bilir. Fakat sizin formunuzda insanların tam olarak hangi alanda vazgeçtiğini yalnızca veri gösterir. Bu yüzden listeyi hipotez kaynağı olarak kullanırım; denetim bu hipotezleri doğrular ya da çürütür.

Kısacası liste okumak bir fikir verir, denetim ise bir iş planı verir. İkisi birbirinin rakibi değil, tamamlayıcısıdır.

Pratikte ben listeyi denetimin ilk gününde bir kontrol aracı olarak açarım. Her maddeyi sitenin ilgili sayfasında ararım ve bulduğumu veriyle doğrulamaya çalışırım. Doğrulanamayan madde listede kalmaz; böylece ekip, var olmayan bir sorunu düzeltmek için zaman harcamaz.

Hangi durumlarda UX audit yaptırmalısınız?

Her site sürekli denetime ihtiyaç duymaz. Öte yandan bazı işaretler görüldüğünde beklemek, her ay kaybedilen müşteri demektir. Sahada en sık denetim ihtiyacı doğuran durumlar şunlar:

• Trafik sabit ya da artıyor, ama form, arama veya satış sayısı düşüyor.
• Reklam bütçesi artırıldığı halde dönüşüm maliyeti yükseliyor.
• Mobil trafik payı yüksek, fakat mobil dönüşüm masaüstünün çok gerisinde kalıyor.
• Site yeni yenilendi ve eski siteye göre sonuçlar kötüleşti.
• Müşteri hizmetlerine sık sık "siteden şunu bulamadım" türü sorular geliyor.
• Yeni bir tasarım projesi planlıyorsunuz ve neyin korunacağını bilmek istiyorsunuz.

Son madde bence en az kullanılan ama en kârlı fırsattır. Yenilemeden önce yapılan bir denetim, çalışan parçaları korur ve aynı hataları yeni tasarıma taşımanızı engeller. Dolayısıyla dönüşüm odaklı bir tasarım süreci çoğu zaman bir denetimle başlar.

UX audit öncesinde hangi hedefleri netleştirmelisiniz?

Hedefsiz denetim, sonu gelmeyen bir gözlem listesine dönüşür. Bu nedenle ilk toplantıda şu soruyu sorarım: bu sitenin işi nedir? Bir e-ticaret sitesi için cevap satış, bir kurumsal site için teklif talebi, bir SaaS için deneme kaydı olabilir.

Ardından ana dönüşümü ve onu besleyen ara adımları yazarım. Örneğin teklif formu ana hedefse, hizmet sayfası görüntüleme, form sayfasına geçiş ve form gönderimi ara adımlardır. Bu adımlar denetimin iskeletini oluşturur. Hedefleri nasıl seçeceğinizi dönüşüm hedefi belirleme yazısında ayrıntılı anlattım.

Son olarak kapsamı sınırlarım. Bin sayfalı bir sitenin tamamını aynı derinlikte incelemek anlamsızdır. Bunun yerine trafiğin ve gelirin çoğunu taşıyan şablonlara, yani ana sayfa, kategori, ürün veya hizmet sayfası, form ve ödeme adımlarına odaklanırım.

Kapsamı yazılı hale getirmek sonradan çıkan tartışmaları da önler. Örneğin blog sayfalarını bu turda incelemeyeceğinizi baştan not ederseniz, rapor teslim edildiğinde "blog neden yok" sorusu gelmez. Ayrıca hangi tarih aralığının verisine bakacağınızı da belirleyin; kampanya dönemi ile sakin dönem çok farklı davranış gösterebilir.

Denetim için hangi verileri toplamalısınız?

İyi bir UX audit, tek bir kaynağa güvenmez. Her kaynak başka bir soruyu cevaplar; bu yüzden veriyi en baştan birlikte toplarım. Aşağıdaki liste çoğu projede başlangıç setimdir:

1. GA4: sayfa bazlı etkileşim, dönüşüm hunisi, cihaz ve kaynak kırılımı.
2. Search Console: hangi sorguyla gelindiği, yani ziyaretçinin beklentisi.
3. Isı haritası ve oturum kaydı: tıklama, kaydırma ve gerçek davranış.
4. Core Web Vitals: saha verisiyle hız ve görsel kararlılık.
5. Müşteri hizmetleri kayıtları: telefonda ve WhatsApp'ta tekrar eden sorular.
6. Satış ekibi gözlemi: müşterinin karar verirken neyi sorduğu.

Buradaki son iki kalem çoğu denetimde atlanır. Oysa telefonda "kargo ne zaman gelir" diye soran her müşteri, sitede o bilginin bulunamadığını söylüyordur. Ayrıca ölçüm kurulumunun doğruluğunu da kontrol edin; yanlış sayılan bir dönüşüm, bütün denetimi yanlış yöne çeker. Bunun için Search Console rehberi ile başlayabilirsiniz.

Nielsen'in 10 ilkesiyle heuristik değerlendirmeyi nasıl yaparsınız?

Heuristik değerlendirme, bir uzmanın arayüzü kabul görmüş kullanılabilirlik ilkelerine göre sayfa sayfa incelemesidir. En yaygın çerçeve Jakob Nielsen'in 10 kullanılabilirlik ilkesi. Ben her ana şablonu bu ilkelerin tamamıyla tek tek karşılaştırırım:

1. Sistem durumunun görünürlüğü: kullanıcı ne olduğunu görüyor mu?
2. Sistem ile gerçek dünya arasındaki uyum: dil müşterinin dili mi?
3. Kullanıcı kontrolü ve özgürlüğü: geri dönmek kolay mı?
4. Tutarlılık ve standartlar: aynı şey her yerde aynı mı görünüyor?
5. Hata önleme: yanlış girişi baştan engelliyor musunuz?
6. Hatırlamak yerine tanıma: bilgi ekranda mı, hafızada mı?
7. Esneklik ve kullanım verimliliği: deneyimli kullanıcı için kısa yol var mı?
8. Estetik ve sade tasarım: gereksiz öğe dikkati bölüyor mu?
9. Hataları tanıma, teşhis ve düzeltme: hata mesajı çözüm sunuyor mu?
10. Yardım ve dokümantasyon: gerektiğinde yardım bulunuyor mu?

Her ihlali bir ekran görüntüsü, ilgili ilke ve kısa bir açıklamayla kaydederim. Böylece bulgu bir "bence" olmaktan çıkar ve herkesin kontrol edebileceği bir tespite dönüşür.

Bu aşamada bir uyarı da eklemek isterim: ilkeler bir puan kartı değildir. Bir sayfa on ilkenin tamamına uyup yine de satmayabilir. Çünkü heuristik değerlendirme kullanılabilirliği ölçer, ikna gücünü değil. Değer önerisi, fiyat ve güven sinyalleri gibi konuları bu yüzden ayrı bir başlık altında not ederim.

Heuristik değerlendirmede kaç değerlendirici gerekir?

Tek bir uzman sorunların bir kısmını yakalar, ama hepsini yakalayamaz. Nielsen Norman Group'un heuristik değerlendirme rehberi ideal olarak üç ile beş kişinin aynı arayüzü birbirinden bağımsız incelemesini öneriyor. Çünkü her değerlendirici farklı sorunlara takılır.

Pratikte küçük işletmelerde üç uzman bulmak zor olabilir. Bu durumda ben kendi incelememe ek olarak ekipten iki farklı rolü, örneğin bir satış temsilcisini ve bir müşteri hizmetleri çalışanını dahil ederim. Onlara ilkeleri kısaca anlatır, sonra ayrı ayrı gezinmelerini isterim.

Önemli olan bağımsızlıktır. Değerlendiriciler birbirinin notunu görürse aynı şeylere odaklanır ve çeşitlilik kaybolur. Bu yüzden notları ancak herkes incelemesini bitirdikten sonra birleştiririm; ardından tekrar edenleri tek bulguda toplarım.

GA4 verisinde dönüşüm engellerini nasıl bulursunuz?

Heuristik inceleme nerede sorun olabileceğini söyler, analitik ise sorunun ne kadar büyük olduğunu. Ben GA4'te önce huni keşfi raporu kurarım ve ana dönüşüm yolunun adımlarını tanımlarım. En büyük düşüş hangi adımdaysa, denetimin ağırlığı oraya kayar.

Ardından aynı huniyi cihaz, trafik kaynağı ve yeni ya da geri gelen ziyaretçi kırılımıyla açarım. Örneğin masaüstünde form adımı iyi çalışırken mobilde çöküyorsa, sorun büyük olasılıkla içerikte değil, mobil düzendedir. Benzer şekilde reklamdan gelenler bir sayfada hemen çıkıyorsa, reklam mesajı ile sayfa uyuşmuyor olabilir.

• Etkileşim oranı düşük açılış sayfalarını listeleyin.
• Huni adımları arasındaki en büyük kaybı cihaz bazında karşılaştırın.
• Site içi arama terimlerine bakın; aranan ama menüde olmayan şeyleri bulun.
• Çıkış sayfalarını, özellikle form ve sepet adımlarını ayrıca inceleyin.

Etkileşim oranını doğru yorumlamak için hemen çıkma oranı yazısına da göz atabilirsiniz.

Isı haritaları UX audit sürecinde neyi gösterir, neyi göstermez?

Isı haritası, bir sayfadaki tıklamaları, kaydırma derinliğini ve bazen fare hareketini renklerle özetler. Ücretsiz bir seçenek olarak Microsoft Clarity hem ısı haritası hem oturum kaydı sunuyor; kurulumu da tek bir etiketten ibaret.

Isı haritası özellikle üç şeyi iyi gösterir. Birincisi, tıklanamayan bir öğeye tıklanması; yani insanlar bir görselin ya da başlığın link olduğunu sanıyor. İkincisi, önemli bir bölümün kaydırma sınırının altında kalması. Üçüncüsü ise dikkatin CTA yerine ilgisiz bir öğeye kayması.

Ancak ısı haritası nedeni söylemez. Bir butona az tıklanıyorsa, buton görünmüyor olabilir; ya da ziyaretçi henüz ikna olmamıştır. Bu yüzden ısı haritasını tek başına karar aracı olarak kullanmam. Onu analitikteki düşüşle ve oturum kaydındaki davranışla birlikte okurum. Ayrıca az trafikli sayfalarda harita yanıltıcı olabilir; yeterli örneklem biriktirmeden sonuç çıkarmayın.

Oturum kayıtlarını izlerken nelere dikkat etmelisiniz?

Oturum kaydı, tek tek ziyaretçilerin sitede nasıl gezindiğini video gibi izlemenizi sağlar. Güçlü bir araçtır, ama rastgele izlemek saatler yer. Bu nedenle kayıtları her zaman bir soruya göre filtrelerim: örneğin "form sayfasına gelip göndermeden çıkan mobil ziyaretçiler".

İzlerken şu davranışları not ederim:

• Öfke tıklaması: aynı noktaya art arda hızlı tıklama, çoğunlukla çalışmayan bir öğeyi gösterir.
• İleri geri kaydırma: ziyaretçi aradığı bilgiyi bulamıyor.
• Alan başında duraksama: formda bir soru kafa karıştırıyor.
• Sekme değiştirme ve dönüş: ziyaretçi fiyatı ya da yorumu başka yerde kontrol ediyor.

Kişisel veriye de dikkat edin. Kayıt aracının form alanlarını maskelediğinden emin olun ve gizlilik metninizde bu aracı belirtin. Türkiye'de KVKK, yurt dışında GDPR açısından bu adımı atlamak ciddi risk yaratır.

Arama niyeti ile sayfa içeriği uyumunu nasıl denetlersiniz?

Bazı dönüşüm sorunları tasarımdan değil, beklenti uyumsuzluğundan doğar. Ziyaretçi "fiyat" diye aratıp gelir, ama sayfada fiyata dair tek satır bulamaz. Bu durumda en güzel düzen bile onu tutamaz. Bu yüzden denetimde her önemli açılış sayfası için Search Console'dan en çok tıklama getiren sorguları çıkarırım.

Ardından basit bir karşılaştırma yaparım: sorgu ne vaat ediyor, sayfanın ilk ekranı neyi cevaplıyor? Örneğin "kurulum süresi" sorgusuyla gelen biri, önce süreyi görmek ister; firma tarihçesini değil. Reklam trafiğinde de aynı kontrolü reklam metni ile başlık arasında yaparım.

Uyumsuzluk bulduğunuzda çözüm çoğu zaman küçüktür. Başlığı sorguya yaklaştırmak, ilk ekrana kısa bir cevap bloğu eklemek ya da ilgili bilgiyi yukarı taşımak yeterli olabilir. Böylece hem hemen çıkış azalır hem de sayfa, arayan kişinin sorusuna daha doğrudan cevap verir. İçerik tarafını güçlendirmek için SEO uyumlu içerik yazısına bakabilirsiniz.

UX audit sırasında en sık yapılan hatalar nelerdir?

Denetim yöntemi kadar, denetimi yürütme biçimi de sonucu belirler. Yıllar içinde hem kendi projelerimde hem de devraldığım raporlarda aynı hataların tekrarlandığını gördüm. En yaygın olanları şunlar:

• Veri toplamadan önce çözümü seçmek ve denetimi o çözümü haklı çıkarmak için kullanmak.
• Yalnızca masaüstünde incelemek; oysa trafiğin büyük kısmı çoğu sitede mobilden gelir.
• Her bulguyu aynı önemde sunmak ve ekibi yüzlerce maddelik bir listeyle boğmak.
• Kanıt eklememek; bu da bulguların toplantıda kişisel görüş gibi tartışılmasına yol açar.
• Ölçüm kurulumunu doğrulamadan huni verisine güvenmek.
• Düzeltmeden sonra ölçmemek ve denetimi tek seferlik bir belge olarak bırakmak.

Bu hataların ortak noktası, denetimi bir süreç değil bir teslimat gibi görmektir. Oysa iyi bir UX audit, ekibin karar alma biçimini değiştirir. Dolayısıyla raporu teslim etmek bitiş değil, iyileştirme döngüsünün başlangıcıdır.

Kullanıcı testi UX audit sürecinin neresine girer?

Veri ve uzman incelemesi çok şey söyler, ama gerçek bir kişinin sesli düşünerek siteyi kullanması başka bir katman ekler. Nielsen'in beş kullanıcı yazısı, küçük ve tekrarlı testlerin sorunların önemli bir bölümünü ortaya çıkardığını savunuyor. Ben de büyük bir test yerine kısa ve sık oturumları tercih ederim.

Pratikte hedef kitleye benzeyen beş kişiye üç gerçekçi görev veririm: bir ürünü bulmak, fiyatı anlamak ve formu göndermek. Onları yönlendirmem, sadece izlerim ve notlarım. İlk iki oturumdan sonra aynı sorunlar tekrar etmeye başlar; bu da denetimdeki hipotezleri doğrulamanın en hızlı yoludur.

Oturum sonunda katılımcıya iki kısa soru sorarım: siteyi bir arkadaşına nasıl anlatırdı ve neyi eksik buldu? Bu cevaplar, değer önerisinin ne kadar anlaşıldığını gösterir.

Kullanıcı testi pahalı olmak zorunda değil. Ancak katılımcıların ekip üyeleri ya da yakın tanıdıklar olmaması önemlidir. Çünkü siteyi zaten bilen biri, yeni ziyaretçinin takıldığı yerlere takılmaz.

Form ve ödeme adımlarını nasıl denetlersiniz?

Dönüşüm kaybının en yoğun olduğu yer çoğu sitede son adımlardır. Bu yüzden formu ve ödeme akışını ayrı bir oturumda, alan alan incelerim. Her alan için şu soruyu sorarım: bu bilgi olmadan işi yapabilir miyiz?

Ardından hata senaryolarını tek tek denerim. Yanlış telefon formatı girdiğimde mesaj ne diyor? Hata alanın yanında mı, sayfanın en üstünde mi çıkıyor? Girdiğim bilgiler sayfa yenilenince siliniyor mu? Mobil klavye telefon alanında rakam klavyesi açıyor mu? Bu küçük detaylar formu yarıda bıraktıran asıl nedenler olabilir.

Ayrıca form sonrasını da denetlerim. Teşekkür sayfası sonraki adımı anlatıyor mu, onay e-postası gerçekten gidiyor mu? Form tasarımının ayrıntılarını randevu, teklif ve demo formu tasarımı yazısında anlattım; denetimde bu kurallarla karşılaştırma yaparım.

Mobil deneyimi ve erişilebilirliği nasıl kontrol edersiniz?

Mobil kontrolü yalnızca tarayıcının dar ekran görünümüyle yapmam; gerçek cihazda, gerçek bağlantıyla gezinirim. Çünkü emülatör dokunma hassasiyetini, klavyenin ekranı kapatmasını ve yavaş ağdaki gecikmeyi tam yansıtmaz. Adım adım yöntem için mobil uyumluluk testi yazısına bakabilirsiniz.

Erişilebilirlik tarafında ise üç hızlı kontrol yaparım. Metin ile arka plan arasındaki kontrast yeterli mi? Site yalnızca klavyeyle gezilebiliyor mu? Görsellerin ve form alanlarının açıklayıcı etiketleri var mı? WCAG yönergeleri bu konuda ölçülebilir kriterler sunuyor; örneğin normal metin için en az 4,5:1 kontrast oranı istiyor.

Erişilebilirliği ayrı bir iyilik projesi gibi görmeyin. Düşük kontrastlı bir fiyat bilgisi, güneş altında telefondan bakan herkes için okunaksızdır. Dolayısıyla erişilebilirlik bulguları çoğu zaman doğrudan dönüşüm bulgularıdır.

Hız ve Core Web Vitals UX audit kapsamına girer mi?

Evet, girer; çünkü yavaş ya da zıplayan bir sayfa, en iyi tasarımı bile işe yaramaz hale getirir. Google'ın web.dev Core Web Vitals sayfası iyi deneyim için üç eşik veriyor: LCP 2,5 saniye veya altı, INP 200 milisaniye veya altı, CLS 0,1 veya altı. Bu değerler ziyaretlerin 75. yüzdelik dilimine göre ölçülüyor.

Denetimde laboratuvar skoruna değil, önce saha verisine bakarım. Search Console'daki Core Web Vitals raporu hangi şablon grubunun sorunlu olduğunu gösterir. Ardından o şablonu Lighthouse ile test ederek nedeni bulurum.

Özellikle CLS'ye UX gözüyle bakmak önemlidir. Sayfa yüklenirken buton aşağı kayarsa, kullanıcı yanlış yere tıklar. Bu da hem öfke tıklamasına hem de güven kaybına yol açar. Kısacası hız bulguları ile davranış bulguları çoğu zaman aynı sorunun iki yüzüdür.

Hız bulgusunu rapora yazarken teknik terimi iş diline çevirmeyi de unutmayın. "LCP 4 saniye" yerine "ürün görseli mobilde geç görünüyor ve ziyaretçi boş bir alana bakıyor" demek, yönetimin önceliği anlamasını kolaylaştırır. Ayrıntılı teknik yol haritası için site hızı yazısına göz atabilirsiniz.

Bulguları hangi şablonla kaydetmelisiniz?

Denetimin en sık bozulduğu yer bulguların yazıya dökülmesidir. "Menü kötü" gibi bir not, geliştiriciye hiçbir şey anlatmaz. Bu yüzden her bulguyu aynı kartla kaydederim ve ekipten de aynısını isterim:

• Başlık: sorunun tek cümlelik tanımı.
• Konum: sayfa, şablon ve cihaz.
• Kanıt: ekran görüntüsü, GA4 düşüşü, ısı haritası ya da oturum kaydı bağlantısı.
• İhlal edilen ilke: Nielsen ilkesi, WCAG kriteri veya Core Web Vitals metriği.
• Etki: hangi dönüşüm adımını etkilediği.
• Öneri: somut düzeltme, gerekiyorsa taslak metin.
• Önem ve emek puanı: önceliklendirme için.

Bu yapı sayesinde bulgu listesi doğrudan bir iş takip aracına aktarılabilir hale gelir. Üstelik aylar sonra biri "bunu neden değiştirdik?" diye sorduğunda cevap kartta durur.

UX audit bulgularını nasıl önceliklendirirsiniz?

Denetimden genellikle onlarca bulgu çıkar ve hepsini aynı anda düzeltmek mümkün değildir. Ben önceliği iki eksende belirlerim: sorunun dönüşüme etkisi ve düzeltmenin emeği. Önem için Nielsen'in 0 ile 4 arasındaki önem derecesi ölçeğinden uyarladığım basit bir tablo kullanırım:

Ardından her bulguya kaba bir emek tahmini eklerim: saatler, günler ya da haftalar. Yüksek önem ve düşük emek kesişimi "hızlı kazanımlar" listesini oluşturur. Tabloyu bir kural gibi değil, tartışmayı düzenleyen bir çerçeve gibi kullanın.

İyi bir UX audit raporu neleri içermeli?

Rapor, okuyan kişiye göre katmanlı olmalı. Yönetici ilk sayfada ne kadar kayıp olduğunu ve ilk üç işi görmek ister; geliştirici ise ayrıntılı kartları. Bu yüzden raporu şu sırayla kurarım:

1. Bir sayfalık yönetici özeti: ana bulgular ve önerilen ilk adımlar.
2. Kapsam ve yöntem: hangi sayfalar, hangi veriler, hangi tarih aralığı.
3. Dönüşüm hunisi ve en büyük kayıp noktaları.
4. Önem sırasına göre bulgu kartları.
5. Hızlı kazanımlar ve uzun vadeli öneriler ayrımı.
6. Ölçüm planı: her düzeltmenin nasıl takip edileceği.

Raporun uzunluğu değil, uygulanabilirliği önemlidir. Yüz sayfalık bir PDF genellikle bir klasörde unutulur. Buna karşılık kısa bir özet ve iyi etiketlenmiş bir bulgu listesi, ertesi gün iş takip panosuna taşınır.

Düzeltmelerin etkisini nasıl ölçmelisiniz?

Denetim, düzeltmeler yayına girdikten sonra ölçülmediği sürece yarım kalır. Bu nedenle her bulgu kartına baştan bir başarı metriği yazarım. Örneğin form alanını azalttıysanız, metrik form başlatma ile gönderim arasındaki oran olur.

Mümkünse önce ve sonra dönemlerini aynı uzunlukta, aynı mevsimsellikte karşılaştırırım. Trafiği yüksek sayfalarda A/B testi daha güvenilir sonuç verir. Ancak düşük trafikli kurumsal sitelerde test anlamlılığa ulaşmayabilir; o zaman eğilimi ve nitel geri bildirimi birlikte değerlendiririm.

Hangi metrikleri raporlayacağınızı seçmek için dijital pazarlama KPI'ları yazısı yardımcı olur. Önemli olan, dönüşüm oranındaki değişimi tek başına değil, gelir ve lead kalitesiyle birlikte okumaktır.

UX audit ne sıklıkla tekrarlanmalı?

Tek seferlik bir denetim iyi bir başlangıçtır, ama site, kampanyalar ve müşteri beklentisi sürekli değişir. Saha tecrübeme dayalı başlangıç önerim şu; garanti değil, sitenin hızına göre ayarlamanız gerekir:

• Kapsamlı UX audit: yılda bir kez veya büyük bir yenilemeden önce.
• Odaklı mini denetim: yeni bir kampanya, yeni ürün grubu ya da yeni form devreye girdiğinde.
• Aylık hızlı bakış: huni raporu, Core Web Vitals ve birkaç oturum kaydı.

Aylık bakış yarım günü geçmemeli. Amaç yeni bir rapor yazmak değil, beklenmedik bir düşüşü erken yakalamaktır. Böylece sorunlar birikip büyük bir yenileme ihtiyacına dönüşmeden çözülür.

UX audit'i kendiniz mi yapmalısınız, dışarıdan mı almalısınız?

İki yolun da artısı var. Ekibiniz siteyi ve müşteriyi iyi tanır, ama siteye alıştığı için sorunları görmez. Dış bir göz ise alışkanlık körlüğü taşımaz; fakat işinizi öğrenmek için zamana ihtiyaç duyar.

Bence en verimli model karmadır. Veri toplama ve oturum kaydı izleme gibi işleri ekip içinde yapabilirsiniz. Heuristik değerlendirmeyi ve önceliklendirmeyi ise en az bir dış uzmanla yapmak, iç tartışmaları da dengeler. Dışarıdan destek alacaksanız UI/UX hizmeti almadan önce sorulacak noktalar size bir kontrol listesi verir.

Denetimden sonra düzeltmeleri kimin uygulayacağını da baştan netleştirin. Rapor ile uygulama arasındaki boşluk büyüdükçe bulgular eskir. Eğer tasarım ve geliştirme tarafında desteğe ihtiyacınız olursa, web tasarım hizmetimde denetim bulgularını doğrudan uygulama planına çeviriyorum.

İlk UX audit için bir haftalık başlangıç planı

Büyük bir projeye girişmeden önce küçük bir denetimle başlamak istiyorsanız, şu beş günlük planı uygulayabilirsiniz. Her gün birkaç saatlik iş yeter:

1. 1. gün: ana dönüşümü ve huni adımlarını yazın, GA4 ölçümünü doğrulayın.
2. 2. gün: huni keşfini cihaz ve kaynak kırılımıyla açın, en büyük düşüşü bulun.
3. 3. gün: o adıma ait şablonu Nielsen ilkeleriyle inceleyin, bulgu kartlarını doldurun.
4. 4. gün: aynı sayfanın ısı haritasını ve yirmi kadar oturum kaydını izleyin.
5. 5. gün: bulguları önem ve emeğe göre sıralayın, ilk üç düzeltmeyi planlayın.

Bu plan kapsamlı bir UX audit'in yerini tutmaz, ama size neyin önemli olduğunu gösterir. Üstelik ekibinizin denetim alışkanlığı kazanmasını sağlar. Sonuçları ölçtükçe denetimi sitenin diğer şablonlarına genişletebilirsiniz.