Test ve Uzman Analizi Yapmak Ne Demek?

Aslında kullanılabilirlik testi diye adlandırılan ama UX kavramının popülerleşmesiyle “UX testi”ne dönüşen süreç şöyle işler. Bir arayüzün hedef kitlesindeki kullanıcılara gerçek hayatı simüle edebilecekleri bazı görevler verip, o görevleri yapmaya çalışırken onları gözlemler, bize “neyi yapmak istediklerini, nereye varmak istediklerini” anlatmalarını da isteriz, süreçteki arayüzün yaşattığı problemleri dokumante eder, analiz eder ve bir sunuma dökeriz.

Bu süreç bir akademik makale yazmak isterseniz, size oldukça fazla istatistiki sonuçlar da veren son derece formal prosedürleri olabilen bir şekildedir. Steve Krug abimiz yeni çevik dünyaya daha uygun bir şekilde “Atla Deve Değil” (orjinal ismi “Rocket Surgery Made Easy”) kitabında "Çevik süreçlerle ürün yönetiyoruz, her iki-üç sprintte birinde sabah 3 kişiyle test edin. Öğleden sonra testin sonuçlarının üzerine ekiple bir araya gelin. Sonrasında bunları raporlayın." diyor. Bu, aslında kullanılabilirlik testini sürecini oldukça hızlı ve bir tık da informal hale getirmiştir. (Not: Steve Krug zaten UX dünyasının Replikas’ıdır; underground rockstar'ıdır.)

Şimdi, bu kullanılabilirlik testiydi. Bir de uzman analizi var. Eğer vaktin yoksa, arayüzlerle alakalı son kullanıcı testini yapma konusunda belli kısıtların varsa veya biraz daha çeşitlendirmek istiyorsan, uzman analizi diye bir çalışma da yapabiliyorsun. Nedir bu uzman analizi çalışması? Jacob Nielsen abimizin bir arkadaşıyla beraber ortaya koyduğu, "Her arayüz bu 10 maddeye uymalıdır" şeklinde, 10 maddeden oluşan bir kontrol listesi var. Heuristics diyoruz biz buna. Bunun farklı yapılardaki arayüzler için farklı versiyonları var. Bir uzman bir arayüzün karşısına geçiyor. Bir senaryoyu kendisi tamamlamaya çalışırken, kullanıcının gözüyle o senaryoda yaşayabileceği problemleri dokümante ediyor ve bunu belirlerken de o Heuristics maddelerini referans veriyor. Bazen sadece test, bazen sadece uzman analizi yapabiliyoruz. Bazen ikisini de beraber yapabiliyoruz.

Bugünün konusu aslında yapay zeka ve daha çok da artık hayatımıza yeni giren agentic AI tarayıcılar bu işi/işleri yapabilir mi? Hadi gelin bunu irdeleyelim.

Yapay Zeka Bu İşleri Yapabiliyor Mu?

Hayır diyen de var, evet yapabilir diyen de. Herkes çorbasının peşinde :) (oooo gönderme) Zaten bu işlerdeki duruşumuz o alandan gelen bir danışmanlık teklifine göre değişebiliyor. (ooo daha da gönderme)

Yapay zeka ile bir web sitesini tarayıp size anında bir UX denetimi sunması fikri kulağa harika geliyor, kabul edelim.

Bu konuda bir ürünü olan Baymard’ın (onlar da bak kendi çorbasında) paylaştığı, iki Microsoft UX araştırmacısı tarafından 2025'te yapılan bir çalışma şunu diyormuş: Bu tür araçların profesyonel UX denetimleri için %50 ila %75 arasında şaşırtıcı derecede düşük doğruluk oranlarına sahip olduğunu gösteriyor. (mi acaba?)

Şöyle de göz korkutuyorlar: “Örneğin, bir yapay zekanın bir ürün galerisini "basitleştirmek" için küçük resimler (thumbnail) yerine noktalar kullanılmasını önermesi, Baymard'ın bir vakasında büyük bir perakendecinin dönüşüm oranında %1'lik bir düşüşe neden olabilecek bir hatadır.”

Hadi diğer taraftan bir çalışma bulalım: arXiv'de yayımlanan "Synthetic Heuristic Evaluation" (Sentetik Sezgisel Değerlendirme) başlıklı akademik bir çalışma, tersi bir sonucu bize iletiyor.

Çalışmaya göre yapay zeka, bir uygulamanın ekran görüntülerini analiz ederek kullanılabilirlik sorunlarını tespit etmede insan değerlendiricilerden daha başarılı olmuş. Yapay zeka, sorunların %73'ünü tespit ederken, deneyimli insan uzmanlardan oluşan grup yalnızca %57'sini bulabilmiş.

Bu çalışmaya da hem muhalefet şerhimizi düşelim hem de biraz açıklama yapalım: Yapay zeka, statik bir çerçeve içinde nesnel, piksel düzeyinde desen tanımada üstünken; insan uzmanlar, çok adımlı bir kullanıcı yolculuğu boyunca bağlamsal değerlendirmede mükemmeldir. Tek bir ekran üzerinde belki anlamlı olabilir ama genelde insan-arayüz etkileşiminde bir ekranlar serisi ile işlemleri tamamladığımız içim bu çalışmanın çoklu ekranlarda yapılması daha anlamlı olacaktır. Yapay zekanın farklı ekranlar arasındaki tutarsızlıkları anlama gibi daha fazla bağlam gerektiren konularda hala zorlandığını unutmamak gerek.

Benim kişisel deneyimim yine her AI odaklı yazıdaki gibi gidip oradan aldığımız sonucu doğrudan kullanmak yerine, bir ön araştırma sürecine katmak, kullanılabilirlik testi sorularını belirlemek vs. gibi konularda çok iyi bir yardımcı pozisyonunda.

Bir Küçük Ara Başlık - “İfade Engeli”

Jacob Nielsen’e göre yapay zeka kullanımındaki en temel zorluk, modelin zekasından veya yeteneklerinden değil, bizden, yani kullanıcılardan kaynaklanıyormuş. Bu durumu da “articulation barrier" (ifade engeli) olarak adlandırıyormuş. Yani diyor ki, çoğu kullanıcı karmaşık ihtiyaçlarını, hedeflerini veya sorunlarını yapay zekanın anlayabileceği netlikte ve yapıda ifade edemiyor.

Boş bir komut satırına bakıp "Ne istemeliyim?" diye düşünürken buluyoruz kendimizi. Başarılı yapay zeka arayüzleri, bu engeli aşmak için kullanıcıya yol gösteren, seçenekler sunan ve en önemlisi, netleştirici sorular soran sistemler ile sorunu aşmaya çalışıyorlar. Kullanıcının belirsiz talebini alıp, "Şunu mu demek istediniz?" veya "Bu hedef için hangi kriterler sizin için önemli?" gibi sorularla onu doğru yola yönlendiriyor.

Şunu ekliyor abimiz: “Yapay zeka ile aslında doğal dilde konuşabilirsiniz ve bu çok daha kolay, ancak yine de ne söyleyeceğinizi bilmeniz gerekiyor. Ben buna 'ifade engeli' diyorum; yani aslında ne istediğinizi formüle etme yeteneği."

Bu ara başlığı şu yüzden attım, aslında uzman analizi için UX ekibi bazında herkesin kullanabileceği bir master prompt şablonu oluşturmak güzel bir başlangıç noktası olabilir.

Yapay Zeka İle Audit İçin 2 Öneri

Aslında düz bir chat’e girip bir şablon prompt ile sonuç almanın ötesine geçebileceğimiz bazı yöntem önerileri de olabilir.

Mevcut Yapıda şu an bir websitesi adresini veya bir ekran görüntüsünü yapay zeka chat uygulamasına verip ondan kullanılabilik sorunlarını bulmasını bekliyoruz. Bunun ötesine geçebileceğimiz bazı tavsiyeler:

UX-Ray Çözümü: UX-Ray, bir arayüzün "iyi" mi yoksa "kötü" mü olduğuna karar vermek veya iyileştirme önerileri sunmak için bir LLM kullanmıyor. Bunun yerine, LLM'leri sadece çok dar ve nesnel bir görev için kullanıyor: arayüz desenlerini sınıflandırmak. Örneğin, bir LLM'e bir ekran görüntüsü gösterip, "Bu filtreleme menüsü onay kutuları mı yoksa bağlantı stili mi kullanıyor?" gibi bir soru soruyoruz. Asıl analiz ve öneri, Baymard'ın 150.000+ saatlik araştırmasına dayanan devasa, kural tabanlı bir sistem tarafından yapılıyor.

RAG Çözümü: RAG’lardan bültenlerimizde bahsetmiştik, yapay zekanın daha odaklı olmasını, daha önceki çalışmalarımızda bulduğumuz UX bulgularını bir vektör veritabanına dönüştürüp üzerine bir chat sistemi kurarak sağlayabiliriz, böylece halüsinasyon görme problemini de çözmüş olabiliriz.

Tarayıcılar Bu İşin Neresinde?

Hadi biraz daha agentic tarafa geçelim. Önce bu agentic tarayıcılar ne yapıyor ona bakalım:

OpenAI Atlas ve Perplexity Comet gibi "agentic" tarayıcılar, web üzerinde sadece bilgi bulmakla kalmayıp, sizin adınıza form doldurma, rezervasyon yapma veya ürünleri karşılaştırma gibi çok adımlı görevleri yerine getirebilen araçlardır. Bu yetenekleri sayesinde, karmaşık kullanıcı akışlarını simüle etmek için inanılmaz bir potansiyele sahipler.

Ancak temel bir sınırlılıkları var: zihinsel model eksikliği.

Buradaki temel çatışma şudur: ajanın hedefi görev tamamlama verimliliği iken, bir UX denetçisinin hedefi sürtünmeyi keşfetmektir. Bu hedefler birbiriyle çelişir. Bu yapay zeka ajanları, doğaları gereği son derece mantıksal ve sabırlıdır. Kötü tasarlanmış bir arayüzle karşılaştıklarında, bir insanın yaşayacağı sürtünmeyi, kafa karışıklığını veya bilişsel yükü (cognitive load) deneyimleyemezler. Ajan, görevi tamamlamak için ağır düşünme işini üstlenerek bilişsel boşaltma (cognitive offloading) yapar ve bu sayede bir insanın bilişsel yükünü ölçme fırsatını tamamen kaçırır ki bu, testin bütün amacıdır.

Hatta bunu şöyle anlatayım, ülkemizde ünlü bir okulun Endüstri Mühendisliği bölümünde verimlilik analizi yapılırken 2 öğrenci arkadaşımıza Trendyol ve Markafoni’nin karşılaştırmasının yapılması görevi verilmişti. Bu görevde arkadaşlarımız ürün bulma, arama ve satın alma süreçlerindeki verimliliği karşılaştırırken sitede geçirilen sürenin azlığı olumlu bir parametre olarak analiz ediliyordu. Verimlilik açısından bir an önce bir ürünü bulmak, satın almayı tamamlamak anlamlı dururken deneyim tarafında aslında kişinin sitede geçireceği sürenin uzunluğu her iki sitenin de tercih ettiği bir davranıştı. (Ürünü bulamasın ve daha uzun arasın olarak değil, ürünü ararken başka ürünleri de görsün, kombini tamamlasın, daha çok alışveriş yapsın gibi.)

Bu nedenle, bu araçlar bir akışın işlevsel olarak çalışıp çalışmadığını test etmek için harika olsalar da, gerçek insan deneyimini, yani o akışın ne kadar kolay veya sinir bozucu olduğunu tam olarak ölçemezler.

Hadi Deneyelim, Atlas, Dia ve Comet ile Analiz

Bu olumsuz girişe rağmen yine de deneyelim.

Önce prompt:

Promptception yaparak Cloude Sonnet 4.5’dan bu prompt konusunda yardım istedim.

Promptu paylaşabilmek için bir artifact hailine getirdim. Ve bu 3 tarayıcıda bu promptu Hangikredi.com için çalıştırdım.

Sonuçlar şu şekilde...

‍

Comet

‍

📊 Genel Değerlendirme

Kullanılabilirlik Skoru (0-10): 7

En Güçlü Yönler

• Kredi ve finansal ürünler arası karşılaştırma çok hızlı ve kolay.
• Bilgilendirici içerik ve finansal rehberler zengin; kullanıcıya yardımcı olmak amaçlı çeşitli araçlar mevcut.
• Ana işlevler ve başvuru süreçleri görünür, ana menüde kolay erişim ve net segmentasyon var.

En Zayıf Alanlar

• Erişilebilirlik (WCAG) standartları tam anlamıyla karşılanmıyor: klavye ve ekran okuyucu desteği, renk kontrastı, ARIA ve alt text eksiklikleri bariz.
• Teknik performans ve SEO optimizasyonu açısından sayfa yükleme hızı, meta ve Open Graph tag’leri, başlık hiyerarşisi eksiklikleri mevcut.
• Hataları kullanıcıya açıklayan, çözüm odaklı mesajlar yetersiz; yardım/dokümantasyon sekmesi sitesinde hızlıca bulunamıyor.

Genel İzlenim ve UX Yorumu:​
Site açık, hızlı ve finansal karşılaştırma deneyimini ön planda tutuyor. Ancak erişilebilirlik, teknik ve hata yönetimi tarafında ciddi gelişim alanları mevcut.

‍

Atlas

‍

📊 Genel Değerlendirme

Genel Kullanılabilirlik Skoru: 7.3 / 10

En Güçlü Yönler

• Çok geniş ürün gamı (kredi, mevduat, sigorta vb.) → kullanıcı ihtiyacını tek noktada çözebiliyor.
• Menü ve kategoriler bankacılık sektörüne uygun şekilde sınıflandırılmış.
• İçerik zengin, finansal araçlar ve bilgi merkezi yazıları iyi organize edilmiş.

En Zayıf Alanlar

• Aşırı yoğun içerik → Aesthetic & Minimalist Design ilkesini ciddi biçimde zorluyor.
• Çok fazla banner, slider, kampanya alanı → dikkat bölünüyor.
• Erişilebilirlik eksikleri (alt text yetersizlikleri, focus indicator belirsizliği, heading hiyerarşi sorunları).
• Yardım/dokümantasyon ve hata durumları için görünür mekanizma yok.

‍

Dia

‍

📊 Genel Değerlendirme

Genel kullanılabilirlik skoru: 7,5/10

En güçlü yönler:

• Net içerik hiyerarşisi ve bankalar/ürünler için kapsamlı kategoriler
• Ana sayfada güncel finansal veri ve kampanya bloklarıyla güçlü bilgilendirme
• Ürün sayfalarına hızlı geçiş sağlayan tutarlı menü yapısı

En zayıf alanlar:

• Erişilebilirlik (kontrast, odak görünürlüğü, ARIA/alt metin tutarlılığı) belirsiz
• Hata ve durum geri bildirimi (form gönderimleri, yükleme/progress) görünür değil
• Teknik performans (görseller, JS/CSS minifikasyon, FCP/LCP optimizasyonu) için kanıt yok

Senaryo Analizi

Bu anasayfa değerlendirmelerinden sonra “Bu sitede ihtiyaç kredisine başvurma sürecini deneyerek bu değerlendirmeyi yapsan?” senaryosu ile devam ettiğimde Dia’da şöyle bir mesaj alıyorum:

“Bunu yapabilmem için süreci doğrudan deneyip formları doldurmam ve sayfalar arasında gezinmem gerekir. Dia, siteler üzerinde sizin adınıza işlem yapamaz veya etkileşimli testler yürütemez.”

Diğer iki tarayıcı devam ederken onayımı istediler.

Commet doğrudan sayfaları gezip bir çok sayfa ziyareti yaptıktan sonra şu sonuca ulaştı:

📊 Genel Değerlendirme

Kullanılabilirlik Skoru (0-10): 7

En güçlü yönler:

• Progress Bar & Multi-Step Form: ING başvuru formunda 1/2/3/4 adım göstergesi net ve görsel olarak açık (Nielsen #1) ✅
• arşılaştırma Araçları: Kredi hesaplama ve karşılaştırma işlevleri hızlı, "Son Hesaplamalarınız" linki önceki sorguları kaydediyor (Nielsen #6) ✅
• Kapsamlı Yardım İçeriği: FAQ, rehber, "Neden Güvenliyiz?" ve TOBB sertifikası sayfada görülüyor (Nielsen #10) ✅

En zayıf alanlar:

• Hata Mesajları Netliği: TC kimlik numarası "11 haneli Kimlik numarası yazın" mesajı yanıltıcı (Nielsen #9) ❌
• Renk Kontrastı & Erişilebilirlik: Footer ve breadcrumb linkleri yetersiz kontrast, alt text eksik (Nielsen 3 & 7) ❌
• Modal İçerik Yoğunluğu: Kampanya koşulları modal'da metin yığını şeklinde, okunabilirlik zayıf (Nielsen #8) ❌

‍

Atlas'da ise şu şekilde bir sonuç aldım:

🎯 GENEL DEĞERLENDİRME & PUAN

⭐ Kullanıcı Deneyimi: 8.3 / 10

Modern, anlaşılır, hızlı.

⭐ Şeffaflık: 6 / 10

Sıralama sponsor odaklı, kullanıcı ilk gördüğü ürünü yanlış yorumlayabilir.

⭐ Başvuru Akışı Kolaylığı: 7.5 / 10

Bazı bankalar uygulamaya yönlendirdiği için süreç çifte zahmetli.

Sonuç

Bu deney sürecini baştan sona değerlendirecek olursak, aslında test deneyimi tek sayfa özelinde ilerlediğimizde linklere erişimi olan herhangi bir chat aracına bir url vermekten çok farklı değil. Bulgular ön bulgu şeklinde değerlendirmek için uygun olmakla birlikte bir nedensellik aradığımızda araçlar zayıf kalabiliyor.

• Dia’nın skill özelliği ile Comet’in shortcut özelliği benzer sorguları başka sitelerde yapmayı kolaylaştırıyor.
• Comet ve Atlas süreç testi yapabiliyor, Comet’in deneyimi daha pürüzsüzken, Atlas her adım için kullanıcıdan bilgi almayı tercih ediyor.
• Atlas süreçte devam ederken bağlamı unutabiliyor, Comet burada bağlama daha bağlı ilerliyor ve ilk prompt da verilen çıktı yapısına ugun şekilde devam ediyor.

Skorlama tarafında ise genelde yapay zeka orta yolcu, 6-8 arası puan vermeyi tecih ediyor, genel yorumlarda hep 7 hattında bir puan alıyorsunuz.

Tüm bu deneyimin sonunda, aslında bir sonraki adımın ne olabileceğine dair net bir yol da şekilleniyor.

Artık yalnızca bir siteyi tarayıcılara verip yorum almaktan öteye geçmenin zamanı. Senaryoyu gerçek bir kullanıcı persona’sıyla zenginleştirerek (örneğin “X kredisini başvuran bir müşteri olduğunu düşün” gibi bir kimlik ekleyerek) analiz derinliğini artırabiliriz. Bunun yanında, tarayıcı tabanlı değerlendirmelerin ötesine geçip Gemini gibi daha “agentic” çalışan API’ları devreye almak, araçları sadece gözlem yapan değil, bağlamı genişletebilen yapılar hâline getirebilir. Böylece bu ilk turda elde ettiğimiz ön bulguları, daha tutarlı, daha nedensel ve daha gerçek bir kullanıcı deneyimine yaklaşan bir analiz hattına dönüştürme şansımız olur.

‍